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ů.

Davide, na Linuxu to máme trošku jinak, swap je obvykle samostatný svazek (který samozřejmě můžeš a/nebo nemusíš šifrovat).

Předpokládám, že TrueCrypt (i dm-crypt) je možné použít i pro šifrování swapu - vyrábí z blokového zařízení opět blokové zařízení.

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(

zase nejakej chytrak, kterej si mysli, ze jenom on to v nastaveni nasel. samozrejme to tam mam vyple, ale kazdou chvili swapuje stejne a neni schopny zaplnit 2GB ram. zkuste si radeji precist neco o tom, ze holt tenhle nedostatek spatne spravy pameti resi udajne az visty, ale nemuzu to potrvdit - nemam je...

Ahoj,
1. To, ze se ti pamet zda zaplnena, neznamena, ze opravdu je. :)
2. To, ze neco hrabe na disk, neznamena, ze jde o swapovani. Pokud je to nejak excesivini zalezitost, doporucuju Process explorer od Marka Rusinoviche (~MS). Ten Vam spolehlive ukaze odkud vitr vane. (Neni neobvykle, ze programy samotne maji vehementni potrebu si neco ukladat do tempu. (At uz se rozhodnou pouzit systemovy temp nebo svuj vlastni.)

Pagefile samzorejme vypnout jde a kdyz je vypnuty, tak je vypnuty a nepouziva se.
Zdravim
Lukas

rad bych souhlasil, lec zkusenosti mi to proste nedovoli. timhle bych debatu ukocnil, protoze mame oba odlisne nazory - ja tvrdim, ze sprava pameti ve windows xp je mizerna a tvrdim to z pohledu vyvojare i uzivatele a taky si stojim za tim, ze si xp strankuji i kdyz je vyply swap :o(

Mno ja bych to urcite neukoncoval, protoze tohle rozhodne neni o nazoru. Rad se dozvim neco, co treba nevim. Jak to muzu zreplikovat a jak se muzu presvedcit o tom, ze si moje xp odsypavaji neco do pagefilu, i kdyz jsem jim pagefajl zakazal?
Mozna to chce asi nejake vyjasneni v terminech neb jsme se ochomytli kolem nedorozumeni... Souhlasime v tom, ze to ze strankovana pamet nemusi byt nutne v pagefajlu, ale muze bez problemu vegetovat v normalni ram, ze ano? :)

pro zacatek zkuste zaplnit pamet ram nad 2GB. mne se to nepovedlo a to jsem spustil opravdu mnoho programu (visual studio 2005, office, autocad, photoshop, ...). uzivana ram se drzi stale kolem 1GB a kazdou chvili pri praci zacne hrabat disk a to tak, ze vas odstrihne na 5s (nekdy i vice) od prace (zatuhne i kurzor) a pritom nedelam zadne operace, ktere by praci s diskem vyuzivaly. vlastne to nekdy necham jenom tak netecne stat. myslim, ze se vam to povede take...

jj uplne suhlasim mam 2GB RAM a tiez hned po zapnuti je swap zaplneny na 200MB, pri vypnutom swape my stale este hrabe po disku... Kde je potom problem v tom ze to nefunguje. Ja nechcem vyuzivat pomalsi disk ale rychlejsiu RAM. Proste nad 1GB RAM to XP nevie vyuzit a stale si vytvara swap hoci len malicky a veselo swapuje dalej (to je asi tych neuveritelnych 200MB co nemoze dat do RAMky).

Zkuste si spustit moderní hru a hned uvidíte, že 2GB není žádná míra :-)

Photoshop ma svuj vlastni swap, tak pozor na to...

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...

ano, tohle je fungujici reseni, ale pripadne mi to jako takova berlicka. system by mel umet vyuzit pamet, kterou mu tam strcim a kterou je cpu schopne adresovat, ale ja stejne prevazne pouzivam linux, takze me to az tak netlaci a nebyt klientu, kteri maji xp, tak bych tady snad ani nereagoval...

To je samozrejme naprosty nesmysl. Technicky to jde, ale zisk cehokoli je nulovy.

:-)) Joo, swapovat do RAMky, tomu rikam napad roku

Existuju programy, ktore sa pod windows ani nespustia (!) ak nemate definovany swap. Bez ohladu na to, kolko mate operacnej pamate (v mojom pripade xw8400 s 16GB RAM). Nemam chut diskutovat na temu preco je to tak, a ze je to blbost. Ja som len uzivatel, a chcem aby mi program vyuzil vsetku pamat, co mam, a podla moznosti co najmenej pouzival disk. A jeden zo sposobov ako to urobit a zaroven prakticky zrusit swap je presmerowat swap na virtualny disk. A na dalsi ram-disk mam presmerovane pracovne subory. Tymito dvoma pomerne jednoduchymi konfiguracnymi trikmi som dosiahol 2-nasobne zrychlenie narocnych simulacnych vypoctov.

A teraz skuste k tomu napisat tentokrat nieco inteligentne, najlepsie daky vas originalny napad...

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

A neni lepsi nez instalace zmenit rucne nastaveni v registru?

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.

Pro uložení kryptograficky citlivých dat používá TrueCrypt neswapovatelnou paměť (proto jak na Windows, tak pod Linuxem potřebuje práva roota). Co se týče možnosti odswapování rozšifrovaných souborů vizte výše odkazovaný TrueCrypt Third-Party Project TCTEMP.

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.

TEMP=$HOME/tmp ???

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..

Tmpfs má oproti ramdisku výhodu v tom, že se mu nastaví maximální velikost, kterou nepřekročí. Pokud ji ale nepotřebuje, tak paměť uvolní a umožní její použití pro něco užitečného. Pokud použijete ramdisk, tak zabere těch 256 MiB ať už v něm něco je nebo ne.

Jo, teď mě ale napadla ještě jedna podstatná věc – tmpfs umožňuje svůj obsah odswapovat. Ramdisk odswapování nepovoluje. Takže k tomuto účelu asi opravdu bude vhodnější ten ramdisk.

Takže dokoupit paměť + tmpfs + vypnout swap :)

Šifrovat swap! Proč ho vypínat, když jde šifrovat?

Proc ho sifrovat, kdyz jej nepotrebuju? ;-)

Kdyz nemas swap a programy ti zacnou zabirat vic a vic pameti, tak az dojde fyzicka pamet, tak system zacne hrozne thrashovat a zacne byt nepouzitelny. Kdyz mas swap, tak se nejdriv zacnou odswapovavat mene dulezita data a narust pomalosti je pozvolnejsi.

Jasne, ale stejne osobne ve vetsine pripadu swap nepotrebuji, takze ho explicitne zapinam az pri hratkach s qemu, ci podobnymi aplikacemi a v tom pripade vesmes stejne neuspavam/nehibernuji, takze _me_ osobne prijde praktictejsi swap vypnout, nez sifrovat.

Ostatne ja nemam ani sifrovany home (jsem malo paranoidni), takze v teto diskusi stejne nemam co delat :-)

Když ho nepotřebujete, a tedy nepoužíváte, proč ta formulace "vypnout swap"? Dle ní jsem usoudil, že swap používáte, a kvůli bezpečnosti šifrování jej chcete vypnout, což je zbytečné, jelikož swap lze šifrovat také.

Pokud swap nepoužíváte vůbec, pak bych očekával formulaci "nezapínat swap", "nechat swap vypnutý" nebo něco podobného. To by dávalo smysl. To, co jste uvedl, smysl nedává - jak chcete vypnout vypnutý swap?

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.

Co použít tmpfs a mít tak /tmp jen v paměti?

Uznávám, není to dokonalé, protože ta paměť pak po uvolnění může být přidělena libovolnému programu, ale po tvrdém resetu tam ty data zaručeně nejsou a pokud máte spuštěn nějaký zlovolný program, který bude čmuchat v prázdné paměti, tak tohle asi nebude váš největší bezpečnostní problém.

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

Nejsem hardwareář, ale řekl bych, že na běžných PC s SDRAM pamětí těch pět minut rozhodně potřeba nebude a tvrdý reset bohatě stačí. Pokud o tom někdo ví něco přesnějšího, rád se nechám poučit.

Pokud vim, u PC se pouzivaji dynamicke RAMky, ktere musi radic pameti neustale cyklicky obnovovat (refresh), jinak v nich data vydrzi par milisekund. Jelikoz pri vyplem PC (i pri tom radoby vypnuti se sviticimi LEDkami) radic pameti nejede, rozhodne bych se nebal, ze v RAM neco zustane. Pri RESETu nevim, tam bych to tak kategoricky netvrdil.

To je teoria. Prax su radovo sekundy az desiatky sekund (v pripade silneho podchladenia aj minuty). Toto presne testovali vedci v UK (neviem teraz kde som dal link). Skusali ako dlho trva nez data 'vyprchaju' z ram modulov bezne pouzivanych v pc a bookoch. Pri dostatocnom podchladeni mali dostatok casu prelozit ram z jedneho systemu do druheho bez straty obsahu (dost blbe ked mate OS v suspend to ram stave a kluce k disku v pamati).

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?

Whirlpool je kryptograficky z mého pohledu nejkvalitnější. Ostatní dvě nabízené funkce (RIPEMD-160 a SHA-1) jsou klony třídy MD, která ztratila kredit kvůli snadnému nacházení kolizí. V Truecryptu se hashovaci funkce používají jako jednosměrné funkce pro tvorbu klíče z passwordu. Tady narušení jejich vlastnosti bezkoliznosti není zatím nijak použitelné, protože ta funkce je složitá. Takže je můžete používat, jen to nebude vypadat moc in.

Zcela mimo ještě uvádím perličku, autentizační protokol APOP (Authenticated Post Office Protocol). Člověk si myslí, že nalézání kolizí v následujícím protokolu nemůže nijak pomoci k útoku na password. Omyl, omyl, celý password lze odhalit pomocí kolizí...

Protokol:
Klient (pozaduje na serveru svoje e-maily)
Server mu posila vyzvu (vyzva ma urcita omezeni, ale nemnoho) C
Klient vraci hodnotu MD5(C || password)
Server zkontroluje hodnotu odpovedi, protoze zna klientuv password. Je-li ok, pošle mu maily.

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.

Ten útok je opravdu MITM jak píšete, jen ho provádí jakoby server (útočník). Uživatel je ten, kdo se snaží server přesvědčit o tom, že je oprávněný, proto možná není nastaveno pravidlo třikrát a dost. Server se prostě ptá uživatele stále, pokud to uživatel típne, tak se k poště nedostane. Pokud to netípne, tak se server stále ptá na odpovědi na svoje výzvy. Po určité době se už neptá, odvodí si password. Není to všem server, ale útočník, který se jako server tváří.
Víte nějaké podrobnosti, jak je to na straně klienta s nastavením - kolik dotazů mu může server poslat, aby se na něj vykašlal?

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?

Na odhaleni jednoho znaku jakehokoliv passwordu je potreba v prumeru (za maximalne nepriznivych okolnosti) cca 255 vyzev. Obvykle to bude pouze cca 32. Pri utoku se pocita s periodickym automatickym prihlasovanim klienta. Utocnik uprostred dela hloupy server a stale klienta autentizuje. Voli si svoje vyzvy C a uci se z hodnot MD5(C || heslo).

Dobry den,
neni v pripade MitM utoku problem s prolomenim bezpredmetny? Mam za to, ze v pripade neuspechu APOP (-ERR Unknown command: APOP) E-mailovy klient automaticky zkouset nesifrovane USER/PASS; resp. APOP vubec nepouzije, pokud nenarazi v uvitani od serveru na timestamp, uvedeny mezi <>. Oboji muze falesny prostrednik sam zaridit. Jina situace by samozrejme nastala pri odposlechu periodicke kontroly E-mailu ve schrance.

Jinak by bylo treba pokazde nove spojeni, protoze se pro MD5 pouzije zmineny timestamp z uvitani POP3 serveru vcetne <> a shared secret.

RFC1939 uvadi jako priklad <1896.697170952@dbc.mtview.ca.us>tanstaaf s MD5 c4c9334bac560ecc979e58001b3e22fb.

Otazkou je, zda by podobny utok sel pouzit na CRAM-MD5 nebo novejsi variantu Digest-MD5.

To uvitani od serveru <..cokoli..> je prave ona challenge C, o ktere se bavime (pro nezainteresovane ctenare - chapu, ze to tak nevypada, kdyz se to jmenuje timestamp). Pokud klient neodpovi MD5(C || password), tak by nemel od serveru postu dostat.

Kdyz se utocnik postavi do role serveru a nepouzije v uvitani vyzvu <....>, co se stane? Posle mu e-mailovy klient svuj password? Jestli ano, tak je tenhle utok opravdu bezpredmetny.

Alespon v Thunderbirdu 2.0, ktery momentalne vyuzivam to tak vypada - kdyz neni vyzadovana uzivatelem zabezpecena autentizace, tak na serveru, ktery challenge (timestamp) poslal, zkousel rovnou APOP a kdyz ne, zkousel primo USER/PASS, coz by melo byt standardni chovani (vyplyva to z RFC, kde se primo pise "A POP3 server which implements the APOP command will include a timestamp in its banner greeting a The POP3 client makes note of this timestamp, and then issues the APOP command). Nevylucuji ale, ze v nekterych klientech je mozno APOP zvolit separatne. Nemam overenu tu variantu, kdy by v hlavicce od serveru challenge byla a APOP by selhal, muzu vyzkouset nasimulovat vhodnym programkem, tvaricim se jako POP3 server. Na druhou stranu utocnikovi staci pozmenit uvitani, aby challenge (timestamp) neobsahovalo. Oproti tomu pri zvolene zabezpecene autentizaci pri selhani AUTH *-MD5 a AUTH NTLM Thunderbird vyhlasi, ze se nemuze zabezpecene na server pripojit a nepokracuje.

Diky. Zda se, ze kryptoanalyza je tady nadbytecna. Staci si rici primo o heslo narovinu.

No pri selhani APOP v bezpecne variante (kdyz jsem to ted zkousel ladit pres netcat) to alespon vyhlasi chybu, ze server nepodporuje bezpecnou autentizaci. Ale neobjevil jsem zadnou Ameriku, jiz je to popsano tady, jak jsem prave zjistil:

http://www.securityfocus.com/archive/1/464584/30/0/threaded

A number of POP3 servers support APOP, but most of them require some
special configuration. And it seems like Mozilla attempts to use APOP if
APOP banner is present in server reply and no secure protocol is
configured. So yes, it's used, but mostly as an alternative to
cleartext. Based on last 115000 sessions statistics for ISP's mail
server with CRAM-MD5, APOP and NTLM support, ~7000 mailboxes:

Cleartext: 96,3%
APOP: 2,1%
CRAM-MD5: 1%
NTLM: 0.6%

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:)

Proc se stale neprodava HW reseni - napriklad radic disku, nebo rovnou disk, ktery si sifruje data sam (ted nemyslim zamek ATA rozhrani, ktery lze obejit jinou elektronikou nebo ctenim disku primo)? K diskum by clovek dostal 2 tokeny, po power-on by ho musel pripojit, aby disk nabehl, bez tokenu by nefungoval, data by na plotnach byla sifrovana. Odpadly by problemy s OS apod.

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

Nějaké takové disky se myslím dělají. Celkem nedávno jsem myslím něco četl na cdr.cz o discích Seagate. A šifrovací mezikus pro ATA disky už jsem taky (na obrázku ;-)) viděl.

Osobně mám ale raději softwarová řešení. Dají se tomu zkontrolovat zdrojáky, dají se tomu nainstalovat bezpečnostní záplaty a modernizovat používané technologie. A co když vám např. ten ATA mezikus shoří? Máte po datech. Musíte tedy stejně zálohovat a zálohy nějak šifrovat.

A speciálně se mi líbí software, který umožňuje vygenerování klíče jen z hesla. Je to sice o něco méně bezpečné než keyfile nebo hardwarové řešení (nikdo ale neříká, že se nemůže použít kombinace obojího), ale vím, že heslo, co mám v hlavě, a onen zašifrovaný soubor je všechno co potřebuju, když chci data zpátky. (Tedy pokud vím, jak přesně to bylo zašifrováno, tzn. ideálně mám původní program se zdrojáky. Při znalosti algoritmu ale není nezbytný.) Hardware se dá ztratit, může se rozbít apod. a navíc krom výrobce často nikdo neví, jak přesně data šifruje/dešifruje.

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í.

Když by útočník obsah keyfiles neznal, tak to pochopitelně je velmi silné - keyfiles se stávají (náhodným) klíčem místo passwordu: Na uvedeném linku je možné zjistit to, co jste zjistil vy. A tedy keyfiles se zpracují do 64 bajtů (to je onen zlomek vteřiny navíc), které znamenají náhodnou masku. Maska se pak naxoruje na password, eventuelně doplněný do 64 bajtů nulami. Jakýkoliv i slabý password se tak stane velmi silným (prakticky) náhodným klíčem o 512 bitech.

Účelem toho cvičení s keyfiles je tedy ze slabého passwordu udělat silný tím, že se k passwordu ještě xoruje ona Maska. Soubory keyfiles se proto musí utajit, jinak útočník Masku vypočte jen jednou a pak je to pro něj pouhá konstanta do luštícího programu, kterou nemusí počítat pro každý nově zkoušený password.

O něco lepší by bylo o tyto soubory (zpracovává se z nich jen 1 MByte) rozšířit sůl. Nebo vypočítat klíč z passwordu a soli tradičně bez keyfiles a poté skutečný_klíč = hash(klíč, keyfiles). V tomto případě musí útočník pro každý nový password načíst a zhašovat celý soubor keyfiles znovu. A to je podstatný rozdíl v náročnosti luštění.

Je to miniaturní připomínka. Účelem keyfiles je zřejmě pouze umožnit externí vstup passwordu (jakožto náhodného binárního souboru) z nějakého média (z USB, ze sítě,...) a zabránit keyloggerům odchytit password. Jediné, co bych TrueCryptu mohl vytknout je, že by měl nějak výrazněji a jednodušeji užiateli napovědět, k čemu jsou keyfiles dobré (nebo ho donutit číst manuál).

Pokud jsou keyfiles uloženy na hard disku, pak mají menší smysl (to je ale u domácích PC právě běžné). Většinou to bude adresář nebo jeden soubor. Útočník tak může zkoušet všechny do úvahy připadající praktické možnosti kombinací souborů.

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)

První zásadní nedostatek je, že k tomu nemá zdrojáky nikdo kromě Microsoftu (tedy pochybuju, že by u tohoto udělali výjimku a zdrojáky dali k dispozici; pokud ano, tak se omlouvám a zbytek příspěvku ignorujte). Dělat tak o tomto systému jakékoli závěry je trošku problematické. I pokud jsou pravdivé všechny veřejné informace o použitých algoritmech apod., tak i bezpečný algoritmus jako AES se dá implementovat nebezpečně atd.

Pan Růžička Vám skvěle odpověděl. Výjimečnost Truecryptu je v tom, že zdrojáky jsou k dispozici a objemem jsou zanedbatelné vzhledem ke zdrojákům u Microsoftu. Lze to tedy mít ještě pod kontrolou. Je veřejnou informací, že jsem se podílel na náhradě Microsoft CryptoAPI za jine Krypto API pro NBÚ. Při této práci jsme v týmu objevili řadu pozoruhodných kryptografických vlastností. Například, když zadáte nějaký parametr šifry, systém vám ho potvrdí, ale uvnitř si nastaví něco jiného. Nejsem příliš paranoidní a nehledám v tom činnost tajných služeb, ale chyby při programování složitých systémů. Proto zcela souhlasím s panem Růžičkou. O takovém systému, který není prozkoumán širším týmem odborníků, nelze dělat jakékoliv závěry.

Je to škoda. Ano, je, protože šifrování ve Windows by mohlo zajišťovat soukromí a my bychom tomu mohli věřit. Než to ale nastane, narostou nám asi dost dlouhé fousy.

Článek ohledně certifikátů a šifrování NTFS zatím nechystám. Určitě je to věc, která by mě bavila, podobně jako CryptoAPI, ale zatím jsem se k tomu nedostal.

Hashovací funkci můžete změnit. Dejte si "Volume tools" - "Header Key Derivation Algorithm" a tam si místo PKCS-5 PRF zadejte HMAC-Whirlpool. Přešifruje se pouze hlavička volume, nikoli data.

Děkuji autorům za vynikající článek, který mě jako pravidelného uživatele TrueCryptu svými závěry velmi potěšil.

Teď mě ještě tak napadlo, bylo by možné zde uvést kontrolní součet, respektive lépe GPG podpis toho archivu se zdrojovými texty, na kterých probíhala analýza? (OpenPGP klíče s otisky C331 F8FE 5FAE 491E 209D D2AA 6358 D2EC B1B9 B8B0 a 9486 BED4 3212 04B3 4D87 E4FA 776E 4443 571C 5C02 patří Vám?)

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.

To jako chcete ten obsah paměti ukládat někam do krypty?

V článku byla jediná výtka, která se týkala keyfiles. V odpovědi ve vláknu keyfiles jsem zhodnocení keyfiles už naznačil (Joe, dík za založení vlákna a správnou poznámku, a tím nakopnutí).

Oč jde, je to, že keyfiles by měly primárně sloužit jako (náhodný) password a být utajené (nebo útočníkovi nedostupné - na síti, na USB, prostě externí zdroj). Pokud nejsou utajené, jejich význam je malý - zde je pak na místě slovo "legrační" (a mohl by být jednoduše zvýšen opatřením, které jsem zmínil v odpovědi ve vláknu keyfiles). Dokumentace k TrueCrypt by měla utajování keyfiles pouze zdůraznit a takto jednoduše popsat jejich smysl.

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.

Dobrý... Samozřejmě to lze, ale teď vážně. Tomu, kdo si nezapamatuje heslo, bych nedoporučil, aby svůj film zašifroval něčím, co může taky zapomenout. (Byly to hnědý Láďovy kalhoty ? nebo Frantova zelená čepice ? na výletu do Krkonoš ? nebo Evina modrá šála na výletě v Tatrách?)

Zkušený uživatel skutečně MůŽE takto nahradit kvalitní heslo.

Je to ale bizardní postup a do masově rozšířeného bezpečnostního programu bych to nedával kvůli blbuvzdornosti. Jako možnost vstupu utajeného klíče z externího vstupu bych to pochopitelně nechal (to je výhodné), ale s podtržením významnu v názvu třeba "extern secret keyfiles" a se striktním varováním před použitím otevřených dat (pod čarou možnost využití otevřených dat pro mimořádně zkušené uživatele, ale jen zcela výjimečně).

Shodneme se takto?

Jinak bych skoro založil nové vlákno na to, jak nějakému kameramanovi, co si prostě nic nepamatuje (kromě ovládání TrueCryptu ....) vtloukl do hlavy něco, co si bude pamatovat. Protože názory na to by mě zajímaly (přejdeme-li to, že v té větě je rozpor, a soustředíme-li se na podstatu).

Omlouvám se za prznění češtiny. Mohu ho používat, dokonce ho i používám, ale mnohem méně než password. Vzniklo to tak, abych odlišil heslo jako přihlašovací heslo a heslo jako heslovou posloupnost u proudových šifer. Je to moje lenost, u tohoto článku by kolize nehrozila.

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.

Nemůžu přijít na to, jak zašifrovat adresář se soubory. Vždy to chce vytvořit virtuální disk a do něj můžu ty data překopírovat/přesunout. To já ale nechci, chci jen ten adresář zašifrovat tam, kde je. Jde to vůbec? Prosím info na mail.
Díky.

Díky za info. To ale ten program docela dost degraduje. Jde tedy jinak zašifrovat Program Files, aby do toho nikdo nemohl zasahovat a aby přitom wokna běžely? To samé se týká adresáře Dokumenty.
Díky g.

Díky za info. Jak říkám, je to škoda, velmi bych tu možnost šifrování adresářů uvítal ... a myslím, že ne jenom já.
Na to přesměrování zmíněných adresářů jsem tedy nepřišel, tj. nenašel řešení .. :-(

Ano, vím že toto vlákno je už dost staré, ale na "čerstvější" zabývající se tímto tématem jsem nenarazil.
Díky g.

Dobrý den a díky. O přesměrování Office vím, tam se to dá nastavit, spíše mi šlo o celou složku Dokumenty, protože tam jsou různá data aplikací, některá nastavení a i pošta a pod..
Zkusím kontaktovat někoho, kdo těm "woknům" přeci jen rozumí víc, než já.
Díky g.

Wokna umí na NTFS vytvořit linky mezi adresáři a "přesměrovat" tak adresář jinam, dokonce lze takto do adresáře připojit celý disk jako na UX systémech, akorát se to moc neví protože v systému na to chybí klikátko, utilitka co umí tyhle linky vytvářet se jmenuje Junction (http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx)
K šifrování adresářů "Documents and Settings" a "Program Files" s tím že wokna poběží - nepoběží, dal by se takhle šifrovat konkrétní profil, ale je to pakárna. Pokud je to jen trochu možné tak je ideální zašifrovat komplet systémový disk (TC od verze 5) -> wokna nic netuší a je ošetřené všechno včetně swapu.

Moc to totiž nechápu. Když nejdou šifrovat kompletní adresáře, tak jsem si řekl, že tedy zkusím zašifrovat kompletní disk, aby se při bootování muselo provést vložení hesla. Jenže OUVEJ .... mám disk rozdělen na dva oddíly, na jednom XIN XP a na druhém Linux. A najednou po aplikování TrueCrypt se mi při bootu neotevře nabídka volby systému, ale ihned startujou wokna. Takže se teď k Linuxu vůbec nedostanu. K čemu to tedy je?
g.