Ochrana TrueCryptovského kontejneru
Při používání TrueCryptu skoro každý uživatel dříve či později narazí na otázku, jak vlastně ochránit šifrovaný kontejner před smazáním či poškozením. Jistě, data v něm uložená jsou chráněná silnou šifrou a kdo nezná heslo, tak se k nim nedostane, ale kontejner sám nijak chráněn není. Proč TrueCrypt nějakou ochranu nenabízí a jak to tedy udělat jinak?
Odpověď na otázku „proč“ je velice jednoduchá, i když možná ne úplně zřejmá: I kdyby ochranu kontejnerů autoři TrueCryptu zavést chtěli, jakože nechtějí, tak to vůbec nejde udělat. Stejně jako hodně jiných požadavků i tento naráží na to, že jednou z klíčových vlastností TrueCryptu je tzv. „plausible deniability“, tj. schopnost uvěřitelně tvrdit, že žádná šifrovaná data nemáte. To mimo jiné znamená, že TrueCryptovský kontejner nejde nijak identifikovat, dokud k němu uživatel nezadá heslo. Kdyby tedy měla ochrana kontejnerů fungovat, musela by buď omezit vlastnost plausible deniability (například přidáním nějaké identifikovatelné hlavičky kontejneru, u souborových kontejnerů vyžadováním nějaké standardní přípony apod.), nebo chránit všechna data s určitými charakteristikami (velikost, entropie obsahu). Obojí je těžko přijatelné, i kdyby to snad někdo chtěl implementovat – plausible deniability je velmi vysoko na žebříčku priorit vývojářů TrueCryptu, ochrana všech dat by zase byla velmi výpočetně náročná (ověřovat entropii při každém otevření souboru?) a nutně by vedla k velkému množství falešných poplachů (například komprimované soubory soubory – třeba videa – se v mnoha ohledech podobají šifrovaným kontejnerům).
Nedal by se tedy najít nějaký jiný způsob, jak kontejnery ochránit nezávisle na TrueCryptu? Dal. Operační systémy v sobě obsahují i mechanismy pro ochranu dat, tudíž i šifrovaných kontejnerů. Jsou zde ovšem jistá omezení, se kterými je třeba počítat. V první řadě je třeba si uvědomit, že nezanedbatelné množství operačních systémů je psaných tak, aby oprávněnému uživateli dovolily s daty manipulovat. Uživatel si pochopitelně může svoje oprávnění snížit, ale i naopak / téměř vždy se s větším nebo menším úsilím může dostat do pozice administrátora systému a všechna omezení obejít. Z tohoto důvodu nemůže být ochrana TrueCryptovských kontejnerů absolutní („chci udělat absolutně nesmazatelný kontejner“) – ten, kdo bude chtít kontejner úmyslně poškodit, to dokáže. Lze ale – za vhodných okolností – zařídit ochranu proti poškození „z blbosti“. Konkrétní postupy popíšu pro operační systémy Windows řady NT (což je všechno kromě Windows 95, 98, ME a šestnáctibitových 1.0 až 3.11); použitelností na jiných OS si nejsem jistý, protože využívám určitých specifik Windowsovské implementace TrueCryptu.
Pro účely ochrany kontejneru je podstatné to, o jaký kontejner vlastně jde. TrueCrypt totiž umožňuje vytvářet tři hlavní typy kontejnerů, které se z hlediska možností ochrany chovají úplně odlišně:
Device-based kontejnery
Device-based kontejnery se vyznačují tím, že pokrývají celou datovou plochu zařízení – celý disk, celou USB klíčenku, výhledově třeba možná i celé DVD. To má, kromě maximálního výkonu, i pozitivní bezpečnostní dopady – zašifrované je kompletně celé zařízení, není na něm sebemenší nezašifrovaná část (pochopitelně mimo servisní oblasti hardwaru, které by neměly být softwarově přístupné). Bohužel to má i dopady co do možností ochrany – takto zašifrované zařízení se totiž nedá odlišit od zařízení zcela nedotčeného. Operační systém pak pochopitelně toto zařízení považuje za nezformátované a uživateli více či méně iniciativně nabídne jeho zformátování. Windows například při spuštění Správce logických disků zobrazí takovéhle okénko:
Na tom není nic špatného, málokterý uživatel chce mít v počítači disk, který nemůže používat, ale zrovna u device-based kontejnerů to je docela problém, protože zápis na zašifrovaný disk s největší pravděpodobností naboří šifrovanou hlavičku kontejneru a tím celý kontejner znepřístupní. Windows konkrétně inicializací myslí to, že se do prvního sektoru disku (to je ten, do kterého TrueCrypt ukládá šifrovanou hlavičku) zapíše minimálně čtyři bajty na offset 01b8h („disk signature“) a dva bajty na offset 01feh („MBR signature“) – a s trochou smůly zapíše i celý standardní zavaděč (440 bajtů od počátku sektoru). To u starších TrueCryptů (před verzí 6.0) znamenalo ztrátu obsahu standardního (ne-skrytého) svazku, TrueCrypt 6.0 se svou záložní hlavičkou už se s tím vyrovná (i ve starších TrueCryptech se s tím někdy dalo vypořádat, ale to si případně nechám do nějakého budoucího článku nebo do fóra).
Nepříjemná zpráva tedy je, že device-based kontejnery se ochránit nedají vůbec.
Partition-based kontejnery
Kontejnery postavené na šifrovaných partition se navenek velice podobají disk-based kontejnerům, zejména v nejobvyklejším případě, kdy je na disku jediná partition. Rozdíl je v tom, že u nich není šifrovaný celý disk, ale jenom celá partition – na disku zůstává nezašifrovaná první stopa nesoucí mimo jiné Master Boot Record s tabulkou rozložení partition. To s sebou přináší nepříjemné dopady na plausible deniability (nemůžete dost dobře tvrdit, že ten disk jste si teprve přinesli z obchodu a nic na něm není), na druhou stranu to řeší problém inicializace a v jisté míře i problém ochrany kontejneru. Pokud totiž tu partition table vytvoříte s rozmyslem, operační systém se sám postará, abyste do ní omylem něco nezapsali. Stačí jediná věc – nastavit typ partition (byte na offsetu 0004h od začátku informace o partition) na hodnotu, kterou váš operační systém nezná (tj. pod Windows třeba na 63h – seznam zde). Pokud nevíte, jak na to, tak nejjednodušší je před šifrováním tuto tuto partition zformátovat v některém Linuxu.
Toto řešení ochrání kontejner před náhodnou inicializací, pořád ale můžete celou partition zformátovat.
Souborové kontejnery
Nejlépe lze ochránit kontejnery souborové (uložené v jednom velkém souboru), ovšem za předpokladu, že vámi používaný systém souborů pracuje s přístupovými právy (ve Windows tedy NTFS). Pak totiž jde souboru nastavit práva tak, aby do něj nešlo zapisovat nebo ho mazat, a operační systém už se sám aktivně postará o to, aby tato práva vynutil. Slyším vás ptát se, „a k čemu mi bude kontejner, do kterého nemohu zapisovat?“ Žádný strach, speciálně ve Windows existuje docela sympatická finta, která zablokuje kontejner pro všechny zápisy kromě zápisů do šifrovaného svazku! – tedy jinými slovy, do kontejneru nebudete moci nic zapsat hexa editorem ani ho nebudete moci smazat, ale pokud ho standardně připojíte, můžete zapisovat do jeho obsahu.
Celá finta spočívá v tom, že TrueCrypt není interně tvořen jediným programem, ale programy třemi: grafickým rozhraním pro správu kontejnerů a svazků, grafickým rozhraním pro vytváření kontejnerů, a ovladačem pro přístup k obsahu kontejnerů. Jak to vypadá, když připojujete existující kontejner? Nejdříve se spustí Správce, vyžádá si heslo a pokusí se tohle heslo použít k rozšifrování hlavičky kontejneru. Když se mu to podaří, načte si z hlavičky kontejneru základní údaje a spolu se šifrovacím klíčem je předá Ovladači, aby se ten postaral o zbytek; správce už odteď není k práci se šifrovaným svazkem potřeba, ke slovu přijde až na konci práce, kdy chcete svazek zase odpojit.
Pro zabezpečení kontejneru je podstatné, že tyto dvě části mají odlišné požadavky na práva (Správci stačí, aby mohl kontejner číst, zatímco Ovladač potřebuje i zápis) a že za standardních okolností každá část běží pod jiným uživatelským kontem (Správce se spouští pod tím uživatelem, který je zrovna do systému přihlášen, zatímco Ovladač běží pod systémovým účtem). Nic tedy nebrání tomu, změnit práva ke kontejneru tak, aby byla pouze dvě platná práva: EVERYONE (nebo USERS, případně dokonce jen uživatel, který má kontejner používat) potřebuje jen právo „R“ („číst data“, „číst oprávnění“), SYSTEM si vystačí s „RW“ („číst data“, „zapisovat data“). Pak dokážete kontejner normálně připojit (to dělá Správce s právem „R“) i do něj zapisovat (to dělá Ovladač s právy „RW“), ale nedokážete ho smazat (nikdo nemá právo mazání „D“) a za normálních okolností ani nabořit (protože jediný, kdo může zapisovat přímo do kontejneru, je SYSTEM, pod kterým obvykle žádná uživatelská aplikace neběží). V případě nutnosti ovšem administrátor může práva přidat (třeba „D“, aby mohl kontejner smazat) – ale není to něco, co byste dokázali udělat náhodou, omylem.
Jediná otázka je, jak ta práva vlastně prakticky nastavit. Já pro nastavování práv používám prográmek FileACL, se kterým jde udělat skoro všechno – až na jednu věc: nepodařilo se mi najít způsob, jak jenom s ním ochránit kontejner, který už má nějaká zděděná práva (typicky je umístěn v nějakém podadresáři). To naštěstí není problém v případě, že začínám s čistým zformátovaným diskem, na kterém se bude nacházet právě jenom šifrovaný kontejner a nic jiného (běžný případ u externích disků). V takovém případě proběhne nastavení práv dost přímočaře (předpokládám, že disk má písmeno D: a už je v něm vytvořen příslušný kontejner):
-
Příkazem
FILEACL D:\si nechám vypsat existující práva k disku. Vypadá to nějak takhle:
-
Následně smažu všechna práva a nechám jen „RX“ pro uživatele
EVERYONEa „RWX“ pro uživateleSYSTEM. Příkaz pro to se liší podle toho, jaká práva máte nastavena, pro příklad výše to jeFILEACL D:\ /R Everyone /R Users /R System /R "Creator Owner" /R Administrators /G Everyone:RX /G System:RWX.(Pokud vás zaráží, že dávám větší práva, než bylo uvedeno výše, je to proto, že „X“ potřebuji pro práci s hlavním adresářem.)
(Použití pouze uživatelů
EVERYONEaSYSTEMmá ještě tu výhodu, že to bude správně fungovat na všech počítačích, protože tito uživatelé mají vždy stejné SID – kdybych použil běžné uživatelské jméno, bude to fungovat jen na tom počítači, na kterém jsem to nastavoval.) -
Ještě jednou zopakuji
FILEACL D:\, abych se přesvědčil, že to dopadlo dobře. Všechna práva by měla zmizet, zůstanou jenom ta, která jsem v příkazu výše napsal za/G. -
Nakonec ověřím práva i pro samotný kontejner (příkazem
FILEACL D:\kontejner.tc) a případně všechna smažu, aby zůstala jen práva zděděná.
Jiná situace je, pokud se kontejner má nacházet v nějakém adresáři, který už sám má nějaká zděděná práva. Principiálně by mělo stačit odstranit dědičnost (to se mi v FILEACL nepodařilo najít, ale Explorer pod Windows XP Professional to umí ve svém grafickém prostředí, pokud máte vypnuté Zjednodušené sdílení) a pak postupovat podle návodu výše, nedošel jsem ale k úspěšnému výsledku – i když u kontejneru bylo jenom právo „R“ pro EVERYONE, stejně ho mohl Administrátor smazat; to u přístupu výše neplatí, tam byl i administrátor sám bezmocný (dokud si zase oprávnění nepřidal, pochopitelně). Zkoušel jsem experimentovat i s „právem“ DENY (popření práv), ale také jsem nebyl úspěšný. Přivítám radu od někoho, kdo si s touhle situací dokáže poradit kompletně. Zatím se musím spokojit s tím, že umím chránit jen souborové kontejnery uložené na externích discích.
Závěr
Tímto postupem tedy jde ochránit kontejner před neúmyslným smazáním či poškozením. Zbývá ovšem podotknout dvě důležité věci:
-
Není to ochrana proti úmyslnému poškození – administrátor systému si vždy může potřebná práva přidělit, případně může kontejner nabořit pomocí diskeditoru.
-
I kdyby ke ztrátě dat došlo, tak to ničemu nevadí, protože pochopitelně od všeho máte aktuální zálohu. Nebo snad ne? V tom případě si ji honem vytvořte – co budete dělat, když disk umře nebo vám klíčenku někdo ukradne?
Daniel Andrascik: Osobně jsem se výkonem šifrovacích nástrojů nikdy nezabýval, protože 1) se primárně řídím podle jiných vlastností a jen zřídka kdy dojdu do situace, kdy mám dva různé nástroje, které by byly ve všem kromě výkonu rovnocenné, a 2) šifrovací výkon je už nyní natolik vysoký, že mě rozdíl 5 nebo 10 procent v podstatě nezajímá. Nicméně pokud ti jde o maximální výkon, tak z technického pohledu má šifrování celého disku nebo celé partition (to je rovnocenné) výhodu nad šifrováním celého svazku, a ten má výhodu nad šifrováním souborového kontejneru.
Dik za odpoved. Doposial som pouzival EFS. Krasne na nom bolo ze sa dalo toto kryptovanie zapnut napriklad len pre adresar s dokumentami a ze kryptovanie je zviazane s uzivatelskym uctom. Nie je to ale zrovna najbezpecnejsie, utocnikovy stacit prelomit uzivatelsky ucet, pripadne som pocul ze kluce sa daju vyextrahovat z registrov.
Teraz uvazujem ze by som si vytvoril 100G particiu na dokumenty a tu by som zakryptoval nejakym riesenim. Bud TC, DiskCryptor (niektory uzivatelia tvrdia ze je rychlejsi ako TC), alebo pripadne este tebou odporucany BCVE. Zatial nie som rozhodnuty.
Ostava mi sa este rozhodnut ci pouzijem drive-based kontajner, alebo file-based. S file-based kontajnerom je najlachsia manipulacia a ako hovoris najmansia pravdepodobnost ze sa nieco nechtiac pokasle. Ale som skuseny uzivatel, takze si myslim ze by som si vedel dat pozor. Najviac ma vsak zaujima vykonnost riesenia – performance. Neviem ci je nejaky vykonsotny rozdiel medzi suborovym kontajnerom o velkosti cca 100G, alebo partition kontajnerom identickej velkosti.
Inac musim ti vyjadrit velke uznanie za tvoje stranky. Uz nejaky ten cas po nich beham a uvadzas tu dobre spracovane a velmi zaujimave a fundovane informacie.
Daniel Andrascik: V případě fyzického poškození se šifrovaný kontejner, a je jedno jakého druhu, chová přesně stejně jako normální nešifrovaný disk – tzn. poškodí se pouze ten jeden sektor. Stejně jako u klasického disku to nemusí nic znamenat, pokud se chyba trefí do prázdného místa nebo do nekritických souborů (video apod.), nebo to může znamenat i značné poškození, pokud se chyba trefí do systémových oblastí svazku. Navíc je jediné poškození – kdyby se chyba trefila do hlavičky kontejneru, tak přijdeš o všechno. Teď už to není tak kritické, protože TC kontejnery mají hlavičku zkopírovanou ještě na konci kontejneru, ale přesto je dobrý nápad si tu hlavičku zazálohovat.
Na tom, jestli je to souborový kontejner nebo partition nebo disk nezáleží, až na tu výhradu, že – jak jsem psal v článku – zatímco souborový kontejner jde chránit před chybou uživatele, partition už hůř a disk vůbec.
Mna by zaujimalo ako to je ak dojde dajme tomu k hw poskodeniu nejakych clusterov file kontaineru pripadne partition-based kontaineru. Neriesme teraz zalohovanie, zalohovanie pouzivam a samozrjem mam zozalohovane hlavicky kontajnerov. Cize zaujima ma ci poskedenie niekolkych fyzickych clusterov poskodi len subory ktore na danych klusteroch fyzicky lezia, alebo moze dojst k totalnemu zlyhaniu dátovej struktury kontaineru a stratia sa vsetky data v kontajneri. A potom ktory typ kontajnera co sa tyka odolnosti voci poskodeniam je na tom lepsie: file-based kontainer, alebo partition-based kontajner.
Proti nechcenému zformátovaniu – aspoň vo WindowsXP – som si vymyslel jednoduchú fintu – „poškodil“ som diskmgmt.msc a compmgmt.msc prepísaním namiesto „.msc“ na „_msc“.
Samozrejme chce to mať viditeľné prípony a možno zakázanú automatickú obnovu systémových súborov…no predpokladám, že kto sa trebárs zo zvedavosti ako ja hrá s Truecryptom také veci zvládne 🙂
Jeen: Nevím, nezkoumal jsem nikdy, co se nachází na nových discích různých výrobců, ale vůbec by mě nepřekvapovalo, kdyby skutečně aspoň některé obsahovaly náhodná data (schopnost disku pojmout data se tím ověřit dá a má to výhodu, že se potom ten disk nemusí mazat). Pokud jsou tam nějaká nenáhodná data, tak bys asi musel argumentovat tím, že se disk chystáš prodat a tak jsi ho prohnal DBANem…
Myslím, že ani u device-based kontejneru nelze dost dobře tvrdit, že ten disk jste si teprve přinesli z obchodu a nic na něm není.
Nové disky mají přece všude nuly nebo všude jedničky. Rozhodně tam nejsou jakási náhodná data. Někdo kdo hledá zašifrované věci jistě bude mít možnost číst i „neinicializovaný“ disk. Ostatně to není problém, vždy se koukám po nákupu co tam je. Mimochodem takové flash karty jsou zpravidla „předinicializované“.
Teraz vlastne uvažujem, že som na skúšku dal zašifrovať disk na ktorom je 32 bit vista (ale boot bol na inom disku). Asi to bude tým, skúsim to ešte aj inými spôsobmi potom.
Jediné, co mě napadá, že jsi nezašifroval celý disk ale jen partition rozprostřenou přes celý disk (tzn. že disk už byl inicializovaný).
Teraz neviem čo som robil inak, pretože aj ty to spomínaš, aj synopsi to má v screenshote, ale mne nič také správca diskov neponúkol.
Díky za doplnění. Já jenom znovu připomenu, že když už budete odstraňovat to písmenko jednotky, tak pozor na to, abyste omylem nepotvrdili inicializaci disku, kterou Správce logických disků nabídne.
Jednu vec by som doplnil k „Device-based“ kontajnerom – teda celým šifrovaným nesystémovým diskom, konkrétne k nemožnosti ich ochrany. To čo napíšem nie je síce priamo typ ochrany akú uvádzaš ty, ale aj tak je pomerne užitočná. Ak zašifrujem nejaký nesystémový disk (povedzme že je to interný disk D), tak ho stále vidím pod „tento počítač“. Do truecryptu ho musím pripájať skrz nejaké iné písmenko. Bohužiaľ keďže D stále vidím v tento počítač, tak na D sa dá samozrejme aj kliknúť. Bez ohľadu na to či je disk cez truecrypt práve pripojený alebo nie, Windows nevie že Dčko je zašifrovaný disk a okamžite ponúka formát disku. A myslím, že aj skúsenému sa môže stať, že sa bez rozmyslu preklikne. Preto by prvá cesta po zašifrovaní disku mala viesť do správy počítače – správa diskov – D – zmeniť písmeno jednotky a cestu – odobrať. Tým dosiahneme, to, že tento nezašifrovaný disk nebudeme vidieť cez „tento počítač“, ovšem v truecrypte po voľbe „vybrať zariadenie“ ho uvidíme stále (bez písmenká) a je možné ho normálne pripájať a klasicky s ním pracovať.
Ah! Ochrana kontejneru v podadresáři před smazáním spočívá v tom, že navíc k zablokovanému právu „D“ (mazání) u souboru je potřeba zablokovat právo „W“ (zápis) k adresáři. Vcelku logické, když o tom tak uvažuju.
Takže už zbývá poslední věc: jak ze souboru/adresáře odstranit zděděná práva pomocí FILEACL.