Nová analýza bezpečnosti TrueCryptu

Minulý týden rozvířil poklidné vody TrueCrypt Forum odkaz na zbrusu novou analýzu TrueCryptu (lokální kopie), kterou publikovali lidé kolem Ubuntu Privacy Remix. UPR je speciální „Live“ prostředí vytvořené tak, aby se v něm dalo bezpečně pracovat s citlivými daty; k dosažení tohoto účelu používá TrueCrypt a tudíž je pro něj zajímavé, nakolik je nebo není TrueCrypt bezpečný. To je ovšem zajímavé i pro nás, kdo TrueCrypt používáme…

Analýzu, datovanou 14. srpna 2011, vypracoval „Ubuntu Privacy Remix Team“. Podle svých slov se zabýval i staršími verzemi TrueCryptu, tyto analýzy však byly jen pro interní použití a nebyly veřejně publikovány. Teprve letošní verze, zabývající se TrueCryptem 7.0a, byla uvolněna i pro veřejnost.

Analýza má celkem jen 18 stránek, navíc je psána velmi srozumitelným jazykem, takže by s jejím přečtením neměl mít problém nikdo, kdo má aspoň základy technické angličtiny. Postupně se zabývá identifikací analyzované verze (včetně hashů zdrojových kódů), velmi stručně postupem kompilace ze zdrojových kódů a několika specifickými postupy analýzy. Následuje samotná analýza, která se kromě kryptologické síly TrueCryptu zabývá i ne-kryptologickými aspekty TrueCryptu, jako je jeho licence nebo dokumentace. Poslední čtyři stránky se týkají tématu, který mnozí považují za stěžejní – popisuje útok na keyfiles, které TrueCrypt používá, pokud si to uživatel vyžádal.

Osobně mám z analýzy poněkud rozpačitý dojem – na jednu stranu obsahuje řadu užitečných (a místy i varovných) informací, na druhou stranu však její metodiku i mnohé závěry lze velmi snadno zpochybnit. Osobně si myslím, že je dobré si analýzu prostudovat, zároveň bych ale důrazně varoval před nekritickým přejímáním prezentovaných závěrů – jak se pokusím ukázat dále, jsou podle mě spíš výstupem snahy o senzačnost než seriózního výzkumu.

Základní problém pro zprávu jako celek vidím v následujících skutečnostech:

1. Zpracovatelský tým je anonymní. My, uživatelé analýzy, nemáme žádný racionální důvod se domnívat, že autoři mají potřebné znalosti, že důsledně používali vědecké metody, že něco nezanedbali nebo nepřidali. (Pravda, ta samá námitka se dá použít proti TrueCryptu samotnému a konec konců i proti mému blogu.)

2. Jen naprosto minimální část analýzy se týká matematických principů a kryptologie jako vědy. Drtivá většina zjištění je „uživatelských“ – „vezmu blok, rozšifruji ho a když v něm uvidím něco, co se mi nelíbí, tak to označím za slabinu“. To sice výrazně zlepšuje čitelnost pro lidi, kteří nejsou kryptology, ale také to staví dosažené závěry na hliněné nohy – dá se ukázat, že mnohé z použitých předpokladů jsou přinejmenším sporné, v horším případě chybné, případně závěry nevyplývají z předpokladů.

Zdůrazňuji: Tyto problémy jsou mým závěrem, vyplývajícím z mých znalostí a mých potřeb. Důrazně doporučuji každému zájemci, aby si analýzu sám přečetl a zvážil si její důsledky sám. Moje závěry by měly sloužit pouze jako upozornění na místa, která vidím jako problematická a doporučuji je bližší pozornosti; rozhodně je neberte jako svaté zjevení, zejména pokud na tom závisí váš život nebo vaše peníze. (Totéž platí i pro další moje závěry dále v článku.)

Zdrojový a spustitelný kód, kompilace

První tři kapitoly se zabývají identifikací toho, co vlastně bylo analyzováno: TrueCrypt verze 7.0a, jednoznačně (pomocí MD5 a SHA1 hashů) byly identifikovány i balíčky zdrojových kódů (jak jsem ověřoval, Windowsové zdrojáky aktuálně dostupné na webu odpovídají). Užitečnou může být část o kompilaci, která je o něco podrobnější než oficiální  readme.txt.

Metodika

Čtvrtá kapitola se zabývá použitou metodikou. Zkoumán byl všechen společný kód a také linuxová část, windowsové části podle všeho zkoumány nebyly vůbec. Pozor na to při aplikaci závěrů i na windowsové verze – dá se sice očekávat, že kryptologická část je společná, v dalším textu analýzy se ale ukazuje, že to neplatí stoprocentně(!).

tcanalyzer

Program tcanalyzer, který si autoři napsali speciálně pro účely analýzy. Jeho účel je dvojí:

1. Rozšifrovat hlavičku TrueCryptového kontejneru podle dokumentovaných pravidel, ale nezávislým kódem, a tak ověřit, že TrueCrypt skutečně dodržuje postupy, o kterých tvrdí, že je používá.

2. Zobrazit údaje z rozšifrované hlavičky, a tak ověřit, že hlavička obsahuje to, co dokumentace tvrdí.

Pochopitelně je třeba programu sdělit heslo ke kontejneru, tcanalyzer není magický nástroj na prolomení TrueCryptu.

Výstupy analýzy

Moje komentáře k místům, která považuji za důležitá a/nebo chybná:

Licence TrueCryptu

Problematikou softwarových licencí už jsem se kdysi zabýval (Free licenci, ale kterou? 1 a 2), takže mě nepřekvapuje, že tam autoři našli určité problémy, na druhou stranu ale mám dojem, že se nechali trochu zaslepit svými přáními a obavami – TrueCrypt Licence sice opravdu není kompatibilní s GPL, to je pravda, ale nevidím v ní nic, co by ospravedlňovalo tvrzení, že „vytvoření odvozeného produktu by v případě, že TrueCrypt přestane být udržován Nadací TrueCrypt, bylo velmi problematické a dokonce nelegální“ – prostě by se TrueCrypt už nemohl jmenovat TrueCrypt, to je celé.

Web a dokumentace

Další položka nesouvisející s bezpečností per se. Tady musím dát autorům za pravdu, že autoři TrueCryptu nekomunikují, ani na dotazy, ani na návrhy ke zlepšení. Dokonce, na rozdíl od autorů studie, nemohu potvrdit ani to, že by autoři TrueCryptu reagovali na popsané bezpečnostní nedostatky. Naopak potvrzuji, že dokumentace je dobrá z technického hlediska, ale velmi v ní chybí detailní popis změn mezi verzemi.

Kryptologické algoritmy

Pozor na nepodložené závěry! Analýza bez jakýchkoliv důkazů tvrdí (poslední odstavec na str. 8), že kaskády šifer (AES-Serpent apod.) jsou bezpečnější než jednotlivé šifry. Pravděpodobně to tak je – ale pokud vím, nikdy nebyl proveden žádný formální důkaz, a je myslitelný případ, že existují případy, kdy použití kaskády celkovou sílu sníží, místo aby ji zvýšil (např. AES s jedním klíčem text zašifruje a Serpent zrovna shodou okolností použije klíč, který zašifrované zase odšifruje – ať už celé nebo část).

Podobně nepodložené je doporučení používat Serpent-AES – nic proti ani jedné z šifer, ale proč zrovna tuhle kombinaci a ne jinou?

Šifrovací režimy

Zaujalo mě, že linuxová verze TrueCryptu používá pro šifrování a dešifrování funkce kernelu, ne vlastní implementace algoritmů jako ve Windows. Vždycky jsem si myslel, že TrueCrypt používá výhradně vlastní implementace – když pro nic jiného, tak z bezpečnostního hlediska („nechceme, aby se nám TrueCrypt rozsypal jenom proto, že někdo do kernelu zatáhl chybu“). Docela mě to děsí. Polehčující okolnost (pro TrueCrypt, ne pro analýzu): Ve zdrojáku TrueCryptu se mi nedaří najít, kde by se to větvení provádělo – podle mě se vždy používá interní implementace (ať už plně softwarová nebo využívající specializované instrukce procesoru).

Kontejnery

Úvodní věta jako by se snažila podsunout uživateli, že hlavní rozdíl mezi souborovým kontejnerem, šifrovanou partition a šifrovaným celým diskem je ve „vyplýtvaném místě na disku“. Rychlost, nic? Plausible deniability, nic? Ochrana před poškozením, nic?

Generátor náhodných čísel

Analýza ukazuje triviální způsob útoku na náhodný generátor v Linuxu. O Windows mlčí, lze ale očekávat, že tam půjde použít podobný typ útoku na jiné zdroje entropie. Dobrá zpráva: Útok vyžaduje, aby měl útočník administrátorský přístup k počítači v okamžiku vytváření kontejneru (a pokud ten přístup má, tak už může na TrueCrypt zaútočit tolika způsoby, že jeden navíc nehraje roli) – a i kdyby to bylo splněno, napaden je jen jeden z několika zdrojů entropie. Ale je to zajímavé, třeba se to jednou bude hodit proti méně důkladným programům, než je TrueCrypt .

Nebyl proveden nebo aspoň zdokumentován žádný test, že (pseudo)náhodný generátor opravdu generuje (pseudo)náhod­ná čísla.

Formát hlavičky kontejneru

Popisovaný formát hlavičky odpovídá oficiální dokumentaci, s jednou podstatnou výjimkou: Analýza tvrdí, že 65024 bajtů od offsetu 512, které oficiální dokumentace popisuje jen jako „rezervováno“ bez podrobnější specifikace, je v Linuxu naplněno nulami, zatímco pod Windows náhodnými daty. Nemám to ověřeno, takže doufám, že to není pravda.

Studie tento rozdíl považuje z bezpečnostního hlediska za „problematickou“ nepříznivě pro Windows: Tvrdí, že v těchto 63,5 KiB může být uložen backdoor, například kopie hlavního klíče (resp. klíčů) zašifrovaná známým heslem, zatímco v Linuxu to tak určitě není (protože jsou tam jen nuly). Tvrdí (bez důkazů), že nelze ověřit, zda byla binární verze TrueCryptu zkompilována z publikovaných zdrojáků, a doporučuje jako ochranu proti tomuto případnému backdooru zkompilovat si TrueCrypt ze zdrojáků.

Několik komentářů:

1. Vyplnění prázdného místa náhodnými čísly je kryptologicky bezpečnější než vyplnění nulami, protože poskytuje útočníkovi méně informace: dává mu pouze šifrovaný text, ne šifrovaný text a zároveň odpovídající otevřený text, a navíc zajišťuje odlišný obsah u různých kontejnerů, i kdyby měly všechno ostatní totožné.

2. Nesouhlasím s tvrzením, že nelze binárku TrueCryptu validovat proti zdrojovým kódům. Ano, nelze dosáhnout stoprocentní shody, protože TrueCrypt svoje binární soubory podepisuje (tzn. kdyby nic jiného, tak se bude lišit podpis), ale to nijak neovlivňuje možnost zkontrolovat shodu kódu (podpis je „připlácnutý“ za kód, ten však není podpisem ovlivněn).

3. Nesouhlasím s tvrzením, že ochranou je kompilace ze zdrojáků. Důvody viz článek Open-source a backdoory.

4. Analýza neříká nic o tom, jestli v této oblasti backdoor je nebo není. Tvrdí, že tam být může. A v tom má naprostou pravdu.

Každopádně bude dobré podívat se na tuto „podezřelou oblast“ podrobněji, až na to budu mít chvilku, a speciálně na důvody, proč se to v Linuxu vyplňuje jinak než ve Windows.

Útok na keyfiles

Asi nejsenzačnější část studie se zabývá „útokem na keyfiles“. Popisuje postup, jak jsou keyfiles zpracovávány, a ukazuje, že je poměrně snadné už dopředu zmanipulovat „potenciální keyfile“ tak, aby neměl žádný efekt, kdyby byl jako keyfile skutečně použit. Nechci se pouštět do detailního popisu, ale velmi zjednodušeně řečeno: K existujícímu souboru lze připojit krátký (maximálně necelé 3 KB) a snadno zkonstruovatelný „přílepek“, který způsobí, že se soubor při použití jako keyfile bude chovat zcela neutrálně – jako kdyby vůbec použit nebyl. Výsledkem je, že kontejner lze dešifrovat i bez tohoto keyfile, pouze se znalostí hesla.

Autoři studie argumentují, že útočník by mohl předběžně vytipovat soubory, které by potenciální oběť mohla chtít používat jako keyfiles. Následně by mohl připravit vhodného trojského koně, aby soubory tohoto typu „sterilizoval“: Pokud by například šlo o obrázky, mohl by nabídnout oběti (resp. veřejnosti jako celku) editor nebo prohlížeč, který by dělal všechny očekávané operace, ale navíc by ke všem zpracovávaným souborům přidal „neutralizační přílepek“.

Protože tato „sterilizace“ je možná jenom díky tomu, že TrueCrypt trochu nepochopitelně používá v příslušné fázi zpracování keyfile jenom CRC32 a ne silnější hashovací funkci, hodnotí to autoři jako bezpečnostní slabinu v TrueCryptu a doporučují opravu (použít místo toho SHA-512 nebo Whirlpool).

Autoři TrueCryptu na toto doporučení zareagovali zhruba ve smyslu, že to není bezpečnostní chyba, protože jakmile oběť dovolí útočníkovi, aby manipuloval její soubory, dostává se do obdobné situace, jako kdyby mu dovolila, aby manipuloval s vytvářenými hesly nebo klíči. Fakticky jde o porušení podmínek fyzické bezpečnosti, které TrueCrypt vyžaduje pro svoji funkci, a tudíž je to čistě problémem uživatele.

Analýza pochopitelně stojí za svým, že útok je praktický a je třeba ho opravit.

Osobně si myslím, že pravdu mají obě strany: TrueCrypt naprosto správně poukazuje na to, že bezpečnost šifrování stojí na určitých předpokladech, z nichž jedním je plná kontrola uživatele nad šifrujícím systémem, a pokud tyto předpoklady nejsou splněny, existuje tolik vektorů útoku, že nemá smysl bránit se proti jednomu specifickému z nich – zvlášť když obrana fakticky neřeší příčinu, ale jen následek.

Na druhou stranu zjištění Ubuntu Privacy Remix Teamu nelze brát úplně na lehkou váhu: Jejich útok je natolik snadno proveditelný (jako příklad uvádějí digitální fotoaparát, který rovnou produkuje „sterilizované“ snímky) a natolik realistický (kolik uživatelů použije prostě několik svých fotek, místo aby vygenerovali skutečně náhodný keyfile?), že má pro útočníka smysl ho zkusit. Pokud tomu TrueCrypt může zabránit, proč to neudělat?

Uvidíme, jestli na to vývojáři TrueCryptu zareagují v příštích verzích programu. Prozatím bych doporučoval: Za prvé, vždy používejte silné heslo, i tehdy, když ho doplňujete keyfilem. Za druhé, pokud už nemůžete použít úplně náhodný keyfile (TrueCrypt vám ho může vygenerovat!!), zkuste k němu ručně přidat několik znaků, abyste aspoň částečně narušili případnou „sterilizaci“.

Výstupy analýzy

Z několika důvodů si nemyslím, že studie má takovou váhu, jak by mohlo vypadat z její formulace a z reakcí na diskusním fóru TrueCryptu. Ať už je to nulová informace o autorech studie nebo dílčí (i větší) nedostatky v argumentaci, je dost důvodů, proč ji nebrat úplně vážně.

Současně ale uznávám, že některá její zjištění jsou poměrně závažná: útok na keyfiles podle všeho je prakticky realizovatelný, i když snad není vysloveně na zodpovědnosti TrueCryptu mu bránit. Mě osobně jako nejhrozivější připadá rozdíl mezi výplní v linuxové a windowsové verzi TrueCryptu (pokud opravdu existuje – nechce se mi tomu věřit), ať už jde o slabinu linuxové verze (vytváření známého otevřeného textu pro útočníka) nebo windowsové (teoreticky to skutečně může být i maskování backdooru).

Jedním pozitivním výsledkem studie, který už se projevil, bylo vyčištění dokumentace TrueCryptu v sekci o zpracování keyfiles – teď už je tam výslovně uvedeno, že se používá konkrétně CRC32 (ne jenom „hashovací funkce“, což mohlo vést k mylným závěrům, že se používá kryptologicky bezpečná šifrovací funkce).

Dalším užitečným výstupem je informace, že TrueCryptovská implementace šifer a šifrovacích režimů je kompatibilní s dalšími implementacemi. Pokud by se podařilo doložit, že tyto „další implementace“ jsou zároveň „nezávislé na TrueCryptu“, byl by to velmi výrazný signál o tom, že TrueCrypt implementuje kryptologické principy správně.

Třetí pozitivum: Studie sděluje svoje závěry velmi srozumitelným jazykem, a stejně srozumitelným jazykem sděluje i svoje doporučení, která jsou ve většině případů dobrá.

Čtvrté velmi malé pozitivum: Máme další studii, která nenašla v TrueCryptu žádný backdoor. Nevíme ovšem nic o tom, kdo tu studii napsal – klidně to mohli být i sami vývojáři. 

V každém případě doporučuji přečtení analýzy všem, kdo chtějí používat TrueCrypt bezpečně. I přes své chyby nabízí dostatek materiálu, který je dobré znát.

Článek byl původně napsán pro blog Pepak.net.