Názory k článku Proč a jak na šifrování disků v Linuxu?
-
Josef (neregistrovaný)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. -
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. -
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ší. -
Rejpal (neregistrovaný)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. -
Lumpy (neregistrovaný)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= -
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.
-
VlK (neregistrovaný)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. -
anonymníno treba TrueCrypt pro widle to zrovna dela za chodu, precte nesifrovanej blok, blok na disku prepise x-krat nahodnyma cislama, blok zasifruje a napise na stejny misto
pro dm-crypt je podobna metoda tady, ale bez prepisovani disku nahodnyma cislama:
http://www.saout.de/tikiwiki/tiki-index.php?page=EncryptExistingDevice
ale ja bych to taky takhle nedelal... -
amores peros (neregistrovaný)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 :) -
someone (neregistrovaný)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.
-
someone (neregistrovaný)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í. -
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.
-
Ho (neregistrovaný)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! ;-) -
Ho (neregistrovaný)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.
-
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 :). -
Ondra "Satai" NekolaZlatý podporovatelJak je na tom dm-crypt/LUKS s podporou více (procesorových) jader? -
someone (neregistrovaný)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.
-
dan (neregistrovaný)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?;)
-
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 -
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íč? -
Ondra "Satai" NekolaZlatý podporovatelBezpecnost 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. -
Ondra "Satai" NekolaZlatý podporovatelVtipna 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. -
anonymníS tím Německem máte osobní zkušenost, nebo jste to jen někde slyšel? Nedovedu si představit, jak mi celník (nota bene v Schengenu) kontroluje počítač [leda v USA]. Vozím sebou palma i do zemí mnohem divočejší než německo, ale nikdy nikoho nezajímalo, jestli tam náhodou není šifrovaná sd karta :)
Co se týče té povinnosti vydat klíč v Anglii (pokud ji tam opravdu mají), je to zcela zjevně v rozporu s evropskou úmluvou o lidských právech (co podle ní soudí ve Štrasburku), takže jakmile to tam na někoho použijí a on podá žalobu do Štrasburku tak na 99,9% vyhraje a Anglie mu bude muset ještě platit odškodné. -
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š. ;-)
-
Sten (neregistrovaný)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í.
-
anonymníPostup implementace sifrovaciho algoritmu rijndael (AES) byva zpravidla detailne dokumentovan od NSA (National Security Agency), ktera se tvorbou podobnych algoritmu zabyva a vede jiz radu let aktivni vyzkum mohutne financovany vladou USA.
Twofish implementovala napriklad americka IBM a source codes uvolnila pro public usage jiz nejmene pred dvemi dekadami
Bezpecnost neni relativni vuci sile / znalostem / zkusenostem utocnika. Pri navrhu bezpecnostni politiky je zasadou pocitat s tim, ze utocnik vi vsechno co vy. Bezpecnost je ekvivaletni nejslabsimu clanku retezce. Tim muze byt i pripojeni k internetu bez korektne konfigurovane DMZ (demilitarizovane zony) nebo za firewallem, majicim leaky. -
anonymníUplne souhlasim. Rychlost twofish nezavisi na delce klice, AES jo. Ja zvolil delku klice 256b a vychazi mi na obou domacich pocitacich twofish v assembleru rychlejsi nez AES v assembleru. A to jeden procesor je amd64 a druhej pentium-m. A ostatni sifry bez assembleru jsou o dost pomalejsi.
Takze zrejme tabulka rychlosti v clanku je pro kratsi klic, ne?
ČLÁNKY DO MAILU