Czy pliki binarne TrueCrypta były skompilowane z dostępnych źródeł?
Zapewne część z Was korzysta z TrueCrypta pod Windows. Czy ktoś jednak sam skompilował go z dostępnych źródeł? Jeśli nie, to czy słusznie ufacie opublikowanym plikom binarnym? Ktoś postanowił to sprawdzić, skompilował i porównał wynik.
Publikacja kodu źródłowego jest dobrym krokiem w stronę zapewnienia przejrzystości projektu i zwiększenia poziomu zaufania użytkowników. Cóż jednak po opublikowanym kodzie źródłowym, jeśli znakomita większość użytkowników korzysta ze skompilowanych plików binarnych, weryfikując w najlepszym przypadku tylko ich zgodność z sygnaturami opublikowanymi na stronie producenta oprogramowania? Taka sytuacja dotyczy wielu programów, szczególnie na platformie Windows, gdzie mało kto bawi się we własnoręczną kompilację swoich plików. Dodatkowo w przypadku TrueCrypta nie wiadomo, kto jest jego autorem, co budzi zrozumiałe wątpliwości użytkowników.
Powtarzalna kompilacja nie jest prosta
Udowodnienie, że opublikowane pliki wykonywalne są skompilowane z opublikowanych plików źródłowych jest wbrew pozorom bardzo trudnym zadaniem (projekt TOR poradził sobie z nim dopiero kilka tygodni temu). Na treść wyniku kompilacji wpływa bardzo wiele czynników na poziomie konfiguracji sprzętu, oprogramowania i użytych narzędzi oraz bibliotek. By otrzymać wynik idealnie zgodny trzeba nie tylko zreplikować w 100% pełne środowisko, użyte do kompilacji oryginału, ale także zrobić to dokładnie tego samego dnia, o tej samej godzinie, minucie i sekundzie (informacje o czasie kompilacji są zapisywane w pliku wynikowym) oraz użyć tych samych certyfikatów do podpisania plików wynikowych i tych samych parametrów kompilacji. Nawet to nie gwarantuje, że suma kontrolna otrzymanego pliku będzie zgodna z oryginalną. Jak zatem odpowiedzieć na pytanie, czy TrueCrypt został skompilowany wyłącznie z dostępnych źródeł, bez żadnych nieprzewidzianych dodatków? Student kanadyjskiego uniwersytetu Xavier de Carné de Carnavalet stanął przed tym zadaniem – i mu podołał. Przeczytajcie, jak to zrobił.
Wszystko da się zrobić, trzeba tylko chcieć
Xavier zaczął od pobrania z oficjalnej strony projektu plików binarnych TrueCrupta 7.1a dla Windows oraz kodu źródłowego tej samej wersji. Zweryfikował sygnatury PGP pobranych plików, by potwierdzić ich autentyczność – wszystko się zgadzało. Następnie przystąpił do odtworzenia środowiska kompilacji, opisanego w pliku Readme.txt zawartym w archiwum kodu źródłowego. W tym celu pobrał i zainstalował następujące elementy:
- Microsoft Visual C++ 2008 SP1 (Professional Edition lub kompatybilna)
- Microsoft Visual C++ 1.52 (dostępne dla abonentów MSDN)
- Microsoft Windows SDK for Windows 7 (skonfigurowane dla Visual C++)
- Microsoft Windows Driver Kit 7.1.0 (build 7600.16385.1)
- pliki nagłówkowe RSA Security Inc. PKCS #11 Cryptographic Token Interface (Cryptoki) 2.20
- assembler NASM 2.08 lub kompatybilny
- gzip
- dd (nie wymieniony w Readme, ale i tak potrzebny).
Następnie upewnił się, że posiada dokładnie te same wersje, z których korzystali twórcy TrueCrypta oraz wszystkie aktualizacje, wydane przed dniem kompilacji wersji 7.1a, czyli przed 2012-02-07. Upewnił się także, że wszystkie programy zostały zainstalowane w odpowiednich ścieżkach, co również ma wpływ na końcowy wynik kompilacji a następnie uruchomił proces kompilacji w Visual Studio.
Skąd biorą się różnice
Jak możecie się domyślać, pliki wynikowe nie pasowały do pobranych ze strony TrueCrypta. Nie pasował nawet rozmiar, zatem nie było mowy o zgodności sum kontrolnych. Oczywiście różnice te mogły wynikać co najmniej z dwóch czynników – innych dat i godzin kompilacji oraz z braku identycznych podpisów cyfrowych. Xavier przystąpił zatem do analizy porównawczej plik po pliku. Zaczął od TrueCrypt.exe.
Początek skompilowanego pliku
Początek oryginalnego pliku
Jak widać, już w nagłówku pliku różnice znajdują się w trzech miejscach. Analiza wskazała, że pierwsza różnica (offset 000000F8) to znacznik czasu utworzenia pliku, druga (offset 00000148) to suma kontrolna nagłówka a trzecia (offset 00000188) to tablica certyfikatów. Wszystkie różnice w nagłówku pliku mają zatem wytłumaczenie.
Czwarta różnica pojawia się w ok. 2/3 długości pliku i jest to zapis daty kompilacji – również zrozumiały, zaś piąta różnica znajduje się na samym końcu pliku i jest to brak certyfikatu, którym podpisany był oryginalny plik. Poza tymi pięcioma różnicami plik był identyczny.
Kolejnym weryfikowanym plikiem był TrueCrypt Format.exe. Zawierał on dokładnie te same różnice co TrueCrypt.exe. Następnie analizie został poddany sterownik truecrypt.sys – tam różnic było więcej. Oprócz standardowych zmian daty i czasu pojawiły się różnice w innym miejscu pliku. Część z nich została wyjaśniona jako zmiana ścieżki źródłowej jednego z elementów kompilacji, jednak po skompilowaniu z identyczną ścieżką nadal część różnic w postaci 16 bajtów pozostała. Dalsza analiza wykazała, że powodem zmian był identyfikator GUID, generowany dla potrzeb debuggingu każdorazowo dla nowej kompilacji. Identyczne różnice znalazły się także w sterowniku dla wersji 64-bitowej.
Dla kompletu pozostał już tylko plik instalatora TrueCrypt Setup 7.1a.exe, zawierający wszystkie powyżej opisane pliki. W tym wypadku różnica – oprócz już wyjaśnionych fragmentów – wynosiła jedynie 4 bajty, które okazały się sumą kontrolną. Na zakończenie Xavier porównał jeszcze utworzone pliki z plikami oryginalnymi, pozbawionymi podpisów cyfrowych i potwierdził, że powyższe wyjaśnienia opisały wszystkie stwierdzone różnice.
Xavier przeprowadził także deasemblację obu wersji plików za pomocą MinGW-w64 i stwierdził, że jej wyniki są w 100% identyczne, zatem pliki są identyczne nie tylko na poziomie binarnym, ale także funkcjonalnym. Xavier dla porządku wykonał identyczne operacje dla wersji 7.0a oraz 6.3a i doszedł do tych samych wniosków.
Podsumowanie
W oparciu o eksperyment wzorcowo przeprowadzony przez Xaviera można stwierdzić, że pliki binarne TrueCrypta w wersji dla Windows, udostępniane obecnie na stronie projektu, zostały skompilowane z udostępnionych w tym samym miejscu źródeł. Czego zatem nie można na 100% stwierdzić:
- tego, ze zawsze udostępniane były te same pliki (chociaż tu może pomóc archive.org i inne archiwa i kopie)
- tego, że kompilator Microsoftu nie dodaje czegoś od siebie w każdym przypadku (problem zaufania do kompilatora jest jeszcze bardziej złożony)
- tego, że w kodzie źródłowym nie schowano jakiejś bardzo sprytnej tylnej furtki, której działanie nie jest oczywiste dla osób ten kod czytających (ten problem planuje rozwiązać inicjatywa audytu kodu źródłowego TrueCrypta).
Mimo tych zastrzeżeń praca Xaviera daje użytkownikom TrueCrypta całkiem sensowne poczucie komfortu i bezpieczeństwa. A jeśli ktoś nie ufa Xavierowi – zawsze może skompilować sam i podzielić się z nami wynikiem.
Podobne wpisy
- Jak jedną prostą sztuczką wyłączyliśmy przestępcom proste złośliwe oprogramowanie
- Nie tylko Polska – włamania do superkomputerów także w Niemczech i UK
- Ocena bezpieczeństwa rozwiązań IT w instytucji finansowej
- Analiza złośliwego kodu dla amatorów na świeżym przykładzie – odcinek 2
- Analiza złośliwego kodu dla amatorów na świeżym przykładzie
Ciekawe, że Snowden za żadne skarby nie chciał użyć prostego Truecrypta przy przekazywaniu materiałów dziennikarzowi tylko uparł się na „skomplikowane” PGP. Daje do myślenia.
PGP używał do korespondencji pocztowej, a do niej TrueCrypt się średnio nadaje. Z kolei Greenwald do wymiany plików Snowdena z Poitras używa właśnie TrueCrypta.
Ciekawe, jak miałby przekazać Gleenwaldowi hasło do kontenera TC nie używając czegoś a la PGP
Bitmessage.
PGP działa w oparciu o RSA, w porwaniu do TrueCrypt. Używając TC obie strony muszą znać hasła do kontenerów, a przy PGP wystarczy znać klucze publiczne.
@Kuba:
klucz publiczny nadawcy oraz prywatny odbiorcy
samymi publicznymi sobie możesz…..
@m:
Kuba prawdę powiada – szyfrujesz kluczem publicznym odbiorcy i tylko osoba posiadająca klucz prywatny może łatwo to odszyfrować. Klucze prywatne nigdy nie są wymieniane. W skrócie – zaszyfrować może każdy znający klucz publiczny, ale odczytać nie.
Nie zapominaj, że odbiorca powinien jeszcze zweryfikować autentyczność wiadomości – więc nadawca najpierw szyfruje swoim kluczem prywatnym ;]
Teraz jeszcze trzeba się wymienić kluczami publicznymi, by każdy był pewny swego. I tym sposobem wracamy do punkty wyjścia, czyli algorytmu bezpiecznej wymiany kluczy ;] Kryptografia asymetryczna, jak widać w tym wypadku nie do końca nam pomoże.
@m: idąc Twoim tokiem myślenia, najlepiej opracowany ostatnimi czasy „model biznesowy” pod tytułem CryptoLocker, nie miałby sensu.
A co jeśli program do pokazania różnicy w plikach i deasembler „pokazały” Xavierowi to co miały pokazać a nie to co jest stanem faktycznym?
Paranoja.
Porównywał binarki. Coś takiego można zrobić otwarto źródłowymi na linuxie po samodzielnej kompilacji wszystkich programów ze źródeł i robić to „na oko”, czyli samodzielnie sprawdzać każdy bit – zresztą skąd program do podglądu binarki miałby wiedzieć co pokazać?
Jak to skąd? Np. po sprawdzeniu sumy kontrolnej pliku,rozmiaru lub/i nazwy etc . pobierał by binarke do „pokazania” …
„Coś takiego można zrobić otwarto źródłowymi na linuxie po samodzielnej kompilacji wszystkich programów ze źródeł i robić to „na oko””
Ale czym kompilujesz? Tym co sam napisałeś od razu w gotowej formie? Nie sądzę.
Powiesz, że paranoja ale spójrz na to z tej strony : wystarczy, że kompilator i np. porównywarka plików robi na w trąbę i już jesteśmy w dupie.
Trzeba by było zrobić kompilator nie programy (układ scalony[zabawa z bramkami logicznymi itp.) ,który by sczytywał kod źródłowy z karty pamieci(chociaż lepiej było by bezpośrednio z klawiatury) i zapisywał gotową binarkę na drugą lub to samą karte pamięci. Ale dalej pozostaje ten problem, że jak zrobimy nawet drugi uklad to liczenia sumy kontrolnej to system może zrobić kopie tej sumy i potem podawać ją(że niby plik nie zmodyfikowany).
*kompilator nie programowy
Czyli cały system musiałby być skompilowany kompilatorem sprzętowym(ale na układzie nie może leżeć żaden mikroprocesor).
Nie słyszałem jeszcze, żeby takowy powstał.
Co jest skomplikowanego w używaniu PGP?!
Spróbuj wytłumaczyć jak używać PGP swoim rodzicom/znajomym z ASP/panu Wieśkowi z warzywniaka. Dużo ludzi z trudem po latach nauczyło się używać emaila, nie każdy ogarnie generowanie kluczy.
To dobra wiadomość. Ja nigdy nie ufałem TC choćby z tego powodu, że wydawał mi się zbyt prosty i zbyt reklamowany. Jak to napisał pewien użytkownik pewnego forum: „tak go polecacie, że aż boję się go używać”.
Pozostaje oczywiście kwestia zaufania w badania i mam nadzieję, że ktoś je zweryfikuje. Póki co do zastosowań profesjonalnych polecam GPG a TC do zastosowań domowych.
to jeszcze pytanie do czego tego TC chcemy uzywac… dla mnie jest to zabezpieczenie w przypadku gdy „zgubie” sprzet i nie chce zeby znalazca ogladal moja historie przegladarki i zdjecia z ostatnich imienin :)
naprawde macie az taka paranoje, ze akurat Waszymi mp3 i notatkami na studia bedzie interesowalo sie NSA/RSA/Interpol/DEA/Porucznik Borewicz (niepotrzebne skreslic) ?
Ha, byś się zdziwił, czym oni mogą się zainteresować, jak przypadkiem tak się złoży że studencina za parę latek zostanie ministrem, premierem albo prezydentem, jakiegoś kraju, a i może się tak złożyć że władzę USA, będą chciały wytargować od tegoż wielmoża jakąś korzystną dla nich umowę na którą on za ch….., nie będzie chciał się zgodzić, i wtedy prześwietlą naszego wielmoża, oj prześwietlą i to na wylot tak że wyciągną wszystkie jego grzeszki nawet te najbardziej, głupie i najbardziej skrywane a wtedy nasz wielmoż-studencik pomyśli oj trzeba było szyfrować dobrym programem trzeba było…
Nasz studencik, może też zostać działaczem Greenpeace, albo jakiejś innej organizacji będącej od czasu do czasu na bakier z prawem, i wtedy również można spodziewać się prześwietleń, zwłaszcza że takie hałaśliwe organizacje często są niewygodne dla wielu wpływowych ludzi.
„zatem pliki są identyczne nie tylko na poziomie binarnym, ale także funkcjonalnym.”
Skoro są identyczne na poziomie binarnym to oczywiste jest że na funkcjonalnym też. Skoro disasembler dostał identyczny plik to musiał wygenerować identyczne wyniki.