Šifrované Souborové Systémy V Linuxovém Jádře

Masarykova Univerzita Fakulta informatiky

Šifrované souborové systémy v linuxovém jádře

bakalářská práce

Antonín Víteček

Brno, 2008 Prohlášení

Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

V Hustopečích dne 20. května 2008 …...... Poděkování

Děkuji Mgr. Václavu Lorencovi za pomoc, vstřícnost, trpělivost a odbornou pomoc při vedení této práce. Děkuji také svým blízkým za podporu a pochopení při vypracování bakalářské práce. Shrnutí

Práce zachycuje současný stav nástrojů pro šifrování metodou OTFE pod operačním systémem GNU/Linux. Zabývá se bezpečností konkrétní implementace nástroje TrueCrypt 4.3a. V závěru pak shrnuje nejnovější poznatky o útocích na tyto nástroje.

Klíčová slova

TrueCrypt, Dm-Crypt, Device-mapper, Linux, Coldboot, Kryptografie, CryptoAPI Obsah

1 Úvod...... 6 2 Principy a popis použitých pojmů...... 7 2.1 Kryptografie – Šifrování...... 7 2.2 Implementace šifrování ...... 9 2.3 Kernel – jádro...... 10 2.4 Soubory v Linuxu...... 11 2.5 Devicemapper...... 11 2.6 VFS – The Linux Virtual File Systém ...... 12 3 Přehled šifrovacích nástrojů, jejich historie a současnost...... 13 3.1 LoopAES...... 13 3.2 Cryptoloop...... 14 3.3 DmCrypt...... 14 3.4 DmCrypt LUKS...... 15 3.5 TrueCrypt 4.3a...... 15 3.6 TrueCrypt 5.x...... 16 3.7 ScramDisk for Linux...... 16 3.8 EncFS...... 17 3.9 CryptoFS...... 18 3.10 CryptFS a NCryptFS...... 18 3.11 eCryptFS...... 19 3.12 CFS...... 19 3.13 TCFS...... 20 4 Bezpečnostní analýza TrueCryptu...... 21 4.1 Analýza Vlastimila Klímy...... 21 4.2 Naše analýza...... 21 4.2.1Obslužná utilita...... 22 4.2.2Modul Linuxového jádra...... 23 4.2.3Popis funkcí jednotlivých částí modulu...... 24 4.3 Zjištěné problémy...... 26 4.4 Nová hrozba...... 27 4.5 TrueCrypt a CryptoAPI...... 27 5 Závěr...... 29 6 Literatura...... 30 7 Přílohy...... 32 7.1 truecrypt.patch...... 32 1 Úvod

Článek sedm listiny základních práv a svobod, který je součástí ústavy České republiky říká: ”Nedotknutelnost osoby a jejího soukromí je zaručena. Omezena může být jen v případech stanovených zákonem.” [1] Tato listina má přirozeně právní původ. Vychází z přirozených potřeb člověka.[2] V českém jazyce slovo soukromí zahrnuje také schopnost, či právo zadržovat informace o sobě.[3] Lze tedy pozorovat, že soukromí je něco, co chceme přirozeně chránit. V současné době jsme při své práci a ve svém soukromém životě stále více závislí na využívání nejrůznějších elektronických zařízení typu mobilní telefon, počítač (notebook), PDA aj. A stejně tak jako člověk při své činnosti zanechává známky opotřebení na nástrojích, které používá. I my zanecháváme známky používání na těchto zařízeních. Navíc jsme si zvykli těmto zařízením důvěřovat a svěřovat jim naše soukromá data. Díky této důvěře pak v těchto zařízeních vzniká náš informační otisk, naše informační dvojče. Je tvořeno například historií navštívených stránek, soukromou a pracovní e-mailovou komunikací, historií rozhovorů v IM (instant messanger), našimi dokumenty, ale třeba i našimi plány do budoucna v podobě Google Calendar. [59] Je-li dvojče opravdu kvalitní, má povědomí také o většině našich hesel, která jsme kdy zadali, protože se nám snaží ulehčit práci a ochotně si je pamatuje. Pokud se ho později správně ptáme, podrobně nám odpovídá, protože má mnohem lepší paměť než my. Bohužel i přes to, že toho o nás tolik ví a zná, nedokáže úplně spolehlivě rozlišit, zda se se ho ptáme právě my, nebo někdo úplně cizí. Dostáváme se do situace, kdy různá elektronická zařízení obsahují uložena naše citlivá soukromá data v nijak nechráněné, čitelné podobě. S přihlédnutím k pokračujícímu trendu mobilizace a miniaturizace bychom se měli zamyslet nad tímto stále narůstajícím nebezpečím. Útočníkovi stačí chvilka naší nepozornosti při tlačenici v MHD a zmocní se notebooku i s naším bezbranným informačním dvojčetem, ochotným vypovídat. Jen těžko si představit, že by to byl právě případ narušení našeho soukromí stanovený zákonem. Tato bakalářská práce seznámí čtenáře s nástroji pro šifrování dat v operačním systému Linux, jako prostředek ochrany proti offline útokům zaměřeným na získání citlivých dat. Popisuje jejich historický vývoj, současný stav a zhodnocuje výhody a nevýhody jednotlivých řešení. Zejména s přihlédnutím k nástrojům TrueCrypt a Dm-Crypt, jejich implementaci a možným bezpečnostním problémům. Druhá kapitola je zaměřena na obecný přehled pojmů užitých v této bakalářské práci, usnadňujících pochopení probíraného tématu. Třetí kapitola nabízí obecný přehled nástrojů, historický vývoj a jejich současný stav. Čtvrtá kapitola se sestává z analýzy zdrojového kódu a popisu fungovaní modulu TrueCrypt 4.3a. Zaměřuje na možné způsoby kompromitace tohoto nástroje ve světle nejnovějších výzkumů. Pátá kapitola shrnuje tuto práci a nabízí možné směry dalšího zkoumání. 2 Principy a popis použitých pojmů

V následujících několika odstavcích se pokusím vysvětlit několik pojmů usnadňujících další pochopení a porozumění textu.

2.1 Kryptografie – Šifrování Kryptografie[4] je věda, která se zabývá metodami utajení sdělení do formy, která je smysluplná pouze se speciální znalostí tzv. klíče. Proces transformace prostého textu do podoby nesrozumitelné, se nazývá šifrování. Algoritmus, kterým proběhla transformace se nazývá šifrovací algoritmus a produktem je šifrovaný text. Proces opačný, kdy z šifrovaného textu, za pomocí klíče získáme text původní, nazýváme dešifrování. Moderní kryptografické algoritmy se řídí Kerchkoffovým pravidlem:“Pouze bezpečnost klíče je bezpečnost systému.“, nebo Shannonovou verzí:“Nepřítel zná tvůj systém.“ V momentě kdy se snažíme před útočníkem utajit fungování systému a bezpečnost systému závisí na této neznalosti, nazývá se toto anglickým termínem security through obscurity. Kryptografické algoritmy můžeme dělit do tří základních skupin. Asymetrické a symetrické algoritmy a hašovací funkce[57]. Asymetrické algoritmy, někdy též nazývané algoritmy s veřejným klíčem pracují s párem klíčů. Veřejným klíčem se data šifrují a soukromým klíčem se data dešifrují. Veřejný klíč může být bez obav zveřejněn na Internetu. Ze znalosti veřejného klíče totiž není možné odvodit klíč soukromý a data zašifrovaná veřejným klíčem lze dešifrovat pouze soukromým klíčem. Chceme-li tedy někomu poslat zašifrovanou zprávu, zašifrujeme ji pomocí veřejného klíče cílového subjektu. A po obdržení ji cílový subjekt dešifruje pomocí svého soukromého klíče. Problém u asymetrického šifrování spočívá v náročnosti výpočtů. Asymetrické klíče mají řádově větší délku a práce s nimi je dosti výpočetně náročná. Dalším problémem je ověření pravosti, zda veřejný klíč opravdu náleží požadovanému cílovému subjektu, kterému chceme poslat šifrovanou zprávu. V momentě kdy by nám útočník podstrčil svůj veřejný klíč jako veřejný klíč cílového subjektu a my jím data zašifrovali, útočník by si zprávu pohodlně rozšifroval svým soukromým klíčem. Symetrické algoritmy pracují pouze s jedním klíčem. Data jsou tímto klíčem zašifrována a stejný klíč se používá k dešifrování. Symetrické šifrování je výpočetně méně náročné než asymetrické a dalo by se tedy říci, že poměrně rychlé. Je však problém jak si bezpečně vyměnit sdílený šifrovací klíč. Buď se pro výměnu používá jiný zajištěný kanál, jako například telefon. Nebo vstupuje do hry opět asymetrická kryptografie a sdílený klíč je vyměněn její pomocí. V praxi to pak vypadá tak, že zpráva je zašifrována symetrickou šifrou. Klíč je zašifrován pomocí veřejného klíče příjemce a je mu odeslán spolu se zprávou. Příjemce si pak pomocí soukromého klíče dešifruje symetrický klíč a pomocí něj dešifruje obsah zprávy. Symetrické šifry dále dělíme na blokové a proudové. Proudové šifry zpracovávají data bit po bitu. Blokové šifry si data nejdříve rozdělí do bloků o určitém počtu bitů a poté pracují s těmito bloky jako s celky. V případě že velikost vstupních dat není násobkem velikosti bloku, je nutno přistoupit k různým technikám pro zarovnání dat na násobek velikost bloku. Pro konkrétní vstup a konkrétní klíč produkují symetrické šifry vždy stejný výstup. Což nám u blokových šifer trochu komplikuje situaci. Pokud vezmeme dlouhou zprávu, ve které se opakují nějaké údaje, například jména, bude se ve výsledné zašifrované zprávě na stejných pozicích opakovat bitové vzorky, což jistým způsobem vyzrazuje obsah zprávy. Jako ochrana proti této slabině se u blokových šifer používají různé režimy práce - modusy. Modusy blokových šifer zajišťují, že pokud se ve vstupu opakují nějaká data, nevede to opakovaně ke stejnému výstupu a je tak zajištěno utajení obsahu zprávy. Výjimkou je modus ECB (Electronic Codebook). Oázek č. 1, který je zašifrován pomocí ECB nádherně ilustrují nedokonalost tohoto režimu.

Obrázek č. 1

Na dlouhou dobu se stal nejrozšířenějším modusem CBC (Cipher Block Chaining). Zpracovává každý sektor zvlášť a u každého používá nový inicializační vektor. Inicializační vektor je dodatečný náhodný vstup modusu, o velikostí shodné jako je velikost bloku šifry, díky kterému je zajištěna jedinečnost zašifrovaných dat i při použití stejného šifrovacího klíče. Tedy bez inicializačního vektoru by dva shodné vstupy vždy produkovaly shodný výstup. Princip CBC je znázorněn na obrázku č. 2 a 3. Na blok vstupního textu je provedena operace XOR[5] s předchozím zašifrovaným blokem. Jedinou výjimku tvoří první blok, který je takto zpracován s inicializačním vektorem. Dešifrování probíhá obdobně, blok šifrovaného textu je dešifrován a je provedena operace XOR s předchozím blokem zašifrovaného textu. Výjimku opět tvoří první blok, který je dešifrován a poté je provedena operace XOR s inicializačním vektorem. Modus CBC však není také dokonalý a trpí různými bezpečnostními neduhy, plynoucími zejmé- na z nenáhodného inicializačního vektoru. Proti těmto zranitelnostem byly vyvinuty různé metody ge- nerování inicializačního vektoru, jako například mód ESSIV, kdy je IV generován z čísla sektoru a soli – dodatečného náhodného vstupu. Při použití CBC musí šifrování probíhat serializovaně, dešifrovat však lze souběžně. Obrázek č. 2 znázorňující šifrování modusem CBC

Obrázek č. 3 znázorňující dešifrování modusem CBC

LRW (Liskov, Rivest, Wagner) se od CBC liší tím, že již nebere sektory v potaz a pracuje s každým blokem jednotlivě. Pokud se útočník pokusí vyměnit nějaký blok, jsou při dešifrování obdržena nesmyslná data. Tento modus při své činnosti používá dva klíče. Klíč blokové šifry se nazývá primární a druhý klíč sekundární o délce 128 bitů. Sekundární klíč je modifikován v závislosti na indexu bloku. Takto získaná hodnota se nazývá tweak. [35] Prozatím nejmodernější modus blokových šifer je XEX a na jeho principu založený XTS. Tyto modusy jsou již používány novějšími verzemi šifrovacích nástrojů. Jedinou slabinou, která je u těchto nástrojů známá je tzv. minor leak. Útočník je schopen na základě změny šifrovaného textu detekovat, v kterém bloku otevřeného textu proběhla změna. I proti této slabině se dá bránit, cena operací navíc již však není úměrná zvýšení bezpečnosti. Hašovací funkce [6] je funkce, která převede vstup jakékoliv velikosti na řetězec konstantní délky nazývaný haš nebo otisk. Haš je jakousi reprezentací vstupu. A změna i jediného bitu ve vstupu by měla zapříčinit podstatnou změnu haše. Z kryptografického hlediska by bezpečná hašovací funkce měla navíc splňovat tyto dvě vlastnosti. Pokud známe haš, tak by mělo být složité najít vstup, který má právě tento haš. A pokud známe zprávu a její haš, mělo by být složité najít jinou zprávu, která by měla stejný haš. Hašovací funkce se používá na mnoha místech například pro uložení hesel, pro ověřování integrity souborů, jako otisk u digitálně podepsaných zpráv nebo pro indexaci a vyhledávání souborů v sítích P2P (Peer-to-Peer).

2.2 Implementace šifrování Výše zmíněné kryptografické algoritmy a funkce můžeme různě implementovat. Právě implementace bývá často kámen úrazu, kdy jinak bezpečný a ověřený algoritmus je nevhodně použit a útočník je schopen ho kompromitovat. Implementovat můžeme buď přímo na hardwarové úrovni, nebo implementaci na úrovni softwaru. Mezi hlavní výhody hardwarové implementace patří vysoká rychlost a možnost integrace do zařízení s omezenými výpočetními schopnostmi. Nás zajímá zejména implementace hardwarového šifrování do řadiče pevného disku, které nabízejí některé firmy. Z našeho pohledu je taková hardwarová implementace nevhodná z několika důvodů. Ve většině případů se jedná o proprietární řešení a jako uživatelé nemáme možnost ověřit, že implementovaný mechanismus je korektní a opravdu správně šifruje. Není vyloučeno, že se jedná pouze o security through obscurity a nezbývá než věřit slovu výrobce. Další problém může nastat v okamžiku hardwarové závady, kdy bez přesně stejného řadiče nejsme schopni číst data z disku. Softwarová implementace se jeví mnohem lépe. Nedosahuje sice takového výkonu jako hardwarová, ale v dnešní době výkonných procesorů se tento rozdíl stává stále zanedbatelnějším. Nespornou výhodou softwarové implementace pak bývá dostupnost zdrojových kódů, kdy je nám uživatelům umožněno zkontrolovat si korektnost proklamovaných a ve skutečnosti použitých mechanismů. Při objevení nějakých bezpečnostních problému stávajícího řešení, jsme pak schopni bez velkých problému vyměnit řešení za jiné. V dalším textu bakalářské práce se zaměříme výhradně na softwarové implementace šifrovacích nástrojů s dostupnými zdrojovými texty. Přičemž je můžeme rozdělit do dvou skupin. Nástroje šifrující na úrovni blokového zařízení a nástroje šifrující na úrovni souborového systému.

2.3 Kernel – jádro Je základem každého operačního systému. Funguje jako prostředník mezi hardwarem počítače a jeho softwarovým vybavením. Plánuje a přiděluje strojový čas procesům, přiděluje jim paměť a obsluhuje vstupně-výstupní operace. Aplikace využívají služeb jádra voláním systémových volání. V rámci této bakalářské práce pak pod pojmem kernel – jádro myslíme konkrétně jádro Linux řady 2.6, které je dostupné v podobě zdrojových textů ze stránek http://www.kernel.org/. Vývojáři jádra zveřejňují různé patche, což jsou textové soubory popisující změnu zdrojového kódu, které opravují chybu nebo přidávají jistou funkcionalitu. Linuxové jádro je monolitické. [8] Veškerý kód jádra sdílí stejný paměťový prostor. Dodatečné funkce, ovladače či jiné části jádra, lze kompilovat v podobě modulů a nahrávat je až v momentě potřeby. Šetříme tak paměť, která by jinak byla zabrána nepoužívaným kódem. Pokud je však při bootování, tedy při startování systému, potřeba nějaké funkcionality, která je zkompilována jako modul - ovladač disku, souborový systém použitý na kořenovém adresáři. Musí být vytvořen takzvaný initial ramdisk – initrd [9]. Jedná se o dočasný souborový systém obsahující potřebné moduly, aby byl umožněn start systému. Jádro se sestává z několika subsystémů, přičemž každý subsystém má na starosti určitou množinu úkolů, která je logicky celistvá. Například subsystém pro správu paměti, subsystém pro práci se souborovými systémy nebo například subsystém pro práci s kryptografickými algoritmy – tzv. CryptoAPI. CryptoAPI nabízí tři druhy manipulace se vstupními daty - transformace. hašovací funkce, šifrovací algoritmy a komprimační algoritmy. CryptoAPI sjednotilo v jádře přístup k šifrovacím funkcím a subsystémy užívající šifrování nemusí již pokaždé implementovat požadovanou šifru, ale stačí standardně využít volání služeb jádra. Díky tomu můžeme tvořit malé programy nenáročné na paměť. Protože je API součástí jádra, lze jeho služeb využívat v průběhu bootování.

2.4 Soubory v Linuxu Jedno ze základních pravidel unixových systémů, které do jisté míry přebral i Linux říká, že na všechno je nahlíženo jako na soubor a je s tím takto i pracováno. V Linuxu existuje několik různých typů souborů. Adresáře, speciální soubory, odkazy, sockety a pojmenované roury. Speciální soubory reprezentují hardwarová zařízení a mohou být bloková nebo znaková. Tyto soubory představují ovladače zařízení a pomocí těchto souborů komunikuje Linux se zařízeními. Bloková zařízení jsou disky a požadavky jsou zpracovávány v dávkách – blocích. Znaková zařízení jsou například terminály a tato zařízení komunikují znak po znaku. Některé ze speciálních souborů však nereprezentují přímo reálné zařízení, ale plní pouze specifický účel. Takové soubory nazýváme pseudo-zařízení. Nejznámější pseudo-zařízení je /dev/null známé jako „černá díra“. Cokoliv do tohoto souboru zapíšeme, přestane existovat. Při čtení je pak soubor vždy prázdný. Loop device [10] je pseudo-zařízení, které plní pouze funkci jakési smyčky, přes kterou prochází data. Podstatná je však bloková povaha tohoto pseudo-zařízení. Čtení a zápis do tohoto speciálního souboru probíhá v blocích, obdobně jako blokové operace u diskových zařízení. Tato vlastnost nám umožňuje přistupovat k obsahu souboru, jakoby se jednalo o diskové zařízení a také s ním tak pracovat. Této vlastnosti využívají některé šifrovací nástroje uvedené v kapitole č. 3, které si takto namapují soubor jako disk a šifrování probíhá při průchodu dat tímto zařízením.

2.5 Device-mapper Jedná se o novou komponentu jádra řady 2.6. Původně byl vyvinut pro LVM 2 (Linux Volume Management) [11], což je nástroj pro správu logických disků. V průběhu času se ukázalo, že ho lze využít i pro jiné účely, například pro šifrování. Sám název napovídá, co tato komponenta dělá – mapuje zařízení. V popisu práce má převádět operace s nějakým blokovým zařízením na operace s jiným blokovým zařízením. Například při práci s LVM mapuje bloky a sektory logické jednotky na jednotlivé fyzické disky, přes které je logická jednotka rozprostřena. Z uživatelského hlediska je tato operace transparentní a plně v režii device-mapperu. Mezi další schopnosti device-mapperu patří například vytvoření zapisovatelného snímku existujícího blokového zařízení. Obrázek č. 4 - Schéma device-mapperu [58]

2.6 VFS – The Linux Virtual File Systém Je abstraktní vrstva Linuxového jádra [12], pomocí které Linux přistupuje k různým souborovým systémům za užití jednotného API. Každý souborový systém musí implementovat množinu základních operací jako je například vytvoření, otevření, uzavření souboru atp. VFS si drží v paměti pro každý použitý souborový systém množinu těchto operací. Představme si modelovou situaci a chtějme otevřít soubor zavoláním systémového volání open(). Vrstva VFS v tomto momentě vyhledá patřičnou implementaci v závislosti na tom, na jakém souborovém systému hodláme soubor otevřít a zavolá ji. Souborový systém [13] je označení pro způsob organizace dat na disku. V terminologii VFS je to pak struktura operací implementujících přímo nízkoúrovňovou práci s diskem. Díky této abstrakci máme možnost celkem jednoduše doimplementovat nový souborový systém jako modul a dynamicky ho nahrávat podle potřeby. Implementace souborového systému se nejprve zaregistruje u Linuxového jádra a naplní požadované struktury operací. Abychom mohli pracovat s obsahem nějakého disku, je nejprve nutné ho přimountovat. Přimountováním/připojením disku se rozumí zavolání příkazu mount s patřičnýmy parametry. Tedy jaký souborový systém, na jakém zařízení, se má přimountovat/připojit do jakého adresáře. Případně je možno přidat další nastavení dle druhu souborového systému. Příkaz mount zajistí, že ukazatele na operace v připojeném adresáři ukazují na konkrétní implementaci patřičného souborového systému. 3 Přehled šifrovacích nástrojů, jejich historie a současnost

Začne-li se někdo zajímat o nástroje na šifrování metodou OTFE (On-the-fly encryption), [14] může být snadno zahlcen a dezorientován velkým množstvím dostupných nástrojů. Pro snazší orientaci a jako přehled této oblasti nám poslouží právě tato kapitola, která popisuje nejvýznamnější zástupce a rozdíly mezi nimi.

3.1 Loop-AES Prvním představovaným je projekt loop-AES [15]. Náleží do skupiny nástrojů šifrujících na úrovni blokového zařízení a tímto blokovým zařízením je loop device. V situaci kdy není použito loop-AES a disk je namountován pomocí příkazu mount do stro- mové struktury. Jsou veškeré požadavky na čtení a zápis uvnitř přimountovaného podstromu předávány ke zpracování linuxové vrstvě VFS. VFS dále zajistí zpracování požadavku korektním souborovým systémem a souborový systém fyzicky přistupuje k diskovému zařízení. Je-li použito loop-AES je nejdříve nutno pomocí nástroje losetup asociovat k loop device soubor, nebo disk. Jako parametry jsou losetupu předány hašovací funkce a použitý šifrovací algoritmus. Poté lze loop device namountovat stejně jako normální disk. V tomto momentě jsou požadavky na čtení a zápis opět předány VFS a dále pak souborovému systému. Rozdíl je v tom, že souborový systém fyzicky nepracuje přímo s diskem, ale s loop device. Loop device je stěžejní bod loop-AES. Právě při zpracování požadavků uvnitř loop device procházejí data procesem šifrování/dešifrování a loop device fyzicky přistupuje k losetupem asociovaným zařízením. Díky loop device jsme schopni přimountovat nejenom blokové zařízení jako je disk, ale i obyčejný soubor. S obsahem souboru je pak pracováno v blocích stejně jako s blokovým zařízením a souborový systém pracuje s tímto poskytovaným virtuálním blokovým zařízením. Loop-AES je dostupný jako modul nebo patch pro linuxové jádro, vyvíjený Jari Ruusuem. Nahrazuje v jádru funkci loop device, aby v něm mohlo probíhat šifrování. Lze jej používat s jádry řady 2.x, 2.2.x, 2.4.x, 2.6.x. I přes to, že je poměrně starým nástrojem z našeho přehledu, první verze vyšla 11. 4. 2001 [16], je stále udržován a aktualizován. Archiv obsahuje i nezbytný patch pro obslužné utility mount, umount, losetup, swapon a swapoff. V současné verzi lze šifrovat algoritmy AES, twofish, blowfish a serpent. Pro procesory x86 a AMD64 je také dostupná optimalizovaná assemblerovská implementace algoritmu AES a MD5, což snižuje negativní dopad na výkon při práci s šifrovaným diskem. Šifrování algoritmem AES používá modus CBC a jsou dostupné tři režimy práce s klíči, přičemž je doporučenou používat poslední jmenovaný[17]: 1. single-key – na šifrování všech sektorů loop device je použit IV (inicializační vektor) a jeden klíč. Tento režim trpí slabostí proti watermark útokům 2. multi-key-v2 – IV je vypočítán pomocí MD5, sektory jsou šifrovány 64 klíči, první sektor prvním klíčem, druhý sektor druhým klíčem, atd. 3. multi-key-v2 – stejný jako multi-key-v2, navíc však slouží 65. klíč jako další vstup pro výpočet IV Loop-AES umí šifrovat nejen swap oddíl, ale s vhodným initrd zvládá i šifrování kořenového adresáře. Jedná se o vyzrálý kus softwaru s dobrou dokumentací, jeho autor Jari Ruusu také aktivně pomáhá a řeší problémy v mailových konferencích.

3.2 Cryptoloop Tento projekt [18] spadá také do kategorie nástrojů šifrujících na úrovni blokového zařízení loop device. Pro jádra řady 2.4 je dostupný jako patch a řady 2.6 je přímou součástí. Jeho implementace byla do jádra zařazena 02. 07. 2003 [19] Cryptoloop pracuje na stejném principu jako loop-AES. Na rozdíl od něj však šifrování není implementováno přímo v modulu, ale bylo vyčleněno do nového jaderného subsystému CryptoAPI a probíhá voláním služeb tohoto subsystému. Stejně jako u předchozího nástroje, i Cryptoloop potřebuje ke své činnosti pozměněné utility losetup, mount, umount, swapon a swapoff. Tyto však nejsou kompatibilní s upravenými utilitami loop-AES a není tedy možno je používat současně. Umožňuje také šifrovat soubor, swap oddíl, diskový oddíl nebo i kořenový adresář. Navzdory své velké popularitě a značnému rozšíření, trpí Cryptoloop již od svého počátku několika bezpečnostními problémy. Tyto problémy nejsou kryptografického rázu, ale plynou z nevhodného použití šifrovacích a hašovacích algoritmů, tedy problémy implementační. Cryptoloop není například odolný proti watermark a plaintext [20,21] útokům. Jari Ruusu, autor modulu loop-AES, na tyto skutečnosti několikrát upozorňoval v linux-crypto mailing listu [22]. Jeho e-maily se však i přes jeho velkou trpělivost nesetkaly u vývojářů Cryptoloopu s příznivou reakcí ani s očekávaným efektem nápravy [23]. Cryptoloop byl tedy spíše z politických důvodů [24] ponechán v jádře 2.6 a byl označen jako „deprecated“ (zastaralý, neudržovaný, určený k odstranění) Je doporučeno používat například jeho nástupce Dm-Crypt popsaného na následujících řádcích.

3.3 Dm-Crypt Dm-Crypt [25] je linuxový modul a další zástupce z rodiny nástrojů šifrujících na úrovni blokového zařízení. Tímto zařízením však není loop device, jak je tomu v předchozích příkladech, ale novinka v jádrech od verze 2.6.4, device-mapper. Jak bylo zmíněno, Dm-Crypt je doporučovaným následníkem Cryptoloopu. První verze vyšla 11. 3. 2004. Protože je však zpětně kompatibilní, trpí stejnými bezpečnostními problémy jako on. S postupem času byly doimplementovány nové modusy (2.6.10 – ESSIV, 2.6.20 – LRW, 2.6.24 – XTS) [26], které již nejsou náchylné na tento druh útoků. Dm-Crypt je čistší a přímější implementace než nástroje používající loop device. Je totiž lépe navržen přímo pro práci s blokovými zařízeními. Při své činnosti používá tzv. mempoools [27], což jsou předem alokované paměťové stránky. Díky tomu dosahuje v porovnání s Cryptoloopem mnohem větší stability[28], ale netrpí ani náchylností k deadlocku při namapování na soubor. [29] Šifrování je prováděno pomocí volání služeb CryptoAPI a velkou výhodou u tohoto řešení je, že již není třeba instalovat pozměněnou verzi utilit mount, umount atd. Nastavení a ovládání probíhá pomocí utilit dmsetup, cryptsetup a cryptmount. 3.4 Dm-Crypt LUKS V tomto případě se nejedná o nový nástroj, ale pouze o jisté vylepšení předchozího. V současné době lze pro Dm-Crypt využít dva diskové formáty. Původní nativní formát a nebo nový kontejnerový formát LUKS [30]. Linux Unified Key Setup je formát vyvíjený Clemensem Fruhwirtem. Má volně dostupnou specifikaci a vzorovou implementaci, která byla poprvé zveřejněna 5. 2. 2005. Formát LUKS nabízí použití až osmi různých hesel pro přístup k šifrované jednotce. Tato hesla jsou na sobě nezávislá a lze je i revokovat bez nutnosti přešifrovat znovu celou jednotku. Což u všech předchozích nástrojů nebylo možné. Můžeme tedy sdílet šifrovanou jednotku mezi více uživateli bez nutnosti sdílet heslo. Protože se jedná o kontejnerový formát, usnadňuje uživatelům práci s jednotkou. Informace o použitých šifrách, hašovacích funkcích a modusech blokové šifry jsou přímo uloženy v hlavičce šifrované jednotky. Uživatel si tyto informace nemusí tedy pamatovat a zadává pouze heslo. Ovládání a nastavení šifrovaných jednotek LUKS se provádí pomocí nástroje cryptsetup-luks. Díky projektu FreeOTFE[31] lze jak s kontejnery LUKS, tak i Cryptoloop jednotkami pracovat v operačních systémech rodiny Windows. 3.5 TrueCrypt 4.3a Původně se jednalo pouze o nástroj pro OS rodiny Windows, který vycházel ze zdrojových kódů programu E4M (Encryption For Masses) a první verze byla vydána 2. 2. 2004. S postupem času byly přidávány nové a nové funkce až nakonec 1. 11. 2005 přibyl i linuxový port. Tento linuxový port nástroje TrueCrypt [32] je vyvíjený jako svobodný software společností TrueCrypt Foundation a spadá do kategorie nástrojů šifrujících na úrovni blokového zařízení device- mapperu. Je tedy alternativou k Dm-Cryptu, neboť je na device-mapper napojen stejným mechanismem. Díky této skutečnosti mají TrueCrypt a Dm-Crypt celou řádku podobných vlastností. Není třeba instalovat upravenou sadu utilit pro práci s diskovými svazky jako mount atp. Navíc však lze tyto dva nástroje používat i souběžně. Po instalaci modulu lze TrueCrypt šifrované jednotky ovládat pomocí utility „truecrypt“. Stejně jako Dm-Crypt LUKS i TrueCrypt je kontejnerový formát. Nenabízí sice možnost přístupu pod více hesly, ale informace o použitých šifrách, hašovacích algoritmech a použitých modusech blokové šifry si nese ve své hlavičce, která je čitelná (srozumitelná) pouze po zadání správného hesla. Vše co uživatel musí znát je tedy pouze správné heslo. Podobnost obou modulů není pouze na úrovni vlastností, ale i na úrovni zdrojového kódu. Tato skutečnost je podmíněná napojením obou modulů na stejné API a využívání stejného subsystému kernelu. TrueCrypt však pro šifrování nevyužívá linuxové CryptoAPI, ale obsahuje své vlastní implementace šifrovacích algoritmů. Takto je zajištěna kompatibilita a přenositelnost šifrovaných kontejnerů mezi linuxovou a windowsovou verzí. Další společná vlastnost je, že k jednotkám TrueCryptu lze v OS rodiny Windows přistupovat nejen pomocí windowsové verze TrueCryptu, ale také pomocí nástroje FreeOTFE a ScramDisk4L [33]. Zašifrovaná jednotka TrueCryptu není nijak identifikovatelná. Obsah takového souboru nebo diskové oblasti vypadá jako náhodný binární šum, což může být velice užitečná vlastnost v momentě, kdy potřebujeme utajit i samotnou existenci nějakých dat – tzv. steganografie [34]. Případně lze zajít ještě dál a vytvořit skrytou jednotku v TrueCrypt jednotce. Existence této jednotky je také utajena do momentu, než kdy je zadáno heslo k této skryté jednotce. Nabízí se nám několik scénářů, kdy lze této skryté jednotky s výhodou využít. Například v nedůvěryhodném prostředí si můžeme dovolit zadat heslo k TrueCrypt jednotce a přečíst dokumenty, ale skrytá jednotka obsahující GPG klíče zůstane utajena. Nebo v momentě kdy jsme někým donuceni prozradit heslo a vydat tajné dokumenty. Jsou vydány falešné dokumenty, zatímco originály uložené ve skryté jednotce jsou stále v bezpečí. Zajímavou avšak spornou funkcí je možnost využití tzv. keyfiles – klíčových souborů. Entropie zadaného hesla je ještě zvýšena daty z vybraného souboru/ů, algoritmus je však velmi nenáročný a z kryptografického hlediska téměř zanedbatelný[35]. Funkce těchto souborů tedy spočívá především v obraně proti rozšifrování jednotky pouze pomocí odchycení hesla keyloggerem. Z uživatelského hlediska skýtá TrueCrypt několik vylepšení a celkově je poznat důraz na uživatelskou přívětivost. Uživatel je například zbaven nutnosti připojovat jednotku, toto provádí TrueCrypt automaticky, o možnost manuálního nastavení však připraven není.

3.6 TrueCrypt 5.x Letos na jaře, 5. února 2008, vyšla nová řada tohoto šifrovacího nástroje. Mnoho uživatelů již dlouhou dobu očekávalo, co tato verze přinece. A opravdu nových vylepšení nebylo málo. Přibyla verze TrueCryptu pro operační systém MAC OS X. Konečně se dočkali i linuxoví uživatelé a TrueCrypt jim nábídl grafické rozhraní. Největší radost však měli uživatelé operačního systému rodiny Windows. Pro které přibyla možnost pre-boot autentizace. Důležitou novinkou byl i přechod na modernější modus XTS. Nadšení uživatelů ale netrvalo příliš douho. Windowsová pre-boot autentizace nebyla dostatečně odladěna a na internetových fórech se vyrojilo množství nešťastníků, kteří se nebyli schopni přihlásit do svého systému. V průběhu měsíce byly v krátkém intervalu vydány další čtyři verze a prozatím se zdá, že jsou všechny problémy vyřešeny. Zklamání čekalo i uživatele Linuxu. Vývojářům se nelíbilo, že v průběhu vývoje nových verzí jádra, se stává jejich produkt nefunkčním a upustili od vývoje svého modulu na bázi device-mapperu a přešli pod křídla souborových systému na bázi FUSE. Obslužná utilita byla přepsána do jazyka C++ a změnili se i možné volby pro práci z textového režimu, což je velmi nepříjemné. I když se nová verze potýkala s velkými porodními bolestmi, jedná se opět o krok kupředu. Uživatelé nejsou odkázáni na textové rozhraní a mohou si se svými šifrovanými disky pohodlně pracovat z grafického prostředí. Navíc již nepotřebují ani práva superuživatele, aby si mohli jednotku připojit.

3.7 ScramDisk for Linux Má podobnou historii jako TrueCrypt. Nejprve existovala windowsová verze tohoto nástroje, která byla následně zkomercializovaná jako DriveCrypt [36]. Na původní, volně šiřitelný produkt navázal právě ScramDisk for Linux [37]. První kompletní a funkční verze byla zveřejněna 6.8. 2005 na stránkách http://sourceforge.net/projects/sd4l/ V našem přehledu se jedná o posledního zástupce skupiny nástrojů šifrujících na úrovni blokového zařízení. ScramDisk se však vydal svou vlastní cestou, rozdílnou od všech předchozích nástrojů. Nešifruje ani s využitím loop device, ani device-mapperu. Ke své činnosti vytváří bloková zařízení /dev/scramdisk/vol01-15 a práce s šifrovanými disky a soubory probíhá pomocí těchto speciálních souborů. SD4L(ScramDisk For Linux) je stejně jako TrueCrypt a Dm-Crypt nástroj také tvořící kontejnerový formát šifrovaných jednotek. Stačí nám tedy znát heslo pro přístup a veškeré kryptografické nastavení si nastaví ScramDisk sám. S jednotkami můžeme pracovat buď pomocí textových utilit sdmount, sdumount, sdcreate, sdchange, sdreformat, nebo pomocí grafické utility scramdisk. Od verze 1.0 umožňuje SD4L pracovat i s jednotkami TrueCryptu kompatibilními s kontejnery TrueCryptu verzí 4.1-4.3a. Podpora verzí 5.x zatím neexistuje, ale je v plánu. I když SD4L nabízí velmi obdobnou funkcionalitu jako TrueCrypt, není tak rozšířen. Pravděpodobně je to způsobeno masovější propagací TrueCryptu na úkor ostatních šifrovacích nástrojů.

3.8 EncFS EncFS [38] je první představovaný a zároveň asi nejznámější zástupce ze skupiny kryptografických souborových systémů. Při své činnosti využívá funkce komponenty FUSE (Filesystem in USErspace) [39], která je přítomna v jádře od verze 2.6.14 a exportuje funkcionalitu souborového systému do uživatelského prostoru. Princip činnosti je znázorněn na obrázku č. 5. Volání služeb VFS jsou předána modulu FUSE. FUSE tato volání předává aplikaci v uživatelském prostoru, aplikace zpracuje požadavek a výsledek je předán zpět. EncFS je právě ona aplikace běžící v uživatelském prostoru, která provádí zpracování volání souborového systému. Při tomto zpracování dochází v aplikaci k šifrování/dešifrování dat a je k tomu použito externí knihovny OpenSSL [40]. První verze tohoto souborového systému byla vydána 9. 7. 2003. Na rozdíl od předcházejících nástrojů, u kterých jsme bez znalosti hesla měli pouze binární šum. EncFS chrání v šifrovaném adresáři pouze obsah souborů, jejich názvy a názvy podadresářů. I bez znalosti hesla jsou souborům a složkám dále čitelná oprávnění, velikosti a časové otisky. Na druhou stranu je možné provádět zálohu jednotlivých modifikovaných souborů. Velká výhoda tohoto řešení spočívá v tom, že pro připojení šifrovaného adresáře nejsou potřeba práva superuživatele. Připojení, vytvoření a obsluha probíhá pomocí utility „encfs“. Při vytváření šifrovaného adresáře je uživatel vyzván k zodpovězení několika otázek ovlivňujících následně použité kryptografické mechanismy. Zároveň je však nutno dbát zvýšené opatrnosti na odkládací soubory, které mohou být uloženy v nešifrovaném adresáři a může tak dojít k nechtěnému úniku informací.

Obrázek č. 5 [62] 3.9 CryptoFS Je další zástupce kryptografického souborového systému [41]. Stejně jako v předchozím případě se jedná o souborový systém v uživatelském prostoru, fungující buď pomocí modulu FUSE, nebo LUFS [42]. První verze vyšla 3. 11. 2003. Výhodou u kryptografických souborových systémů je flexibilní velikost šifrovaného adresáře. Zatímco u nástrojů šifrujících na úrovni blokového zařízení je potřeba již při vytvoření jednotky stanovit její velikost, zde tomu tak není. Šifrovaný adresář je omezen pouze velikostí hostujícího diskového oddílu a případných omezení souborového systému. Je-li použito modulu FUSE probíhá přimountování zdrojového adresáře s šifrovaným obsahem pomocí utility „cryptofs“. V případě, že je použito modulu LUFS probíhá pomocí utility „lufsmount“. Konfigurace se načítá z textového souboru „.cryptofs“ ve zdrojovém adresáři. Šifrování probíhá pomocí kryptografické knihovny libgcrypt [43]. Díky portování modulu FUSE pod Mac OS X, známe jako MacFUSE [44] se tento modul dočkal portace pod Mac OS X jako cryptomfs [45].

3.10 CryptFS a NCryptFS CryptFS [46] je podle jeho autora pouze proof of concept, tedy něco jako testovací prototyp. Skutečně použitelný stohovatelný šifrovací souborový systém byl až NcryptFS [47]. Nezdá se však, že by byl v současné době aktivně vyvíjen. Zatímco CryptFS umožňoval použít pouze šifru Blowfish, Ncryptfs umožňuje použití více šifer, více klíčů a omezení časové platnosti těchto klíčů. Také nabízí možnost vytvářet své vlastní uživatelské skupiny a delegovat jim oprávnění. Na obrázku č. 6 je znázorněno propojení CryptoFS vrstvy nad regulérní souborový systém. Obrázek č. 6 [63]

3.11 eCryptFS Jedná se o stohovatelný šifrovací souborový systém [48], který je odvozen z CryptFS. První verze byla vydána 4. 10. 2006 a jako součást jádra byl začleněn od verze 2.6.19. Je generovaný pomocí FiST frameworku [49], který usnadňuje tvorbu a portování souborových systémů. K šifrování eCryptFSužívá služeb subsystému CryptoAPI, umí pracovat s veřejnými klíči a spolupracovat s jadernou klíčenkou či TPM [50]. Šifrovací klíč si nese každý soubor ve své hlavičce, což umožňuje zálohování na úrovni šifrovaných souborů, či případnou inkrementální zálohu. K dešifrování poté stačí vlastnit potřebný klíč, nebo znát potřebné heslo. Na obrázku č. 7 je znázorněno schéma zapojení eCryptFS při činnosti. Tento souborový systém se nachází nad regulérními souborovými systémy a požadavky jsou při činnosti šifrovány/dešifrovány v této vrstvě a následně předány další vrstvě. Dle autorů modulu je možno eCryptFS používat nad jakýmkoliv souborovým systémem. Jedině u souborového systému XFS [51] je potřeba ověřit, zda nedochází k přetečení zásobníku. Obrázek č. 7 [64]

3.12 CFS Cryptographic File System [52] je již dost starý šifrovací souborový systém vytvořený Mattem Blazem. Jeho vznik se datuje do roku 1989 a poslední verze vyšla v roce 1997. CFS běží v user-space jako démon a není tedy potřeba kompilovat jádro. Ke své činnosti používá lokální NFS export a jeho lokální přimountování. Při instalaci je potřeba nainstalovat obslužné nástroje cfsd, cdetach, ccat, cmkdir, cname a cattach. Šifrovanou složku vytvoříme příkazem cmkdir, který si vyžádá heslo. Takto vytvořený adresář je však jenom úložiště pro šifrovaný obsah. Chceme-li tento obsah dešifrovat a začít s ním pracovat, musíme příkazem cattach CFS oznámit, že s ním má pracovat. Je vyžádáno opět heslo a dešifrovaný adresář je dostupný v přimountovaném adresáři NFS exportu. Po skončení práce je opět potřeba odpojit obsah pomocí příkazu cdetach.

3.13 TCFS Transparent Cryptographic File System [53] je souborový systém pro šifrovaný přenos souborů přes NFS (Network File System) [54]. Navazuje na projekt CFS. Po přimountování exportovaného NFS adresáře a nastavení šifrovacího klíče pomocí utility „tcfs_setkey“ jsou veškeré soubory s rozšířeným příznakem X šifrovány. Šifrování probíhá pomocí volání služeb linuxového subsystému CryptoAPI přímo na straně klienta. Požadavky aplikací na čtení/zápis jsou zpracovány v dešifrované formě a poté jsou předány jako normální požadavky mechanismu NFS, jejich obsah je však již šifrovaný. Není potřeba provádět žádné úpravy na straně NFS serveru, neboť tento modul je plně kompatibilní s NFS v3. Oproti CFS je více transparentní pro uživatele a rychlejší, protože běží v kernel-space. Nedochází tedy ke kopírování dat do user-space a zase zpět do kernel-space. 4 Bezpečnostní analýza TrueCryptu

4.1 Analýza Vlastimila Klímy V červenci roku 2007 byly zveřejněny výsledky analýzy [35] provedené předním českým kryptologem Vlastimilem Klímou [55]. Jeho analýza byla zaměřena zejména na použité kryptografické algoritmy. Uveďme alespoň několik podstatných informací. Každá jednotka TrueCryptu si nese v prvním sektoru 512 bytů dlouhou hlavičku, která obsahuje veškeré údaje potřebné pro práci s jednotkou. Struktura je popsána v tabulce č. 1. Hlavička je zašifrována pomocí klíčů odvozených od uživatelem zadaného hesla.

Tabulka č. 1 - struktura hlavičky TrueCryptu [35]

Odvození klíčů probíhá pomocí složité funkce PBKDF2, která zadané heslo a sůl 1000x nebo 2000x iteruje v závislosti na vybrané hašovací funkci. Je to způsob ochrany proti útoku hrubou silou. Při běžné práci nám toto zdržení nepůsobí žádné problémy, ale útočník nedisponuje dostatečným vý- početním výkonem, aby mohl vyzkoušet v reálném čase všechny možnosti a rozluštit tak obsah jednotky. Z nabízených hašovacích algoritmů pak Klíma doporučuje používat algoritmus s názvem Whirpool. Ověřil, že použité klíče jsou generovány náhodným generátorem a je proveden test, zda nejsou slabé. Při změně hesla, dochází k přegenerování hlavičky a jejím 23 přepisům pokaždé s jinou solí, aby se zabránilo možnosti obnovy původních dat. Kryptolog Klíma neobjevil v TrueCryptu žádná zadní vrátka, která některé společnosti implementují do svých produktů. A ověřil, že se TrueCrypt chová v souladu s jeho dokumentací. Z analýzy vyplynulo, že se tedy jedná o důvěryhodný produkt a můžeme mu svěřit svá data.

4.2 Naše analýza Provedená bezpečnostní analýza se zabývala implementací TrueCryptu verze 4.3a, která se skládá z jaderného modulu a obslužné utility. Analýza probíhala na základě ověřených zdrojových kódů stažených ze stránek http://www.truecrypt.org/ dne 4. 10. 2007. U získání zdrojových kódů můžeme upozornit na malý nedostatek, neboť zdrojové kódy lze stáhnout pouze pomocí nešifrovaného protokolu http. Útočník by tak při stahování mohl podstrčit upravené zdrojové kódy. Lze též stáhnout PGP podpis zdrojových kódů, ale většina uživatelů ověřování neprovádí, neboť jsou to úkony navíc. Přitom protokol https lze použít, ale pouze při nahlašování chyb TrueCryptu. Po stažení, ověření a rozbalení zdrojových kódů je nutno nejprve zkompilovat zdrojové kódy a poté je nainstalovat. Tato činnost probíhá pomocí skriptů v adresáři Linux s názvy build.sh a install.sh. Oba dva skripty vyžadují spuštění s právy superuživatele. Pro kompilaci potřebujeme také zdrojové kódy jádra, na kterém bude TrueCrypt provozován. Minimální verze jádra musí být 2.6.5. V případě prvního skriptu build.sh probíhá pouze kompilace a práva superuživatele jsou zde z bezpečnostního hlediska nadbytečná. Autoři se tak pravděpodobně rozhodli předejít problémům s oprávněními k zápisu při rekompilaci jaderných modulů. Neboť do adresáře /usr/src/, kde se většinou nachází zdrojové kódy jádra, nemá ve většině distribucí běžný uživatel právo zápisu. Skript install.sh již práva superuživatele opravdu potřebuje, neboť instaluje zkompilovaný modul, obslužnou utilitu a dokumentaci do systémových adresářů. Zkontroluje také přítomnost potřebných speciálních souborů, utitlit a modulů. Ve skriptech nebyla nalezena žádná jiná problémová partie. Analýza je dále rozdělená zvlášť na analýzu obslužné utility a na analýzu jaderného modulu.

4.2.1 Obslužná utilita

Jako výsledek kompilace souboru Linux/Cli.c vznikne binární spustitelný soubor se jménem truecrypt. Tato aplikace je z uživatelského hlediska nejdůležitější, neboť právě pomocí ní uživatelé vytvářejí a pracují s TrueCrypt jednotkami. Ve zdrojových kódech jsme ověřili, že utilita pracuje s hesly bezpečně. Celý proces běží v neodswapovatelné paměti, tedy hesla zůstávají v RAM počítače a nejsou zapisována na disk. Při rozdvojení procesu voláním služby fork(), jsou synovskému procesu hesla okamžitě přepsána nulovými hodnotami. Utilita také hlídá signály přerušení a v případě nečekaného ukončení hesla také nuluje. Při ukončení práce jsou hesla opět bezpečně přemazána. Tato utilita ke svému běhu vyžaduje práva superuživatele. Požadavek je to oprávněný, neboť při své činnosti volá systémové utility jako mount, losetup či dmsetup. Autoři se preventivně rozhodli nepovolit pracovat s touto utilitou, pokud je spuštěna jako setuid a brání se tak případné nechtěné eskalaci práv. Pokud program detekuje, že je spuštěn a má nastavený suid bit, okamžitě se ukončí, aniž by provedl jakoukoliv akci. Buď tedy budeme s TrueCryptem pracovat pod účtem superuživatele, nebo budeme používat příkaz sudo. Autoři přímo do programu zahrnuli využití příkazu sudo a potřebné akce, vyžadující práva superuživatele spouští přes něj. V implementaci tohoto volání byla odhalena chyba, která by mohla být za určitých okolností zneužita. Funkce, která zajišťuje použití suda má nešťastně zvolené pořadí operací, nejdříve ověří má-li uživatel superuživatelská práva. Pokud ano, nastaví bezpečně systémovou proměnnou PATH a skončí. Pokud ne, spustí celý příkaz přes sudo, které se zeptá na heslo a spustí ho již s právy superuživatele. Systémová proměnná PATH obsahuje cesty do systémových složek, v kterých se nachází příkazy. Uživatel tak nemusí pokaždé zadávat absolutní cestu k příkazům, ale pouze jejich jednoslovné názvy. Příkaz sudo je však v rutině spuštěný pomocí volání execvp(), které při svém spuštění prohledává systémovou proměnnou PATH a hledá v ní program, který má spustit. Když se útočníkovi podaří upravit PATH proměnnou uživatele, nebo pokud má uživatel v této proměnné nastavený pracovní adresář, je příkaz sudo nejdříve hledán v těchto adresářích. Útočník do těchto prohledávaných adresářů může podstrčit binární soubor s názvem sudo a tento může být spuštěn místo systémového příkazu sudo. Dojde-li až k tomuto spuštění, má útočník v podstatě volné pole působnosti. V příloze je obsažen velmi jednoduchý příklad takto upravené implementace suda. V momentě, kdy se ptá poprvé na heslo, zaloguje si tyto informace a spustí již opravdu požadovaný příkaz. Čili se snaží chovat nenápadně. Toto chování by však mohlo být i daleko více nebezpečné. V současné době má většina běžných uživatelů povoleno spouštění jakéhokoliv příkazu přes sudo. Po takto úspěšně provedeném útoku má útočník plnou kontrolu nad systémem. Obrana proti takovému útoku je velmi jednoduchá. Stačí již při spuštění nastavit bezpečný obsah proměnné PATH. Opravená verze je v příloze.

4.2.2 Modul Linuxového jádra

Tou před uživateli skrytou, ale nejdpodstatnější částí TrueCryptu je jeho jaderný modul. Modul v podstatě vykonává veškerou těžkou práci TrueCryptu při jeho šifrování/dešifrování. Modul vznikne po kompilaci zdrojového kódu Linux/Kernel/Dm-target.c a jmenuje se truecrypt.ko. Instalačním skriptem je nainstalován do patřičného adresáře linuxových modulů, aby mohl být v případě potřeby zaveden. TrueCrypt je při své činnosti závislý na device-mapperu. Což je jaderný mechanismus pro mapování blokových zařízení. Při tomto mapování může a dochází k různým transformacím. Této skutečnosti nejdříve využil pro šifrování Dm-Crypt. Později ho následoval i TrueCrypt a implementoval svůj modul podobným způsobem. Device-mapper nabízí rozhraní a jednotlivé moduly pak pouze implementují základní funkce, podobně jako tomu bylo v případě souborových systémů. Vývojářům je takto nabídnuta možnost poměrně efektivně, bez větších problémů a především velmi čistě psát moduly pro rozšíření funkčnosti device-mapperu. Je tomu tak i v případě TrueCryptu. Rozšiřující moduly se v terminologii device-mapperu nazývají targets, česky cíle. Moduly se při zavedení do paměti zaregistrují voláním funkce „dm_register_target()“ a jako parametr předají strukturu obsahující jméno cíle, verzi a odkazy na obslužné rutiny. TrueCrypt ve svém modulu implementuje základní rutiny truecrypt_ctr, truecrypt_dtr, truecrypt_map, truecrypt_status a dvě pomocné truecrypt_endio a work_process. Nemusí tedy řešit žádné z hlediska bezpečnosti kritické sekce. Veškerá bezpečnostní rozhodnutí zůstávají v režii ochranných mechanismů jádra. Ve své režii si spravuje pouze šifrovací klíče. Protože je device-mapper součástí oficiálního jádra, je pod bedlivým dozorem vývojářů a mnoha testerů v různých prostředích. Zvyšuje se tak šance, že případná bezpečnostní nebo jakákoliv jiná chyba bude brzy nalezena a opravena. Naše analýza se tedy zaměří přímo na implementaci funkcí TrueCryptu. Na obrázku č. 8 je znázorněno postavení TrueCryptu k device-mapperu jiným subsystémům jádra jako např. VFS. Šipky znázorňují požadavky na čtení a zápis. Obrázek č. 8 - Napojení TrueCryptu na vrstvy jádra

4.2.3 Popis funkcí jednotlivých částí modulu

Zdrojový kód TrueCryptového modulu je poměrně dobře čitelný, některé části by však mohly být lépe okomentovány. Problém se snaží řešit přímočaře a také se mu to daří, velikost zdrojového kódu je o 7kB menší než zdrojový kód Dm-Cryptu. Tento rozdíl je především cena za vývoj modulu v hlavní vývojové větvi Linuxového jádra a za zpětnou podporu zastaralých algoritmů. Aby se nový kód dostal do oficiálního jádra, musí být patrné, co která část kódu dělá. Toho je docíleno pomocí kvalitních komentářů a transparentní implementací bez krkolomných triků. Pokud na nějakém triku přece jen trváme, musí být pak dobře okomentovaný. Správci jádra jsou poměrně nároční a pokud se jim kód nezdá, odmítnou ho začlenit. Linuxový mailing list[60] je plný důkazů o takových odmítnutích. Následující přehled zevrubně popisuje vnitřní činnost modulu.

Načtení modulu V případě, že selže jeden z následujících kroků, je uvolněna použitá paměť a je vrácena chyba -ENOMEM ● je vytvořena pracovní fronta s názvem „truecryptq“, která slouží pro opožděné spuštění naplánovaných úloh ● v paměti je alokována cache s názvem „truecrypt-bioctx“ kvůli rychlejší alokaci objektů a efektivnímu využití paměti ● voláním funkce dm_register_target() je do interních struktur device-mapperu zaregistrován cíl truecrypt a jsou mu předány potřebné parametry

Vymazání modulu ● voláním funkce dm_unregister_target() je odregistrován cíl truecrypt ● pracovní fronta „truecryptq“ je vyprázdněna a zrušena z paměti ● uvolní se paměť alokovaná cachi „truecrypt-bioctx“

Funkce truecrypt_ctr Funkce je volána po získání potřebných informací z hlavičky TrueCrypt jednotky. Obslužná utilita spustí příkaz „dmsetup create truecrypt“ a na jeho vstup vypíše řetězec obsahující potřebné údaje pro vytvoření blokového zařízení TrueCryptu. Blokové zařízení je vytvořeno v adresáři /dev/mapper/, je přimountováno do požadované složky a takto je umožněna práce s dešifrovaným obsahem jednotky. Utilita dmsetup komunikuje s device- mapperem pomocí systémových volání ioctl (input output control) zaslaných zařízení /dev/mapper/control Pokud dojde k selhání v některém z následujících kroků, citlivé údaje jsou přepsány nulami a je uvolněna případná alokovaná paměť. ● Proběhne kontrola na počet parametrů a jejich typ. ● Alokuje se neodswapovatelná paměť pro strukturu obsahující kryptografické informace. ● Je vytvořen mempool stránek a slabů pro zpracování požadavků. Mempooly zajišťují úspěšnou alokaci paměti i při jejím značném zaplnění. ● Datové struktury jsou inicializovány předanými parametry. Proběhne inicializace šifrovacích algoritmů a blokové zařízení, které bylo vytvořeno voláním dmsetupu je schopno provádět šifrování.

Funkce truecrypt_dtr je spuštěna při rušením blokového zařízení TrueCrypt jednotky. Jsou přepsány citlivé údaje nulami, uvolní alokovanou paměť.

Funkce truecrypt_status vypisuje textové informace o TrueCrypt jednotce. Například použitý algoritmus, modus blokové šifry, id uživatele atp.

Funkce truecrypt_map Je spouštěna device-mapperem a náplň její činnosti je převod mezi šifrovanou a dešifrovanou podobou dat. Jako parametr je jí předána BIO (Block I/O) struktura, což je interní struktura Linuxového jádra, určená pro provádění blokových vstupně/výstupních operací. Každá BIO struktura je samostatná a představuje jeden požadavek na čtení/zápis blokového zařízení. Moderní hardware je schopen zpracovat i více požadavků najednou. Kvůli zvýšení výkonu jsou tedy BIO struktury organizovány do seznamů a zpracovávány zaráz. V BIO struktuře jsou obsaženy důležité informace, potřebné k úspěšnému vykonání požadavku. Údaje o blokovém zařízení, různé příznaky a odkazy na další struktury. Pro nás je podstatnou částí BIO struktury její obsah. Ten je adresován pomocí pole struktur, odkazujících již na jednotlivé stránky v paměti, nesoucí obsah. Důležitý je pro nás také příznak čtení/zápis, který určuje zda se bude šifrovat/dešifrovat. ● Při požadavku o zápis je ověřena ochrana proti zápisu a případně je vrácena chyba -EPERM. ● Ověří se správná velikost sektorů, při špatně velikosti je vrácena chyba -EINVAL. ● Je alokována nová struktura BIO, do které jsou nakopírovány technické informace o blokovém zařízení, počátečním sektoru atp. ● V případě že jde o požadavek čtení je zkopírováno i pole struktur odkazujících na stránky s obsahem ● Při požadavku na zápis ○ Je ověřena ochrana proti zápisu a ocharna skryté jednotky proti přepisu, v případě porušení je uvolněna vrácena chyba -EPERM nebo -ENOMEM. ○ Jsou alokovány stránky pro šifrovaný obsah a je do nich překopírovaný obsah nešifrovaný. ○ Přímo v takto nově alokovaných stránkách proběhne zašifrování jejich obsahu. ● Je volána funkce blokové vrstvy jádra pro uskutečnění požadavku generic_make_request(), jako parametr jí je předaná nově alokovaná BIO struktura s potřebným obsahem.

Součástí nově vytvořené BIO struktury je i odkaz bi_end_io na funkci, která je volaná při dokončení požadavku. Odkaz ukazuje na funkci truecrypt_endio.

Funkce truecrypt_endio Je vykonána v kontextu přerušení, při ukončení blokového požadavku. Aby neblokovala přerušení, musí být co nejrychleji provedena. K takovým účelům se v jádře 2.6 využívá pracovních front – tzv. workqueue. V kontextu přerušení jsou provedeny nejnutnější operace a zbytek je přidán do této fronty, kterou zpracovává samostatné vlákno jádra později. ● při požadavku na čtení je inicializována pracovní fronta „truecryptq“ a je do ní přidáno spuštění funkce work_process ● při požadavku o zápis jsou již zašifrovaná data zapsána na disk a proběhne uvolnění alokovaných stránek a je sníženo číslo referencí na BIO strukturu.

Funkce work_process Dokončuje práci modulu při dešifrování. Prochází jednotlivýmí stránkami šifrovaných dat, dešifruje je a přímo je do nich zpět zapisuje.

4.3 Zjištěné problémy Během naší analýzy nebyly zjištěny chyby závažného charakteru, které by nějak přímo souvisely se špatnou implementací, nebo přímým ohrožením dat uložených v TrueCrypt jednotkách. Dva drobné nesoulady byly objeveny ve funkci truecrypt_ctr(). První nesoulad je spíše kosmetického rázu a běžný uživatel na něj nenarazí. V případě, že není funkci předán potřebný počet argumentů, vypisuje textovou informaci o správném použití. Tato textová informace je však nepravdivá, neboť ze seznamu povinných parametrů je vynechán parametr obsahující id uživatele. Dokud se tedy uživatel bude řídit vypisovanou informací, bude jeho počínání neúspěšné. Záludnost této chyby spočívá v rozporu mezi poskytovanou dokumentací a skutečností. Správný formát není ani nikde zmíněný, lze ho vyčíst pouze ze zdrojových kódů TrueCrypt modulu. Druhým nalezeným problémem ve funkci truecrypt_ctr() je provedení špatné kontroly po alokaci paměti. Po alokaci je sice provedena kontrola na nenulovost ukazatele, ale špatného. Pokud je alokace neúspěšná a hodnota ukazatele je NULL, při jeho dalším použití v kódu je vyvolána chyba jádra – kernel oops[56]. Linuxové jádro se s takovou chybou vypořádá tím, že zabije proces, který tuto chybu vyvolal a blokové zařízení TrueCryptu tím pádem není vytvořeno. V průběhu analýzy jsme také zjistili další velice zajímavou skutečnost, která by mohla vést až k odhalení alespoň malých částí nešifrovaného obsahu TrueCrypt jednotky. Toto zjištění nesouvisí s žádnou skutečností, kterou by mohl ovlivnit TrueCrypt modul, ale s vnitřním návrhem a mechanismy Linuxového jádra. Linuxové jádro se snaží chovat co nejefektivněji. Protože přístup na disk je ve srovnání přístupu k operační paměti mnohem pomalejší, byl do jádra implementován mechanismus buffer cache. Tento mechanismus zajišťuje, že jakmile je požadován obsah nějakého souboru, je nahrán do cache paměti, která se nachází v operační paměti a zůstává v ní uložen. Přijde-li další požadavek na tento soubor, není již nutno znovu pracovat s pomalým diskem, ale obsah souboru je namapován z této cache paměti. Tohoto mechanismu je použito i v našem případě, při přístupu k nešifrovanému obsahu blokového zařízení TrueCrypt jednotky. Modul po provedeném dešifrování, vrací device mapperu BIO strukturu, odkazující na stránky v paměti nesoucí dešifrovaný obsah. A tento nešifrovaný obsah je udržován v buffer cache paměti. Dokud jsou stránky takto alokovány, je jejich obsah chráněn proti neoprávněnému čtení ochrannými mechanismy jádra. Dříve nebo později však dojde k jejich uvolnění a označení jako volné stránky, nedochází ale k přemazání jejich obsahu. Toto přemazání se provádí pouze v momentě, kdy je stránka mapována do uživatelského prostoru. Teoreticky by se tedy útočník mohl dostat k nešifrovanému obsahu. Musel by však mít možnost alokovat v jaderném prostoru velké množství stránek, aby vyvolal výpadek stránky a donutil tak jádro vyprázdnit buffer cache, čili označit stránky za volné. Úspěch tohoto útoku však není ani takto zaručen. Protože dochází ke značné fragmentaci paměti, stránky nejsou přidělovány v souvislých blocích, ale různě rozmístěné po paměti. To značně ztěžuje roli útočníkovi. Musí mít štěstí a dostat od jádra přidělenou stránku původně obsaženou v buffer cache, přičemž se tato stránka nijak neliší od stránek ostatních. Poté musí být schopen právě tyto stránky identifikovat. Dá se však předpokládat, že pokud je již útočník schopen takto alokovat velké množství stránek v kontextu jádra, došlo k selhání některých bezpečnostních ochran jádra a útočník se k obsahu může dostat i mnohem snazšími cestami, než je analýza obsahu bloků paměti.

4.4 Nová hrozba V únoru letošního roku, zveřejnil tým vědců z Princentonské univerzity velmi závažné výsledky výzkumu. Téměř všichni jsme se domnívali, že obsah paměti RAM, založený na technologii DRAM, je po odpojení napájecího napětí téměř okamžitě vymazán. Výzkum tento všeobecně rozšířený názor značně narušil. Útok na veškeré On-the-fly šifrovací systémy, který vědci provedli, nazvali coldbooot. V průběhu výzkumu bylo totiž zjištěno, že obsah pamětí RAM je stále čitelný i několik sekund po odpojení napájecího napětí. A pokud jsou moduly paměti ještě více zchlazeny, zmenší se odpor vodičů, takže se kondenzátory tak rychle nevybíjí a dokáží v sobě uchovat hodnoty po dobu až v řádu hodin. Této skutečnosti využili a předvedli několik variací coldboot ůtoku. Název odpovídá skutečnosti, je proveden opravdu studený start. Start systému s chlazenými pamětovými moduly. K ochlazení byl použit tekutý dusík. K uskutečnění tohoto útoku je potřeba mít fyzický přístup k napadanému počítači, který musí být spuštěný a musí být připojen šifrovaný disk. Nejdříve je počítač vypnut. Pamětové moduly jsou zchlazeny a k počítači je připojena bootovací USB klíčenka. Klíčenka obsahuje speciální instrukce a při bootování začne kopírovat stávající obsah paměti na sebe. Aby mohly šifrovací programy fungovat transparetně, musí mít šifrovací klíče uložené v paměti připravené kdykoliv k použití. Veškeré nástroje si dávají pozor, aby tyto klíče byly uloženy v neodswapovatelné paměti a neobjevily se tak zapsané na disku, v domnění že jsou tam bezpečně skryty před zraky útočníka. V případě coldbootu je však obsah celé paměti přehrán na USB disk i s těmito klíči. A pozdější analýzou jsme schopni tyto klíče nalézt a za jejich pomoci rozšifrovat obsah celého disku. Druhá varianta útoku je, že máme připravený druhý počítač a po vypnutí a zchlazení pamětí je přeneseme do našeho připraveného počítače ke zkopírování jejich obsahu. Tento způsob útoku je velmi nečekaný, ale za to velmi efektivní. Jediná stroprocentní ochrana je zabránit útočníkovi v fyzickému přistupu k počítači. V diskusních fórech se objevovaly různé návrhy, zda klíče nedržet v paměti nějakého zařízení, cachi procesoru atp. Toto však není ani efektivní ani systémové řešení. Útočníka to může pouze zpomalit, než objeví, kde se klíč nachází a pak jej bez problémů přečte.

4.5 TrueCrypt a CryptoAPI Součástí zadání bakalářské práce byla i analýza napojení TrueCryptu na šifrovací vrstvu linuxového jádra CryptoAPI. Dokumentaci k použítí tohoto CryptoAPI se však nepodařilo nikde nalézt, nebo byla neúplná a spíše matoucí. Jako vzorovou implementaci byla brána implementace v modulu tcrypt. Což je testovací modul, který ověřuje zda moduly implementují šifry dávají korektní výsledky. Správné použití je následující: ● Nejdříve je nutno vytvořit instanci struktury crypto_blkcipher voláním funkce crypto_alloc_blkcipher(const char *alg_name, u32 type, u32 mask) ● Odkaz na tuto strukturu vložit do struktury blkcipher_desc. ● Nastavit klíč šifry voláním funkce crypto_blkcipher_setkey(struct crypto_blkcipher *tfm, const u8 *key, unsigned int keylen) ● Nastavit inicializační vektor šifry, v případě modusu LRW je to pak druhý klíč, voláním funkce crypto_blkcipher_set_iv(struct crypto_blkcipher *tfm, const u8 *src, unsigned int len)

Po těchto inicializačních úkonech můžeme provést šifrování/dešifrování voláním funkcí. ● crypto_blkcipher_encrypt(struct blkcipher_desc *desc, struct scatterlist *dst, struct scatterlist *src, unsigned int nbytes) ● crypto_blkcipher_decrypt(struct blkcipher_desc *desc, struct scatterlist *dst, struct scatterlist *src, unsigned int nbytes)

Bohužel se však nepodařilo vytvořit funkční prototyp, který by nepůsobil kernel panic. Po hlubším zkoumání problému se ukázalo, že by bylo potřeba přesunout celý kód šifrovacího modusu do userspace utility, která používá šifrování při vytváření jednotky. Tím by jsme však přišli o výhodu, kvůli které nás tato možnost zájímala. 5 Závěr

V práci se ukázalo, že existuje poměrně velké množství nástrojů na OTFE šifrování a některé z nich jsou konkurenceschopné i v komerčním prostředí. Nic to však nemění na skutečnosti, že jsou to pouze nástroje a neměly by v nás vyvolávat falešný pocit bezpečí. Při práci s citlivými údaji je potřeba, aby si každý uchoval zdravou míru paranoie a zůstal ostražitý. Jak se říká: „Důvěřuj, ale prověřuj.“ Bakalářská práce mi otevřela nové obzory, zejména co se týká vývoje linuxového jádra a programování modulů. Počítačová bezpečnost mě odjakživa zajímala a tato práce byla příjemný způsob, jak se o této oblasti dozvědět další nové a zajímavé informace. Zejména vyvolá člověku úsměv na tváři až překvapivá jednoduchost některých závažných útoků na bezpečnostní mechanismy. Doufám že dosažených znalostí dále využiji k zajištění bezpečnosti osobních dat a rozšiřování povědomí o těchto mechanismech. Rád bych se také dál věnoval problematice CryptoAPI a pokusil se dokončit úpravu TrueCrypt modulu, či ho alespoň udržoval v chodu s měnícím se API linuxového jádra. 6 Literatura

[1] http://www.psp.cz/docs/laws/listina.html [2] http://cs.wikipedia.org/wiki/Listina_z%C3%A1kladn%C3%ADch_pr%C3%A1v_a_svobod [3] http://cs.wikipedia.org/wiki/Soukrom%C3%AD [4] http://cs.wikipedia.org/wiki/Kryptografie [5] http://mathworld.wolfram.com/XOR.html [6] http://en.wikipedia.org/wiki/Cryptographic_haš_function [7] http://cs.wikipedia.org/wiki/API [8] http://cs.wikipedia.org/wiki/Monolitick%C3%A9_j%C3%A1dro [9] http://en.wikipedia.org/wiki/Initrd [10] http://en.wikipedia.org/wiki/Loop_device [11] http://sourceware.org/lvm2/ [12] http://artax.karlin.mff.cuni.cz/~mikulas/doc/vfs.html [13] http://cs.wikipedia.org/wiki/Souborov%C3%BD_syst%C3%A9m [14] http://en.wikipedia.org/wiki/OTFE [15] http://loop-aes.sourceforge.net/ [16] http://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software [17] http://mail.nl.linux.org/linux-crypto/200705/msg00066.html [18] http://tldp.org/HOWTO/Cryptoloop-HOWTO/ [19] http://www.uwsg.indiana.edu/hypermail/linux/kernel/0307.0/0348.html [20] http://mareichelt.de/pub/notmine/diskenc.pdf http://mareichelt.de/pub/texts.cryptoloop.php?alt_styles=2 http://www.governmentsecurity.org/archive/t14922.html [21] http://lwn.net/Articles/67223/ [22] http://mail.nl.linux.org/linux-crypto/ [23] http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.2/1137.html [24] http://kerneltrap.org/node/3521, http://kerneltrap.org/node/2433 [25] http://www.saout.de/misc/dm-crypt/ [26] http://en.wikipedia.org/wiki/Dm-crypt [27] http://lwn.net/Articles/22909/ [28] http://mirell.org/kernel-traffic/kernel-traffic/trans/czech/kt20031231_247.xml [29] http://lkml.org/lkml/2004/1/16/222 [30] http://luks.endorphin.org/ [31] http://www.freeotfe.org/ [32] http://www.truecrypt.org [33] http://www.scramdisk.clara.net/ [34] http://cs.wikipedia.org/wiki/Steganografie [35] http://www.root.cz/clanky/truecrypt-profesionalni-ochrana-dat-zdarma/ [36] http://www.securstar.com/disk_encryption.php [37] http://www.scramdisklinux.org/ [38] http://www.arg0.net/encfs [39] http://fuse.sourceforge.net/ [40] http://www.openssl.org/ [41] http://reboot.animeirc.de/cryptofs/ [42] http://sourceforge.net/projects/lufs/ [43] http://directory.fsf.org/project/libgcrypt/ [44] http://code.google.com/p/macfuse/ [45] http://phon.ling.mun.ca/~ghedlund/cryptomfs.html [46] http://www.am-utils.org/docs/cryptfs/cryptfs.html [47] http://www.filesystems.org/docs/ncryptfs/ [48] http://ecryptfs.sourceforge.net/ [49] http://www.filesystems.org/ [50] http://en.wikipedia.org/wiki/Trusted_Platform_Module [51] http://cs.wikipedia.org/wiki/XFS [52] http://www.crypto.com/software/ [53] http://www.tcfs.unisa.it/ [54] http://cs.wikipedia.org/wiki/Network_File_System [55] http://cryptography.hyperlink.cz/ [56] http://en.wikipedia.org/wiki/Linux_kernel_oops [57] http://krypto.krokonet.com/ [58] http://mbroz.fedorapeople.org/talks/DeviceMapperBasics/dm.pdf [59] http://www.google.com/calendar [60] http://lkml.org/ [61] http://citp.princeton.edu/memory/ [62] http://fuse.sourceforge.net/fuse_structure.png [63] http://jt.wz.cz/vytvory/cryptfs/cryptfs.htm [64] http://en.wikipedia.org/wiki/Trusted_Platform_Module 7 Přílohy

7.1 truecrypt.patch diff -ruN truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c truecrypt-4.3a-source- code_new/Linux/Kernel/Dm-target.c --- truecrypt-4.3a-source-code/Linux/Kernel/Dm-target.c 2007-04-24 18:32:06.000000000 +0200 +++ truecrypt-4.3a-source-code_new/Linux/Kernel/Dm-target.c 2008-04-20 08:02:36.000000000 +0200 @@ -157,7 +157,7 @@

if (argc != TC_LAST_ARG + 1) { - ti->error = "truecrypt: Usage: truecrypt "; + ti->error = "truecrypt: Usage: truecrypt "; return -EINVAL; }

@@ -171,7 +171,7 @@ memset (tc, 0, sizeof (*tc));

tc->ci = crypto_open (); - if (tc == NULL) + if (tc->ci == NULL) { ti->error = "truecrypt: Cannot allocate crypto_info"; error = -ENOMEM;