Názory k článku
Proč a jak na šifrování disků v Linuxu?

Zrovna se LUKSem zabývám, takže článek mi přišel akorát vhod. Těším se na další pokračování! Zajímalo by mě šifrování nejenom diskových partition, ale taký virtuálních disků v souboru. Doufám, že to autor v dalších pokračováních zmíní. Také srovnání s jinými podobnými nástroji (např. s TrueCrtypem) by bylo jistě zajímavé. Každopádně díky za seriál.

Jsem rád, že vám článek přišel vhod. "Virtuální disky v souboru" probírat budu, a to ve třetím díle. Srovnání s jinými podobnými nástroji jsem se bohužel nevěnoval (článek/seriál jsem zaměřil výhradně na dm-crypt/LUKS), nicméně podrobné srovnání jednotlivých nástrojů naleznete na Wikipédii.

Truecrypt vs LUKS. Z hlediska bezpečnosti bych řekl, že jsou na tom velmi podobně (u LUKS je to podmíněno volbou vhodného algoritmu a šifrovacího módu, Truecrypt dělá řadu rozhodnutí za uživatele).

LUKS je na tom podle mého lépe ve správě klíčů, nabízí až 8 možných klíčů pro šifrovanou jednotku. Truecrypt zase nabízí oproti LUKS skryté jednotky (hidden volumes) a na rozdíl od LUKS šifruje i hlavičku, takže oddíl šifrovaný Truecryptem by neměl být (snadno) identifikovatelný. Pro uživatele, kteří vyžadují plausible deniability je Truecrypt tedy vhodnější.

Truecrypt ztrácí v mých očích především v tom, že vznikl a je primárně vyvíjen pro Windows, takže linuxová verze bývá občas pozadu. V tuto chvíli již sice linuxová verze má k dispozici grafické rozhraní (a je soběstačná - nevyžaduje kompilaci jaderného modulu), ale třeba skryté jednotky (hidden volumes) v aktuální verzi podporovány (k mému překvapení) nejsou.

Skryté jednotky TrueCrypt v Linuxu a Mac OS X podporuje (tedy umí s nimi pracovat), ale neumí je vytvářet. Je to tím, co jsi psal – Linuxová verze je pozadu. Ale v plánu je tuto funkci přidat.

diky za pekny clanok - este by ma zaujimalo ci sa da menit velkost souborov, ktore sa pripajaju ako virt.disky...

Ne. Jenoduše ne. Respektive, nějak ručně by se vám to podařit mohlo, ale moc bych si s tím nehrál, abyste nepřišel o data.

Teoreticky, pro zmenšení kontejneru byste musel neprve změnit velikost souborového systému na dané šifrované jednotce. Pak byste musel odhadnout, kde přesně (v daném kontejneru) končí souborový systém a spočítat, o kolik můžete soubor oříznout (pozor na LUKS hlavičku). Pak byste soubor ořízl a doufal, že se k datům ještě někdy dostanete.

Zvětšení by bylo o něco jednodušší, soubor byste zvětšil o nějaká (pseudo)náhodná data a poté provedl zvětšení souborového systému.

Ale ani jedno jsem nikdy nedělal a o žádných automatizovaných nástrojích, které by to prováděly, nevím.

Přestože? Dodnes neumějí programy pořádně využít více jader, takže jestli tu zkratku chápu dobře, každé jádro má 1,65GHz a pokud se využije jen jedno, rychlost bude pochopitelně nižší než s laciným Sempronem.

1.65 GHz jádro Core2 (mobilní, starší Merom) je podle mých zkušeností o 50-60 % rychlejší, než 1.8 GHz Sempron K8. Nejrychlejší současný Sempron má asi 2,3 GHz. Zajímalo by mě, za jakých okolností by i ten nejnovější Sempron mohl být rychlejší. :-)

Rychlejší v čem? Já se zmínil o čistě jednovláknové úloze, kterou tato je. Celý systém nebo paralelně běžící aplikace budou na uvedeném Core 2 rychlejší. Šlo mi o příklad, že je to prostě jednovláknová záležitost. Navíc Vaše srovnání s Core2 má háček v tom, že má 2 rychlejší jádra, kdežto uživatel s Quad má 4, tedy o něco pomaleji taktovaná a je znevýhodněn.
Sempron byl trochu nadsazený příklad, v praxi jsem ho s Intelem nepoměřoval na žádné takové jednovláknové úloze, ale rozhodně Intel nebude jádrokrát rychlejší.

Rychlejší v jednojádrové rekompilaci dvou lispovských kompilátorů (SBCL a OpenMCL, v případě SBCL pokles zhruba z dvanácti minut na sedm po přechodu z 1.8 GHz Sempronu 64 na 1.66 GHz Core 2 Duo), jejich build proces nelze paralelizovat, naštěstí netrvá moc dlouho. (Jiné velké věci nemám potřebu na vlastním stroji rekompilovat, případně je posílám do buildovací farmy.)

Nechápu, jak může být 1,66 GHz jádro Core 2 Quad "taktováno o něco pomaleji", než 1,66 GHz jádro mého Core 2 Duo notebooku, leda že by tu jednotku mezi vydáními těch procesorů nějak reformovali. BTW stejně je to bezpředmětné, 1.66 GHz měl údajně Q6400, Q6600 má mít 2,4 GHz.

není nutné čekat stačí google, navíc docela záleží na verzi jádra, na jaderných modulech a na distribuci
http://www.google.com/search?aq=f&hl=cs&q=%C5%A1ifrov%C3%A1n%C3%AD+s+luks+mandriva+2008&btnG=Hledat&lr=

a doufám, že bude dostatečně podrobný (=pro blbce :-) )Nejlépe jak převést celý existující systém na šifrovaný - místa na disku dost, jen se nechce znovu vše nastavovat.

+1
Tiez by som rad videl navod pre blbov :-). LUKS som si sice skusil pri instalacii celeho distra, ale moznost nainstalovat to na existujuci system ma tiez zaujima.

Doufám, že návod dostatečně podrobný je. Samozřejmě, pokud nebudete čemukoliv rozumět, zeptejte se a já rád dovysvětlím.

U převodu existujícího systému na šifrovaný bohužel o žádné snadné cestě nevím. Nějaký konvertor by mohl existovat pro jednotky šifrované dm-cryptem, ale ne pro LUKS (LUKS hlavička o něco šifrovanou jednotku zmenšuje). A i kdyby existoval, bylo by jeho použití velmi nebezpečné (výpadek proudu či SW chyba a konec). Nehledě na to, že pouhé zašifrování existujících dat by otevřelo dveře možnému útoku na médium (obnova předchozí vrstvy záznamu z pevného disku možná je), takže by bylo vhodné data určená k šifrování bezpečně vymazat.

A co dělat v případě externích disků? Třeba záložního USB? To taky nejde převést? Takže: odložit data zašifrovat, nahrát zpět a zadat heslo při každém připojení?

Skoda, že neexistuje:-(
Jinak argumenty proč neexistuji nechápu, spíš nechci chápat :-)
Pokud se logický obsah disku šifruje, hlavička není problém, nikdy nemám disk úplně plný.
Problém s výpadkem proudu? Ty risknu vzhledem k tomu, že mám UPS. SW chyba? Záloha, risknu.
útok na medium? tak paranoidní nejsem:-) většina dat důvěrných se mění a tedy po jistém čase jsou v bezpečí. Nebo by útok na medium odhalil i klíč?

Neexistují proto, že je nikdo nenapsal a že to není až tak jednoduché. Ta hlavička je problém spíše vzhledem k souborovému systému - bude třeba jej o tu hlavičku zmenšit (a při zašifrování data posunout za hlavičku).

Řekl bych, že konverze teoreticky možná je. Jen jsem to nikdy nezkoušel a nevím o žádných nástrojích, které by tento úkol zautomatizovaly.

Útok na médium neodhalí klíč, ale pokud bude úspěšný, útočník se může jednak dostat k původním datům a jednak získá informace, které může použít ke kryptoanalýze. Jak velké riziko to v praxi představuje nejsem schpen odhadnout - nejsem kryptoanalytik.

Zálohy souborů nemusí být jenom v /tmp. Mám zašifrovaný loop s hesly atd., a když nějaký soubor otevřu ve vimu, tak se mi hodí jeho záloha do ~/.vim/backup. Na to je potřeba myslet a nějak mazat (skriptem, třeba).

smazany soubor lze obnovit pokud se opravdu nepromaze nejakymi datami, takze spis bych to videl na zmenu konfigurace vimu nez na mazani skriptem, ale jinak dobra poznamka.

Ve skriptu můžete mazat shredem.

Což na žurnálovacích filesystémech nemusí být bezpečné (viz manuálová stránka programu shred). Osobně doporučuji šifrovat všechny filesystémy, kde se chráněná data mohou objevit.

mam cryptsetup-luks a opravdu _NEDOPORUCUJI_ reseni, kdy si udelate jeden velky encrypted device a pak do nej LVM!!! pri normalni praci je to OK, ale pri kopirovani vetsich souboru je to peklo, je to pomale a load vyskoci obcas i na 5!

predtim jsem mel x logical volumes a v nich encrypted device a bylo vse OK.

nedavno jsem si rikal, ze idealni by bylo /boot nesifrovany a do initrd vlozit nejaky kontrolni kod - fingerprint kernelu a ramdisku - vytisknout jej pri boot a cekat na potvrzeni uzivatelem jestli to sedi (idealni by byl ten slovni fingerprint jako u ssh klicu). v pripade shody pokracovat dale bootovanim :)

no nerebootuji moc casto, ale po 2 tydnech rebootu mi fakt vysla passphrase na 6 pokus :) uz jsem zacal mit strach o sve data :)

zajimala by mne informace
o skutecne bezpecnosti LUKS
napr. kdyz mi policie cr odveze pc
dostanou se k datum?
pripadne jakymi volbami
a nastavenim zvysit bezpecnosti

dekuji

Nedostanou se k datum kdyz neuhodnou heslo, proto treba v Anglii uz sifrovani dat zakazali a US government s nim zacina mit problemy take. Prvni co je potreba pro bezpecnost udelat je obetovat vsechen proprietarni (uzavreny) software, protoze ten casto obsahuje jako bonus i nejaky malicous software (malware). Bezpecnost zvysit uzivanim anonymizacnich toolu jako je tor. Na webu se samozrejme slusi mit i privoxy, javascript disabled, cookies disabled, referer logging disabled, java / flash disabled. Enabled pouze pro specificke a duveryhodne servery. Je take vhodne pouzit system-wide socks5 ssl proxy server ci ssh tunel pres ktery bude proudit vsechen sifrovany traffic dovnitr i ven vcetne sifrovanych DNS queries. Zaroven doporucuji uzivat IPSEC vsude kde to jde, ssmtp + spop3 nebo imap over SSL, ftp over SSL, zadny skype + poridit si za par stovek ethernet adapter s HW packet offloading a HW IPSEC encrypt / decrypt supportem. V neposledni rade je potreba mit na pozoru updaty a zabezpecit potencialne zranitelne daemony, jako napr. sshd, cups, smbd, sendmail. Na zaver dukladny hardening serveru / workstationu a penetracni test pro ziskani certifikatu ci overeni konfigurace.

V Anglii sifrovani nezakazali, jen dali povinnost na pozadani policii vyklopit hesla (jinak automaticky na 2-5 let do basy). Takze je nutne pouzit dalsi vrstvu (steganografie, hidden volume, atd ...)

Ano, spravne Bilbo. Sifrovani bez uposlechnuti prikazu cerneho policisty znejiciho "Gimme dat f***in' password ya son o' da biatch !" zakazali jak uvadim vyse a na letistich se kontroluje uz i operacni system v laptopu, pry je to prevence proti terorru a jeho ztvarneni - terrorismu. Lzi budou tvrdit zamerne az do doby nez se cast obyvatelstva vzbouri proti vlade a misto demonstraci zacne s necim tvrdsim. Tato cast zacne byt oficialne povazovana za terroristy, kteri nyni zatim jeste minimalne v CR neexistuji.

Ta kontrola laptopů mi přijde směšná. Na to, aby to mělo smysl, by ji musel provádět skutečný odborník, což nepředpokládám, že je (a bude) prováděno. Druhá věc je, že AFAIK neexistuje kompletní legislativní a procedurální rámec pro provádění těchto kontrol - tj. co kontrolor smí, co nesmí, kdo a jak kontroluje jeho, jak bude postižen v případě zneužití pravomoci, smí-li si podezřelá data zkopírovat, kam se ta data budou ukládat, kdo k nim bude mít přístup, jak a kým budou analyzována, jak budou likvidována, kdo nese odpovědnost, apod.

No a třetí věc, data se dají ukládat na vzdálené servery (pro zákonodárce očividně překvapení). Takže mi stačí zašifrovaná data zkopírovat na nějaký server, vyčistit laptop, přenést laptop přes hranice, připojit se na Net a data stáhnout zpět. Účel těchto kontrol? Není mi jasný. Kromě dalšího zásahu do soukromí.

Pokud je mi známo, v Anglii nezakázali šifrování jako takové, pouze učinili člověka povinným poskytnout dešifrovací klíče na požádání pod nějakým trestem. Takže sice šifrovat můžete, ale když heslo odmítnete sdělit nebo jej prostě zapomenete, půjdete si sednout.

myslim ze to neni pravda, ak ho zabudens a oni nedokazu ze ho vies tak sa nic nedeje, ale ked ti ten napriklad HDD vratia a ty ho budes pouzivat tj. pouzijes heslo co si nechcel prezradit tak je zle.

Ono je nepříjemné už to, že tenhle zákon platí retrospektivně, tj. policie v UK může chtít po někom podle daného zákona šifrovací klíče, i když mu třeba odebrali harddisk dávno před tím, než zákon vešel v platnost.

Jinak doufám, že máte pravdu, i když, jak si čtu text toho zákona, mám dojem spíše opačný. Neměl byste náhodou odkaz na nějaký případ z praxe, kdy by se někdo podobně hájil a soud ho v UK osvobodil? Ono vždycky platí, že zákon je jedna věc a jeho výklad soudcem je věc jiná (pro člověka však rozhodující).

V zásadě, ten zákon se mi zdá postavený takto - pokud vám prokážou, že jste klíč k šifrovaným datům někdy v minulosti měl, má se za to, že jej máte stále, pokud _vy_ nedokážete, že ho skutečně nemáte (a zkuste _dokázat_, že jste něco skutečně zapomněl a už si nevzpomínáte). Takže podle mého je to skutečně tak, že když zapomenete, půjdete si sednout.

... jak krasny priklad demokracie :-) takovy ten priklad z demokraticke ustavy: - pravo na soukromi, ktere muze byt omezeno zakonem, nejste obzalovan, ale rovnou poslan do basy :)

Nemam pravnicke vzdelani, ale u nas tusim obzalovany nemusi vypovidat, pokud by si tim pritizil, pripadne muze lhat. Dalo by se to vztahnout i na neposkytnuti heslo k sifrovanemu disku? Pokud dalo, ma sanci u nas takovy zakon projit? Neni v Anglii tenhle zakon v rozporu s jinym, pripadne jejich ustavou?

Obecne mam dojem, ze ty protiterosticke zakony nevznikaji na teroristy, ale jako skulinka bezvladi pro policejni a vojenske slozky. A terorismem se to jen zastituje.

Nechci rejpat, ale mám pocit, že slavné Spojené království je stále v podstatě absolutistickou monarchií, viz. http://cs.wikipedia.org/wiki/Spojené_království#Vl.C3.A1da_a_politick.C3.BD_syst.C3.A9m
Ať žije Orwell! ;-)

RE: "Obecne mam dojem, ze ty protiterosticke zakony nevznikaji na teroristy, ale jako skulinka bezvladi pro policejni a vojenske slozky. A terorismem se to jen zastituje."

Samozrejme, ze mate pravdu. Protiteroristicka opatreni jsou ve skutecnosti pro pripad, ze vypukne valka o ropu, nebo se obcane vzbouri kvuli tomu, ze nebudou mit co jist kvuli cene jidla. Je prokazano, ze svetove ceny potravin rostou spolu s cenou ropy, uz dnes jsou problemy v chudsich statech, kde obcane nyni nemaji na ryzi. Ropni magnati chteji svou ropu doprodat a prostredky jak to udelat na to maji. Kdo myslite ze bude brzy nejbohatsi clovek sveta?

CR patri mezi chude vychodni staty, uz ted nemame co jist, jelikoz si prectu slozeni a vidim, ze krome chemie, majici nejruznejsi vedlejsi ucinky v ceskych potravinach uz nic jineho neni. Ceska republika ma nejvyssi vyskyt rakoviny strev z cele Evropy, kazdy treti Cech ji drive ci pozdeji dostane a to kvuli nekvalitni strave, ze se o tom nemluvi? Zeptejte se ceske vlady, ktera se vse snazi maskovat za obecny pojem "rakovina" a pokousi se vinu svadet na kuraky, z jejichz financi se pokousi hradit nejlacinejsi moznou "lecbu", ktera v drtive vetsine pripadu konci neuspesne - umrtim. Zatimco kuraci rakovinu dostavaji pouze velice ojedinele, ve 3% ze vsech pripadu. Ceske limity skodlivych latek v potravinach jsou nekym zaplacene a hluboce pod limity v porovnani s Nemeckem ci libovolnym vyspelejsim statem.

CR mezi vyspele staty nepatri. Kdyz mluvime o libovolnem vyspelejsim state, myslime tim vyspelejsi stat nez CR.

Masny odpad ktery okolni staty mivaly ve zvyku likvidovat v kafileriich se v CR jiz nekolik let objednava a nechava dovazet. Prave z nej Cesti vyrobci ve velkem (vice nez 53% masa co tu je) vyrabeji to, co se tady prodava s ceduli "Ceska Kvalita", aby to alespon naivni senylove verici v dobro kupovali.

Cedule v Kauflandu s napisem Ceska kvalita znamenaji ve skutecnosti "toto je masny odpad se syntetickym ochucovacem, syntetickym barvivem a syntetickou soli. Dokud vam to neprinese umrti na rakovinu strev, nechte si chutnat !"... Nenabizi se zamerne temer zadne zahranicni alternativy kvalitnich potravin, protoze prave ti Cesti vyrobci, kteri masny odpad prodavaji si stezuji, ze maji maly odbyt zbozi kvuli tomu, ze lide kupuji jine zbozi (splnujici opravdove limity Evropske Unie). CR ma jeste nejmene do roku 2015 ujednano, ze si vse bude delat po svem a to napriklad plati o mnozstvi importovaneho zbozi. Nejradeji by ceska vklada zakazala dovazet cokoli a tvrdila by, ze mame nejen ceskou kvalitu, ale rovnou svetovou kvalitu a ze omezuje dovoz ze zahranici pro nase dobro.

Dominantni cesky automobilovy prumysl velmi brzo doplati na zvysujici se cenu ropy -> bude prakticky nulovy zajem o nove vozy a jejich soucasna cena klesa kazdy den.

jak je to s probuzenim z disku nebo ram??

nedavno jsem zkousel sifrovat /home, ale po probuzeni se me dana partysna nepripojila
v pripade probuzeni z disku se to aspon zeptalo na heslo, ale nepozastavilo nabihani relace, ktera tim padem pak spadla

Obecně jsou dvě varianty: buďto při uspávání necháte šifrovaný svazek připojený a ten se pak připojí i při probouzení. Tam je ale problém v tom, že klíče zůstávají nechráněné v paměti/disku a po probuzení máte disk připojený.

Můžete ale také použít nějaké udělátko, které vám při usínání disk odpojí. To se ale dost špatně dělá u systémového disku (nebo home, který se aktuálně využívá). Musel byste mít citlivá data někde bokem nebo se ještě před uspáním odhlásit.

A to je presne duvod proc nekolik let na NB nehibernuji. Kdyz uz mi konecne s2ram zacalo fungovat tak NEEXISTUJE reseni jak provest zapomenuti klice v pameti a pri odhibernovani opet pozadat o klic, ktery se ulozi zpet do pameti a transakce nad diskem se rozjedou (tedy nad partition). System odpojovani pri hibernate a pripojeni po probuzeni je z uvedenych duvodu nanic. Tohle je proste 'by design' a vylozene me to sere :).

Mit root na samostatne nesifrovane partition, home na sifrovane partition a tu pred hibernovanim odmountovat.

jasne a zavrit vsechny terminaly, ktery maji otevrenej adresar homu, zavrit firefox (protoze ma otevreny .firefox/XYZ), apod.? zkus si to... fakt to neni tak jednoduchy :).

to uz ten komp muzete rovnou vypnout a hibernaci nepotrebujete, kdyz se ma odpojit home :)

Nejjednodušší řešení pro hibernaci je zašifrovat celý disk i swap (např. v LVM v jednom LUKS oddílu, takže je jeden klíč a jedno heslo). Uspání do RAM je nebezpečné z hlediska cold boot útoku.

Chtel bych touto cestou podekovat za velmi zdareny clanek, ktery polopaticky vysvetluje zakladni principy a postupy sifrovani.

Preji hodne uspechu pri psani dalsich nemene zajimavych clanku.
Jeste jednou mnohokrate diky.

Děkuji moc za pochvalu.

Jak je na tom dm-crypt/LUKS s podporou více (procesorových) jader?

Bohužel nemám sestavu s více jádry/procesory, abych to otestoval. Ale, pokud tomu správně rozumím, pak šifrování/dešifrování provádí jediný proces (resp. jeden proces na každou šifrovanou jednotku). Takže z více jader můžete těžit maximálně v situaci, kdy máte více šifrovaných jednotek.

Zaklad paralell computingu je v tomto pripade rozdelit task na mensi bloky dat. Core #1 muze pote operovat jen s urcitou casti, zbytek totiz provede core #2. Teoreticky neomezeny pocet chunku lze paralelne decryptovat ve stejny cas, v praxi by se take hodilo aby Intel quadcore nebyly 2 slepene dual core sdilejici stejnou cache.

Presne toto chovani jsem videl i ja.. takze pokud mate 4 disky v raid5 schopne prenosu (4-1)*90M/s tak pri zapnuti sifrovani klesa rychlost z tech 270 na 30M/s kvuli single-thread sifrovani. Doufam ze nekdo udela vicejadrovy dm-crypt, protoze kazdy blok lze samozrejm sifrovat na jinem procesoru :) a tech 4x30 = 120M/s na quadcore by bylo fajn. Taktez na 8-way SMP by byla rychlost lepsi.. pripadne by to chtelo hw akceleraci, treba pres PCIE kartu (co tak obetovat nejakou phys-x nebo gpgpu na tento ucel?;)

A nebo na šifrování použít procesor VIA C3 nebo lépe C7 s HW podporou AES ;-) Mám domácí server s C7 1,5GHz na něm disky zašifrované AES dm-cryptem a když z něj tahám přes FTP 70MB/s (skutečně cca 550Mbps), tak dm-crypt vytěžuje CPU na 25% (a proftpd si bere dalších cca 15%).

Ano zruba tak se to da rict.

Paralelni sifrovani (crypt vlakna per procesor) se menilo v ruznych jadrech, nebudu popisovat duvody pro se to zmenilo, ale momentalne:

- kernel 2.6.24 dm-crypt a vys pouziva pro jedno sifrovane zarizeni 2 vlakna, jedno slouzi pro sifrovani, jedno pro io operace.

- kernel 2.6.25 pridava podporu asynchronniho crypto rezimu. az nekdo napise driver pro hw, ktery umi paralelne sifrovat, pouzije se automaticky (kolik pozadavku hw prijme paralelne, tolik se mu posle requestu). ale zatim takovy driver zadny neni...

jinak podpora hw funguje i normalne - VIA Padlock a AMD Geode jsou v kernelu podporovany, takze pokud jsou nahrany spravne moduly, dm-crypt je pres kernel CryptoAPI pouzije.

Obecne (s temito jadry) plati, ze je dm-crypt optimalizovany pro provoz podobny sifrovani na notebooku (tj. zatezuje hlavne jeden core na procesoru. neco musime nechat pro to prehravani mp3, ze :)

Na viceprocesorovem serveru (a s RAID zvysujicim propustnost disku navic) vykon neni optimalni, to je znamy problem, a casem se urcite vyresi - bud primo dlasimi vlakny v dm-cryptu nebo paralelnim zpracovanim v crypto vrstve. (rad bych, aby to bylo nekjak konfigurovatelne - tj. napriklad kolik vlaken se pro sifrovani pouzije nebo tak nejak)

p.s.
diky za hezky clanek

Děkuji za pochvalu i za doplnění.

Dobrý den,
omlouvám se, ale v této problematice se zatím moc nevyznám, ač se milerád přiučím. Aktuálně mám zašifrovaný /home. Udělal jsem to jednoduše při instalaci openSUSE 10.3 pomocí nástroje na rozdělení disku. Asi nic převratného. Mám sice zaheslovaný BIOS a vstup do GRUBu (nabídka je během bootu skrytá), ale pořád mi není jasné, jak moc je to bezpečné s ohledem na nešifrovaný /boot. Po přečtení tohoto nesmírně zajímavého článku (Děkuji!) jsem trochu znejistěl, neb jsem si uvědomil, že ani nevím, jakým algoritmem to SUSE šifruje. Hrůza.
Možná se to objeví v budoucím díle seriálu, ale rád bych se zeptal, jak je na tom z hlediska bezpečnosti a vůbec použitelnosti výchozí šifrování distribucí. Je to nějak kloudně funkční metoda i pro neodborníka?
A jak je to s tím /tmp? A swap? A co jsou ty jiné vrstvy, když musí člověk odevzdat šifrovací klíč?

Bezpecnost je vec relativni vuci sile utocnika. Jak to popisujete, tak se k vasim datum nejspise drtiva vetsina utocniku (manzelka, milenka 1, milenka 2, nahodny zlodej notebooku a pracovni konkurence - pokud nedelate ve stavebnictvi) nedostane. Pokud mate strach z GRU, tak bych doporucil spise navstevu prislusneho lekare, sifrovat vse a /boot nosit s sebou ;)
A budiz vam utechou, ze se k vasim datum pripadny utocnik spis nedostane celnim utokem, ale oklikou. Trebas vam upravi klavesnici (mimochodem, jiste nemate bezdratovou, ze ne?).

/tmp a swap lze sifrovat jednorazovymi klicy generovanymi pri bootu, pokud si pamatuji, tak jak v *buntu i OpenSuse stacilo instalatoru zadat pro prislusny oddil prazdne heslo.

To víte, je to zlá nemoc, ale neznamená, že po mě nejdou. :-D Jde o notebook. A krom ochrany dat je to i prevence před tím, aby ho případný zloděj vůbec mohl použít. To je taková skoro škodolibost. :) Hlavně mě zajímalo jak jsou ty distribuční nástroje kvalitní.

Vtipna alternativa k tomu, co popisujete je naopak nechat moznost snadneho bootu do oskliveyho slidiveho rezimu, kde notebook pravidelne napr. posila svou IP a fotografie z webkamery ;)

Sifrovani biosu nema moc dobrou povest ohledne bezpecnosti, ale nikdy jsem nesel po podrobnostech. GRUB... je fain, ale kdokoli stejne muze vyjmout disk, dat zapojit ho do USB portu, zrusit oddily a prepsat MBR...
Jinymi slovy, s tim, co udelate nejspis musi zlodej zajit za "kamosem, co tomu rozumi" a nepujde rovnou do zastavarny dve ulice vpravo od Jedove chyse ;)

Aktuálně mám zašifrovaný /home. Udělal jsem to jednoduše při instalaci openSUSE 10.3 pomocí nástroje na rozdělení disku. Asi nic převratného. Mám sice zaheslovaný BIOS a vstup do GRUBu (nabídka je během bootu skrytá), ale pořád mi není jasné, jak moc je to bezpečné s ohledem na nešifrovaný /boot. Po přečtení tohoto nesmírně zajímavého článku (Děkuji!) jsem trochu znejistěl, neb jsem si uvědomil, že ani nevím, jakým algoritmem to SUSE šifruje. Hrůza.

Pokud SUSE používá LUKS, můžete si nechat vypsat příslušné informace (šifra, šifrovací mód) z LUKS hlavičky:

cryptsetup luksDump /dev/zarizeni

Co se bezpečnosti týče, je třeba zvážit, před kým (a před čím) vlastně chcete data chránit. Pokud nepředpokládáte, že útočník bude expert na Linux a kryptoanalýzu, úplně stačí šifrovaný /home a swap. Pokud předpokládáte, že je útočník schopný linuxář a má opakovaný přístup k vašemu PC, zašifrujte kořenový souborový systém, umístěte /boot na flashdisk a noste ho při sobě.

Možná se to objeví v budoucím díle seriálu, ale rád bych se zeptal, jak je na tom z hlediska bezpečnosti a vůbec použitelnosti výchozí šifrování distribucí. Je to nějak kloudně funkční metoda i pro neodborníka?

Záleží na tom, co výchozí šifrování dané distribuce používá - dm-crypt, LUKS či něco jiného - a hlavně, jaké je výchozí nastavení takového řešení (popřípadě jaké jsou možnosti nastavení). Bohužel, tímhle jsem se v seriálu opravdu nezabýval. Nemohu tedy doporučit nic jiného než někde zjistit, jak to ve vaší distribuci vlastně je.

A jak je to s tím /tmp? A swap? A co jsou ty jiné vrstvy, když musí člověk odevzdat šifrovací klíč?

Pokud používáte tmpfs pro /tmp, nemusíte si dělat starosti, pokud máte na /tmp vyhrazen nějaký oddíl, je vhodné ho zašifrovat. Šifrovat swap určitě vhodné je, neboť se v něm mohou objevit data, se kterými pracujete, a to v nešifrované podobě. Jak na to, tomu se budu věnovat v příštím díle.

Ehm... k těm jiným vrstvám... teď nevím, co jste tím myslel. A za poslední, nutnost odevzdat šifrovací klíče platí v Anglii, v ČR pokud vím nikoliv.

U nás ta povinnost zatím skutečně není, ale třeba do Německa vás se zašifrovaným diskem nemusí pustit. Takže se to blíží. S těmi vrstvami jsem myslel toto: v diskuzi někdo zmiňoval, jak lze chránit data, když musíte v Anglii odevzdat klíč: šifrovat data, nějaké procesy,... Teď jsem to nebyl schopen najít... Pardón...
$ cryptsetup luksDump /dev/sda3
LUKS header information for /dev/sda3
Version: 1
Cipher name: aes
Cipher mode: cbc-essiv:sha256
Hash spec: sha1
Takže je to asi v pořádku. O tmpfs jsem neslyšel (Stydím se;), ale až budu upgradovat, podívám se na to.

Nastavení jsou v pořádku, snad jen šifrovací mód by na tom mohl být lépe. Mód cbc-essiv je do jisté míry zranitelný, pokud má útočník k dispozici opakovaný přístup k zašifrovaným datům (a může s nimi manipulovat).

Tmpfs je souborový systém určený pro /tmp, charakteristický tím, že data se ukládají do RAM (nebo SWAPu, pokud RAM dojde). Tmpfs můžete použít velmi snadno, stačí do /etc/fstab přidat odpovídající řádku.

ale to neznamena, ze ho pustia z basy. sud pre ludske prava nie je odvolaci sud.
v strasburgu sa da vysudit maximalne tak odskodne za porusenie luskych prav, nic ine.

S tím Německem to před nedávným časem proběhlo médii. Třeba na letištích mimo Schengen si to umím představit celkem snadno. Krom toho, když jsem na konci ledna jel do Německa, kontrolovali nás celkem podrobně...

anglani nepodpisali europsky dohovor o ludskych pravach.

Ještě doplním odkaz na příslušné stránky SUSE:
http://en.opensuse.org/Encrypted_Filesystems
http://en.opensuse.org/Encrypted_Root_File_System

Jak nad tím tak přemýšlím, tak mě napadá, jaké adresáře mohu šifrovat jako samostatné oddíly. Asi nejde mít jen /boot a zbytek / zašifrovaný. Nemýlím-li se, tak /root také nesmí být šifrován. Nebo ano? A co /bin a /sbin? Je na to nějaké univerzální řešení na rozdělení celého jednoho disku? Aby potom těch diskových oddílů nebylo přespříliš. ;-)

Jak nad tím tak přemýšlím, tak mě napadá, jaké adresáře mohu šifrovat jako samostatné oddíly.

Můžete šifrovat všechno kromě /boot.

Asi nejde mít jen /boot a zbytek / zašifrovaný.

Jde. Něco k tomu si řekneme ve třetím dílu.

Už se nemůžu dočkat. :-) Jestli budou ostatní díly také tak skvělé bude to úchvatné. :-)

Co jsme s lidma blbli a pomoci dvou 1.44 MB disketovych jednotek jsme vytvorili hot-swap RAID1 sifrovane disketove pole. :-)

Rijndael (AES) je oproti Twofish rychlejší s krátkým klíčem (128 bitů), ale pomalejší se středně dlouhým klíčem (192 bitů) a dlouhým klíčem (256 bitů). Viz Srovnání rychlostí finalistů AES. Rozdíl v rychlosti mezi těmito dvěma šiframi je však minimální.

ano v teorii je to pravda, ale nakonec stejne zalezi na implementaci. vsadim se, ze kdybych implementoval twofishe ja, byl by pomalejsi nez cokoliv jineho ;-)

Ta tabulka je evidentně dělaná s defaultní délkou klíče, což je 128 bitů. Ale my paranoici máme rádi to nejdelší: cryptsetup luksFormat -s 256 -c twofish-cbc-essiv:sha256 -h sha512 /dev/sda

Má někdo jednoduchý návod jak udělat komprimovaný oddíl / swap ?

chcel by som sa opytat, aky je rozdiel medi LUKS a TrueCrypt?

mam to chapat tak, ze su to len rozdielne nastroje k dosiahnutiu rovnakeho ciela, alebo su tu nejake zasadnejsie rozdiely?

v oblasti kryptografie sa nepohybujem, takze sa mozno pytam blbo. :)