Názory k článku TrueCrypt: profesionální ochrana dat zdarma

protože člověk nikdy neví, co ve swapu skončí, může se do něj dostat cokoli s čím uživatel pracuje. Na Linux jde swap zakázat, jde to nějak i na Windows?

Další nebezpečí je v tom, že člověk si třeba WWW prohlížečem na šifrovaném disku otevře soubor a WWW prohlížeč název souboru iniciativně uloží do historie stránek, která je však na nešifrovaném disku --- existuje někde seznam programů, které je možno na šifrovaném disku používat bez nebezpečí, že budou informace vynášet mimo ten disk?

Tady nastupují na řadu aplikace pro šifrování celých diskuů.

Windows to defaultne hází někam do "oblasti rezervované by OS" - což je neznámo kde ... jinak WinXP _vždy_ swapuje, swap mu nejde zakázat, dokonce pokud to uděláte, bude si swapovat, kde se mu zachce (z pohledu struktury disku - od začátku na konec), jde ale určit specifická partition, kde má swapovat... ale vypnout? Je to přece Windows.. :-)

presnejsi je, ze volba na vypnuti swapu tam je, nicmene jak bylo napsano o par prispevku vyse, stejne to swap nevypne a xp si swapuji vesele dale. naivne jsem si myslel, ze kdyz k 1GB ram prikoupim jeste dalsi 1GB, tak nebudu swapovat, protoze jsem mel vzdy ten druhy 1GB volny - jak jsem se mylil. co z toho plyne? => windows xp neumi ani vypnout swap ani pouzit ram na 1GB :o(

blbost!!!!

winXP dokaze vypnut swap suubor!!! len Ty to nevies nastavit!!!
system properties->advanced->performance options (advanced)->virtualmemory (change) - a tu zapinas a vypinas swap subory, mozes urcit i na ktorom odiely kolko budes/nebudes mat..

mam 2GB pamate, funguje to ok i pri 1Gb pamate..

To je zvlastni a to sem si myslel, ze Linux je uzivatelsky slozitejsi. Swapak ve win umi vypnout i moje mati .... takze k tomuto tematu o nevypnutelnosti SWP uz asi neni co dodat:)

A skusil si na ten 1GB, ktory si dokupil, nahodit ramdisk, a swap presmerovat nan? Kdesi som cital, ze to ide. Problem je len v tom, ze musis pouzit daky iny ramdisk-driver, lebo ten co je vo windows neumozni vytvorit taky velky virtualny disk...

Skus si na stroji, ktory ma 64MB RAM, vypnut swap vo win2k. Uz sa nezalogujes a mozes to preinstalovat. Takze vypnut to ide :)

No ja neviem ale ja by som nabehol do nudzoveho rezimu a tam to o5 zmenil...

já bych šifroval taky komunikaci klávesnice-počítač, protože to jde taky odchytit.

Ve Windows jde zapnout, aby se při restartu (vypnutí) swap soubor promazal. Mimoto, swap lze vypnout normálně v menu.

Ve Windows jde zapnout, aby se při restartu (vypnutí) swap soubor promazal.

To je sice hezké, ale moc bezpečné mi to nepřijde. Kde máte zaručeno, že se skutečně přepíšou všechny sektory, kde se swap soubor rozprostírá? A s příslušným vybavením se dá údajně dostat i k několika předchozím vrstvám magnetického záznamu na pevném disku.

Tak samozřejmě, promazat neznamená "bezpečně přepsat sektory" - jako to umí např. open source Erase. Jde jen o funkci lepší než nic :-)

Pro tohle konkrétní použití bych s ohledem na bezpečnost řekl, že jde o funkci horší než nic. Nabízí falešný pocit bezpečí, zatímco otevírá dveře útočníkovi.

Na Linux jde swap zakázat

Na Linuxu se swap šifrovat samozřejmě dá. Třeba náhodným heslem při každém bootu. Zakazovat swap netřeba.

http://www.truecrypt.org/third-party-projects

TCTEMP

Description: TCTEMP automates the process of using TrueCrypt to on-the-fly encrypt the Windows paging (swap) file, temporary files, and print spooler files.

Mam podezreni, ze pod kernelem 2.6 si muze i neprivilegovany proces poridit neswapovatelnou pamet. Overit to jde treba memtest(1)em.
DoS skoro ukazkovy. Resenim je ulimit, mozna taky sysctl.

Ahoj, i na na windows jde pagefile vypnout... zalezi to ale na nekolika okolnostech. V zasade to chce mit dostatek ram (pro moji beznou praci je 1.5GB ok) a aplikace, ktere explicitne pagefile nevyzaduji. (Moc takovych, ktere by na nem opravdu trvaly neni, ale napriklad photoshop na tom trva (aspon kdysi verze 5)...)

A dalším velkým problémem je adresář /tmp, kam spousta programů píše (třeba Acrobat Reader) --- čili si otevřete dokument ze šifrované USB klíčenky a máte ho rozšifrovaný na disku, ani nevíte jak. Po zavření ho Acrobat smaže, ale tím hůř --- sektory obsahující data tam zůstanou a nevíte, kde jsou. To by fakt chtělo udělat audit programů, co se na šifrovaném disku používat smí a co ne, a jak to nastavit, aby to ta data neroznášelo.

Takhle se chová taky winRAR. Když máte soubor, kde se bez hesla nedá přečíst ani vnitřní struktura, v grafice winRARu ho otevřete a chcete jeho obsah rozbalit, udělá si kompletní "zálohu" do tmp a nesmaže ji ani po ukončení, což je příšerný. V Linuxu je jen konzolová verze, která to snad nedělá, ledaže by se podobně choval např. Ark, nebo jiný nástroj pro zacházení s archivy.

co tak pouzivat RAM disk?
nastavis si povedzme 256MB, prepises cesty pre temp a tmp na tuto jednotku..a po vypnuti kompu si mozes byt isty, ze nik nenejjde nic v temp adresaroch..

Tak prostě zašifrujete celý systém (s výjimkou zavaděče a obrazů jádra). Pak je úplně jedno, co který program dělá v /tmp, /var, apod.

ja bych nespolehal na to, ze po resetu NEKDO smaze celou pamet
Jedine tak vypnout, pockat 5 minut, zapnout

tmpfs je dobrý nápad. Předtím, než je paměť přidělena nějakému procesu, je vynulována, takže nebezpečí, že by někdo ta data odtud četl, není. Jen je třeba dát pozor, aby se obsah toho tmpfs nedostal do swapu (buď ho šifrovat nebo zakázat).

Moc pěkný článek. Uvítal bych podobný článek zaměřený na nativní řešení Linuxu, tedy dm-crypt a LUKS.

nápodobně

http://gentoo-wiki.com/SECURITY_Encrypting_Root_Filesystem_with_DM-Crypt_with_LUKS

http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS

Díky, ale já nemám problém s tím, jak to zprovoznit, to už jsem dávno nastudoval a provedl. Tenhle článek je zajímavý tím, že se v něm expert na šifrování vyjadřuje k určité implementaci šifrovacího systému (Truecrypt). Já používám dm-crypt a LUKS, a právě proto by mě zajímalo, jak vidí stejný expert toto řešení, z kryptografického hlediska.

Chtěl bych mít možnost rozšiřovat kryptovaný disk podle potřeby. Disk MUSÍ být umístěn v souboru. TrueCrypt to zřejmě neumí. Existuje nějaké jiné řešení?

To není to na co jsem se ptal. Já bych chtěl ten 600MB soubor zvětšit na 900MB. Pochopitelně bez přeformátování a se zachováním stávajících dat na tom zašifrovaném disku.

Z tohoto důvodu používám na desktopu s linuxem encfs (pro domovský adresář). Je škoda, že encfs nemá kvalitní GUI frontend (kencfs nic moc...).

Má zřejmě pár nevýhod (menší výběr šifer, pomalejší), ale pár uživatelských výhod (na nešifrovaný disk se ukládají šifrované soubory jednotlivě, tj. menší riziko poškození všech šifrovaných dat; nejsou problémy s využitím místa - znáte to, rozdělíte disk na oddíly pro domovské adresáře a pro šifrovaná data a pak zjistíte, že na jednom oddíle je zbytečně moc místa a na druhém jste na nule).

Nicméně ve Windows používám TrueCrypt, je to skvělý software.

Ano encfs znám. Ale neskrývání metadat souborů je pro mě neakceptovatelné.

Kdyz jsem resil s TC obdobny problem tak jsem to vyresil tak, ze jsem si vyrobil 900Mb sifrovany soubor, do nej nakopiroval data z toho 600Mb sifrovaneho disku a ten pak smazal. Data se zachovaly :)

Tohle v TC mozne neni. Jedine co lze je vytvoreni "dynamickeho" disku (presny termin nevim, ale je mozno dohledat v dokumentaci), kde nastavite maximalni velikost a on pozdeji roste dle potreby. (hrube se nedporucuje z duvodu bezpecnosti, spolehlivosti a vykonu :) ) Zkousel jsem a je to opravdu katastrofa, nicmene je dobre mit tu moznost.

Do určité míry lze (alespoň na Windows) něčeho takového dosáhnout pokud je kryptovaný disk umístěn jako soubor v systému NTFS. Nový Truecrypt umí vytvořit kryptovaný disk jako tzv. sparse file, tj. soubor, kde se nulové bloky dat na fyzické médium nezapisují. Takový soubor (v tomto případě kryptovaný disk) se pak tváří, že má třeba 40 GB, ale jeho fyzická velikost začíná na pár megabajtech a postupně se zvětšuje s tím, jak do něj přibývají data.

Samozřejmě se tím nejspíš o něco sníží bezpečnost, protože lze pak na první pohled určit, které části kryptovaného disku obsahují data a které nikoliv.

Díky. Škoda, že je to skutečně implementováno jen pro Windows. I když i například ext3 sparsefile umí tak si nemyslím, že tohle je ta správná cesta.

Kdyz to TrueCrypt neumi, tak bych doporucil si precist clanek, nebo aspon prvni odstavec, ver mi, pak uz to TrueCrypt umet bude

Pane chytrý můžete mi zkopírovat relevantní část, která popisuje co potřebuji? Děkuji.

Njn, jsem to spatne precetl:) Ale zkusil bych rozsirit fyzickou partisnu na ktere to je a pak pri namountovanem disku rozsirit velikost partisny i tam. Pokud program dela jenom to, ze na jiste partisne prevadi data mezi OS a driverem, tak by to z principu melo fungovat, ale je to spis otazka na autory nebo to zkusit. Rozsirovani partisny by muselo nasledovat tak i tak. Jinak u souboru stejnym zpusobem jako u fyzicke partisny. Ve win32 je na to dokonce funkce.

Este by ma zaujimalo preco?

Tak to by mne zajimalo jak to u toho APOP prohiha.

Nasadi-li se man-in-the-middle, tak pri prvnim (u tupejsich useru mozna az pri druhym nebo tretim) pozmenenym C nebo poslane response se to provali, nebot server odmitne autentizaci.

A pokud odposlechnu nejakou serii Cx, a MD(Cx || pass) tak v tom nevidim zpusob jak vyuzit ty kolize k prolomeni. Teda pokud tam neni nejaky flaw typu ze Cx muze byt jedna z 256 moznych nebo tak neco.

To priznam se nevim, ale tusil bych ze postovni program to zkusi asi jen jednou a pak zarve ze je spatne heslo (pri klasicke autentizaci taky nema smysl zkouset to same heslo dokola kdyz server napoprve rekl ze je spatne) ... a pak je to na uzivateli, aby si to nejak prebral

Otazkou pak je spis kolikrat uzivatel bude mackat nejake tlacitko na zpusob Reconnect/Retry nez mu dojde ze je tu asi neco spatne ...

Zase na druhou stranu, pokud server odpovi ze heslo je dobre a nabidne uzivateli ke stazeni prazdnou schranku (nebo treba par spamu at to vypada ze tam "neco je" :), tak si toho ze je neco spatne muze dotycny vsimnout pozdeji (pokud ceka na nejaky email a ten ne a ne dorazit, ale pri takovehle netrpelivosti pak muze kontrolovat schranku treba i kazdou minutu, cili vice poslanych challenges a vice prijatych responses)

Na druhou stranu, pokud stahovani mailu bude probihat nejak automaticky (napr. "zkontrolovat kazdych 5 minut novou postu") tak se muze program bez "vedomi" uzivatele pokouset treba kazdych 5 minut o pristup do schranky ...

Kolik challengi je takhle potreba postat a dostat zpet aby se heslo prolomilo?

a jak je to s rychlosti encrypt-decrypt?

Je tam benchmark, aspon ve win verzi. Pouzivam twofish a je to kolem 60MB/s na 3GHz P4, cteni o neco malo rychlejsi, ale v podstate stejne. V realu to nezatezuje prakticky vubec, leda pri kopirovani velkych mnozstvi dat a to pravda neni nejbeznejsi, navic i rychlost te x let stare P4 je za hranici rychlosti disku, takze v dnesnich C2D a podobnych je to uz uplne irelevantni:)

Jen tak pro upresneni, ATA password na disku nejde obejit jinou elektrikou, v praxi to znamena, ze pokud si ho zamknes (nebo nejaka el. havet pokud nemas BIOS co to umi freeznout - vetsina BIOSU to neumi!), tak prijdes o data a pomuze ti jenom zaplatit xx tisic za recovery od nejake specializovane firmy

Je nějaký způsob, jak pod Linuxem zašifrovat celý disk se systémem? Na workstejšně doma je mi to jedno, ale na notebooku bych to rozhodně přivítal. Pokud vím TrueCrypt toto neumí, jinak je to samozřejmě vynikající nástroj, který používám. Už se těším na GUI, i když i z komandlajny to funguje skvěle.

Reseni existuje - luks. Kdysi jsem si sam pro sebe napsal navod, jak toho dosahnout. Pokud te to zajima, tak se podivej na http://www.jetpac.org/wiki/index.php/VAIO#Encryption_setup

Mam tam sled kroku, vysvetleno tam neni nic. Jak to funguje muzes najit v odkazech na pouzitou literaturu na konci stranky.

Pokud by si v tom navodu nasel jakoukoliv chybu, dej mi prosim vedet, opravim to. Diky.

Díky za info, určitě na to mrknu.

* Fill the /dev/sda3 partition with garbage:
dd if=/dev/urandom of=/dev/sda

Chybí ti tam ta trojka. Copy&paste by pak nadělalo pěknou paseku :-)

Diky - opraveno :-)

Od verze jádra (tuším) 2.6.20 podporuje CryptoAPI v Linuxu mód LRW (viz článek). Ten je třeba při tvorbě šifrovaného oddílu zadat (jinak je default aes-essiv):

cryptsetup -c aes-lrw-benbi -h sha256 -s 384 -y luksFormat /dev/neco

Je nějaký způsob, jak pod Linuxem zašifrovat celý disk se systémem?

Samozřejmě, viz dm-crypt a LUKS. Jediné, co zašifrovat nejde, je obraz jádra, zavaděč a initrd (čili /boot). Všechno ostatní zašifrovat jde.

HTH

Trochu mě zarazilo hodnocení keyfiles, že mohou prodloužit útok hrubou silou jen o zlomky vteřin. Platí to i v případě, že útočník obsah keyfile(s) nezná?

Měl jsem totiž za to, že obsah keyfile se "nějak" aplikuje na password, a tom případě by IMHO stačilo i prosté XORování, aby se ze slabého hesla stalo silné (tedy pokud má heslo rozumný počet znaků a keyfile je dostatečně randomizovaný).

(Že to není XORování jsem si našel na http://www.truecrypt.org/docs/?s=keyfiles-technical-details , ale je to na mě moc složité, nicméně jsem si to vyložil tak, že se jedná skoro o totéž)

Keyfile, aspoň jak mu rozumím, by tedy měl být jakýmsi "privátním klíčem", který ze své podstaty musí zůstat útočníkovi utajen. Podobně jako u ostatních šifer, kde prozrazení privátního klíče v podstatě znamená její prolomení.

super clanek

Shodou okolnosti jsem se k TrueCryptu(btw i k svinstvu zvanem ATA security) dostal minuly tyden a funguje velmi presvedcive. Predpokladam, ze jste uzivatelem windows, zajimal by me vas nazor na kryptovani v ramci NTFS, vim ze tam jde o jiny system pomoci certifikatu a podobne, ale zajimala by me bezpecnost pripadne by jste mohl napsat nejake shrnuti, jak je to s temi certifikaty a podobne:) Asi ne na rootu, ale nekde jinde, nicmene myslim, ze by to hodne lidi zajimalo, jelikoz spousta lidi nema o podobnych vecech ani poneti (jak prenaset certifikaty a podobne) a studovat tyhle veci do detailu na MSDN v anglictine je pro vetsinu neprijatelne. Urcite by to byl zajimavy clanek. Jinak dekuju za tento:) Skoda, ze neprisel o tyden driv, pouzil bych whirlpool:o)

Je mozne pouzit TC vloume napr. na SD karte i na Windows Mobile 5? Hodil by se softik, ktery dokaze kryptovat jak na PPC tak v Linuxu.

cus,
hele jak resite kryptovani suspend image? priklad: po hybernaci notebooku se jde jeho majitel zhybernovat do putyky, kde mu je jeho stroj ukradnut, disk pripojen k jinemu stroji a prectena cela pamet "ziveho" stroje.
takze: hibernovat radeji na swap nebo do fajlu? jak resumnout z fajlu na cryptofs? slepice nebo vejce?
dik za kopnuti, tl.

Tohle resim jednoduse: nehibernuju.

Hibernovat na crypto partition samozrejme jde. Jen je potreba si trosku pohrat se startovacimi skripty a pred samotnou rehibernaci kernelu predhodit jiz decryptovany swap - napr /dev/mapper/swap.

Když moje poznámka došla takového uznání (děkuji), zkusím ještě trochu přispět na téma keyfiles. Jedná se o mé úvahy nad praktickým použitím vlasností popsaných zde: http://www.truecrypt.org/docs/?s=keyfiles

Osobně jsou mi keyfiles sympatické ze dvou důvodů: Jako keyfile se dá použít téměr jakýkoli soubor, takže se vlastně jedná o steganografii. Prosté scanování disku (i jen mallwarem) je schopno odhalit a ukrást různé certifikáty a privátní klíče, protože podle jejich vnitřní struktury se dá poznat, že jsou to privátní klíče. To u keyfiles nehrozí - nijak se neodlišují jiných běžných souborů.

Druhou sympatickou vlastností je možnost pomocí několika keyfiles obejít nutnost pamatovat si silné heslo, a to i v případě, kdy útočník zná všechny _potenciální_ keyfiles. Příklad: Na USB klíčence mám jednak nezakryptovaný oddíl a pak oddíl zakryptovaný TrueCryptem. V nezakryptovaném oddílu je, mimo jiné, cca 500 soukromých fotek. Mnemotechnicky vyberu 20 z nich (všechny z výletu na Kokořín, plus ty dvě, kde má Franta červené oči od blesku) a použiji je jako keyfiles. Možných kombinací je, tuším, 500! / (480!*20!) = 2,7e+35. Sice to není tak velké číslo jako 2^512, které odpovídá důkladnému 64 bytovému heslu, ale i tak mi to přijde velmi slušně zabezpečné proti útoku hrubou silou. Navíc to můžu ještě okořenit tím, že tam dám navíc jednu konkrétní fotku z flickr.com, která na USB disku nebude.

Sice to sám takhle důkladně nepoužívám, ale by člověk potřeboval např. odvézt větší množství dat (třeba dokumentární film) ze země, jako je Kuba nebo Čína, mohlo by se to hodit.

Podle mého názoru dokumentace TrueCryptu počítá s oběma možnými scénáři (utajené keyfiles vs relativně velký pool neutajených potenciálních keyfiles) a snaží to popsat jedním textem, což může být při prvním seznamování se s keyfiles matoucí.

Závěrem bych se chtěl připojit k ovacím za skvělý článek. Děkuji.

ma to pro me jednu zasadni chybu a to, ze to nebeha na BSD :(((( (a geli se s tim nemuze srovnavat)

http://www.root.cz/clanky/cryptoroot-pro-nejvyssi-bezpecnost-1/
http://www.root.cz/clanky/cryptoroot-pro-nejvyssi-bezpecnost-2/
http://www.root.cz/clanky/zaostreno-na-dm-crypt/

V diskusii na http://www.redhatmagazine.com/2007/01/18/disk-encryption-in-fedora-past-present-and-future/ sa objavila zaujimava kritika Truecryptu. Aj ked autor uviedol len prve meno (Greg) oplatilo by sa jeho tvrdenia preskumat:

Problems with TrueCrypt that DM-Crypt, LUKS, loop-AES, etc. do NOT have:
TrueCrypt has a number of problems IMHO– problems that are not shared by its counterparts mentioned above.

1) Secretive, hidden developer community: The controlling project developers and the so-called “TrueCrypt Foundation” are hidden behind an anonymous screen of Internet tools. Their “foundation” doesn’t seem to be registered ANYWHERE or tied to any physical location or official entity. Their identities, names, backgrounds, countries-of-origin, etc. are unknown to anyone but their inner-circle and they refuse to address this issue (or even to explain themselves). This kind of black-hat persona certainly doesn’t lend itself to the trust of a corporate/business world, for good reason.

Furthermore, they rule their community with an iron fist and do so inconsistently. This makes it extremely difficult to maintain a normal support atmosphere there (would-be community members leave and abandon the project on a regular basis).

2) Cumbersome, antiquated licensing terms: TrueCrypt was born out of the OLD Encryption-For-The-Masses framework (e4m) and contains the work of several other authors/packages with inconsistent licensing conditions. This has caused them trouble in the past, for example when they tried to move their product to the GPL (unsuccessfully).

3) Information control issues: Forums will be suddenly taken offline, apparently deliberately, as certain critical discussions occur. This occurs frequently whenever a new version is released. At the very least, this makes it very hard to support the product properly as a member of their user community, let alone the trust issues this causes.

Furthermore, there are no published bug reports or vulnerabilities listed anywhere except for whatever makes it into their forums and isn’t deleted. Their bug submissions are only accepted through a private Web form on their site.

Finally, certain forums aren’t even visible for public viewing unless you first register. No explanation has been given for this.

For all these and many reasons, I now favor the work done in the “open” world by these other projects and I will no longer personally support TrueCrypt as an encryption platform. If you want the time/effort of folks like myself, you’ll stay away from the TrueCrypt-style tactics I’ve described.