Dotaz: Zašifrování /home v Ubuntu - zkušenosti?

[Míra]

Zdravím,
V Ubuntu je při instalaci možné nastavit, aby se domovský adresář šifroval.
Nejsem v tom žádnej odborník, tak bych se chtěl zeptat těch zkušenějších, jaký na to mají názor.
Jak je toto šifrování silné? (má to vůbec smysl ?)
Co když dojde k poruše disku nebo souborového systému?
Jaký souborový systém je na šifrovaný adresář nejvhodnější?
Je lepší používat TrueCrypt?
Jaké jsou s tím zkušenosti?
atd...

Odpovědi

[Fluttershy, yay!]

Na to bych byl býval rád odpověděl, ostatně jsem to krátce i používal, ale Ubuntu jsem před časem opustil z důvodů jak praktických (distro-specifické regrese v kernelu), tak politických (od spyware Unity po jejich sprostotu kolem Miru)... a doporučuju totéž.

Co když dojde k poruše disku nebo souborového systému?

Zálohy?

[waldo pepper]

a kdo se Tě na to ptal? Borec chtěl poradit a Ty si tu plácáš játro

[Fluttershy, yay!]

A co užitečného přináší tvůj komentář?

Mimochodem se to jmenuje diskuse... tak diskutuju.

[Josef Kufner]

Na Debianu mám celý disk (/ + swap, ne jen /home) zašifrovaný už od instalátoru pomocí dm-crypt, LUKS a 256bit AES. Jen /boot mám na samostatné partition, aby bylo dokud natáhnout jádro.

Je to plně integrované v jádře i userspace (mount, initscripty) a naprosto bezproblémové na provoz.

[Míra]

...a jaký má dm-crypt vliv na rychlost? V Ubuntu je zašifrování /home poznat, že je to pomalejší...

[Jendа]

Na i3-2350M (Sandy Bridge) mi to čte ze šifrovaného stejně rychle, jako z nešifrovaného - 70 MB/s (notebookový disk). Šifruješ /home tím udělátorem z grafické instalace (to je tuším FUSE, takže pomalé) nebo dm-cryptem? Jak to měříš?

[Josef Kufner]

# hdparm  -t /dev/mapper/root 

/dev/mapper/root:
 Timing buffered disk reads: 128 MB in  3.00 seconds =  42.65 MB/sec

# hdparm  -t /dev/sda

/dev/sda:
 Timing buffered disk reads: 382 MB in  3.00 seconds = 127.13 MB/sec

# smartctl /dev/sda -a
=== START OF INFORMATION SECTION ===
Model Family:     SandForce Driven SSDs
Device Model:     KINGSTON SH103S3240G
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 1.5 Gb/s)

# cat /proc/cpuinfo
model name      : Intel(R) Core(TM)2 Duo CPU     T7250  @ 2.00GHz

# uname -a
Linux 3.11-trunk-686-pae #1 SMP Debian 3.11-1~exp1 (2013-09-12) i686 GNU/Linux

Jas kontrolky pevného disku odpovídal poměru naměřených rychlostí. Takže asi tak.

[little.owl]

Zkousel nekdo realny vliv AES-NI na dm-crypt u SSD?

Kdyz Intel poskytoval patch pro kernel, mluvili az 50% redukci casu u dm-crypt (zde), tedy treba u aes-ctr-plain64. Na plotnovem HDD jsem tak velky rozdil nepozoroval, i kdyz tam je bottleneck jinde.

[tuxmartin]

Jen /boot mám na samostatné partition, aby bylo dokud natáhnout jádro.

Tady je velka slabina, utocnik muze upravit initrd na nesifrovanem oddilu a hned zna heslo...

Jedina moznost by asi byla nosit si /boot na flash disku.

[Josef Kufner]

Aby takový útok mohl být úspěšný, musel by mi ukradený notebook vrátit. To není příliš pravděpodobný scénář. Navíc pokud by k tomu došlo, obnovím /boot ze zálohy ještě před jeho použitím (ano, mám denní automatickou zálohu). Taktéž se to dá řešit pomocí TPM a podobných hraček, ale kdo ví, jak moc jsou důvěryhodné.

[tuxmartin]

Nikdy nenechavas vypnuty notebook 10 minut bez dozoru? Prehrat initrd, ktery ma kolem 20MB je velice rychle.

Ja jsem v ramci testovani ukladal v takto upravenem initrd zachytnute heslo na konec souboru s configem jadra (/boot/config-3.5.0-42-generic). Treba u Ubuntu, kde ma config 6,5 tisice radku si jednoho navic nikdo nema sanci vsimnout.
Pak uz staci nechat uzivatel zapnout notebook a nechat pracovat. Jakmile ho zase opusti staci si precist heslo, smazat ho a vratitm puvodni initrd.

Pouzivas neco na sledovani zmen v souborech/adresarich? Treba tripwire, nebo incrond? Jina rozumna ochrane me nenapada.

Urcite je pohodlnejsi, minimalne u stolniho PC pouzit hardwarovy keylogger.

[Jendа]

Nikdy nenechavas vypnuty notebook 10 minut bez dozoru?

Ne.

Můj notebook nebyl vypnutý už hodně dlouho (uspávám do paměti - takže útočník si pomůže spíš s coldbootem, ale na to se taky přijde). Hash /boot mám poznačený.

Prehrat initrd, ktery ma kolem 20MB je velice rychle.

Musíš fyzicky vymontovat disk, což zrovna u mého notebooku je pěkný oser (bootování z externího média i změnu parametrů jádra na init=/bin/sh mám samozřejmě chráněné heslem). A když už to máš úplně celé rozebrané, můžeš tam připojit keylogger :).

Ja jsem v ramci testovani ukladal v takto upravenem initrd zachytnute heslo na konec souboru s configem jadra (/boot/config-3.5.0-42-generic).

Nejlepší je si tam rovnou dát backdoor, který ti otevře po síti shell.

Pouzivas neco na sledovani zmen v souborech/adresarich? Treba tripwire, nebo incrond? Jina rozumna ochrane me nenapada.

Ne, pokud mě někdo napadne, může tohle zrušit nebo tam nejlépe dát rovnou backdoor jaderný.

[Pavel]

Taky premejslim, ze si zasifruju oddily v LVM.. ale porad nevim, kde mam uchovavat klice? Je to server, ktery neni v moji blizkosti, takze kdyz klice budou treba na usb, je mi to prd platny, protoze kdyz mi nekdo server ukradne, pujde to i s klicema. jak tohle resite?

[Josef Kufner]

K tomuhle se dá využít TPM nebo různé šifrovací tokeny (klíč je uložen pouze v tokenu a nelze ho přečíst, šifrování provádí sám token, takže klíč ho nikdy neopustí). Je potřeba ale zajistit, že při otevření skříně serveru dojde k likvidaci klíčů. Pochybuju ale, že bude existovat nějaké snadno použitelné a hotové řešení.

[Šangala]

Nebo spustit ssh server z initrd a odemknout to vzdáleně, nebo tam poslat babičku, aby zasunula flashku a až to pípne ji vytáhla a dal zpátky do ledničky.

[Jendа]

Není problém odemykat přes SSH - mít dropbear (malý SSH server) v ramdisku, přes který heslo zadáš.

Samozřejmě to není odolné proti útoku, kdy ti někdo vypne stroj a vymění initramdisk. To si musíš pořešit nějak jinak.

[alfonz mucha]

mám zašifrovaný právě zmiňovaný domovský adresář. Jako všechny ostatní způsoby, část je potom pomalejší. Na druhou stranu na SSD se to sice také projevuje, ale subjektivně to není znatelné.

Alternativní instalátor umožňuje i zašifrování celého disku.

[Jendа]

Jak je toto šifrování silné? (má to vůbec smysl ?)

Bál bych se, že data budou leakovat do /tmp, swapu a dalších adresářů. Doporučil bych zašifrovat celý systém (vše kromě /boot). To je snadno při instalaci z Alternate CD.

Jo a taky jestli se tam furt používá encfs, tak je vidět adresářová struktura i na zašifrovaném disku. Další důvod, proč šifrovat celé blokové zařízení.

Je lepší používat TrueCrypt?

Použil bych normální jaderný dm-crypt.

[rADOn]

Kdyby náhodou nebyl /tmp na ramdisku, co tak tragického může leaknout? Ditto swap – při dnešních velikostech ram by měl být většinu času prázdný (můj rozhodně je) a když náhodou nebude, jaká je šance že tam útočník najde něco užitečného?

Šifrovat celý FS je určitě bezpečnější, ale jestli po tobě jde NSA tak ti to stejně nepomůže A pro většinu ostatních účelů je to overkill.

[filbar]

Proč overkill, co když ti ntb ukradnou? Pak se do něj bez hesla nikdo nedostane.

[Love_Dali]

Když mi notebook ukradnou, tak zformátujou celý disk a nainstalujou tam něco na čisto. Nikoho nezajímá co, kde jaký běžný uživatel má na disku. Pokud tam mám něco důležitého, tak si změním loginy. Což udělám stejně tak i když mám šifrovaný disk. Pokud nejsem vyloženě podnikatel, co tam má doopravdy důležitá data, tak je podle mě šifrování zbytečnost, co akorát zpomaluje chod systému. Pokud mám na disku doopravdy něco důležitého, tak řeším zabezpečení spíše hw cestou a až potom dejme tomu nějaké šifrování, ne?

[Šangala]

Už jsem pár hezkých fotek viděl a to nešlo ani o krádež :)

[Josef Kufner]

Nějaké loginy jsou naprosto nezajímavá věc. Jakmile připojíš disk k jinému počítači, ani je nepotkáš.

Ukládáš si hesla v prohlížeči nebo poštovním klientu? Máš elektronické bankovnictví? Máš tam kalendář, ve kterém je napsáno, kdy nikdo není doma? Hm?

[Jendа]

Myslím, že třeba českou policii dm-crypt zastaví, ale HW bariéry pro ni neexistují.

tak řeším zabezpečení spíše hw cestou

Jak?

[rADOn]

tak řeším zabezpečení spíše hw cestou

Jak?

Já mám třeba v pracovním notesu od Dellu šifrování přímo ve firmwaru disku. Dokud nepošleš nějakým speciálním ATA příkazem heslo ke klíči, tak z disku nic nedostaneš, ani když ho strčíš do jiný mašiny. A ne, není to stupidní heslo ulozený v biosu , i když bys disk rozšrouboval a přečetl přímo plotny tak by mělo být opravdu zašifrovaný. Ne žé bych t ozkoušel, ale spíš podezřívám že ve firmwaru je víc než jedno heslo ke klíči Jestli ho má výrobce a NSA tak jsem v klidu. Pro moje účely stačí že běžný poberta to nezlomí a já se nemusím matlat se šifrováním (je to normální ATA zařízení).

[Jendа]

Nevěřím.

[rADOn]

Co s tim ma spolecnyho nejakej taiwanskej vyrobce flashdisku?

[Jendа]

Inspirace, že ne vždy je HW šifrování opravdové šifrování (kde vyrobili tvůj disk?).

Schovat do disku rozumnou implementaci AES, která dá třeba 200 MB/s, IMHO asi nebude úplně fun.

Prostě tomu nevěřím. V HW (a proprietárních šifrovacích systémech obecně) bylo už podobných průserů příliš.

[rADOn]

Však jsem taky psal že tomu klíči nevěřím Ale s daty od Snowdena nepracuju a proti běžným pobertům je to dostačující.

BTW trochu jsem se na to informoval: AES se tam nepoužívá (muselo by to být v ECB módu což nějak postrádá smysl), je tam nějaká jednoduchá symetrická bloková šifra realizovaná v hw. Když je nastavené heslo, tak se s ním zašifruje klíč. Když heslo není, tak je klíč uložený otevřeně, ale bloky na disku jsou pořád šifrované. Takže ano, když bys mi ukradl notes ještě předtím než nastavím poprvé heslo, rozdělal disk, přečetl klíč, zašrouboval a vrátil aniž bych si toho všimnul, tak mi žadný další heslo nepomůže. Myslím že to risknu

IMO je skutečný zakopaný pes v tom že klíč má být sice pro každý kus unikátní, ale nikde není psáno že není odvoditelný. Stačilo by něco jako MD5( serial_num + _nsakey), takže plány na ovládnutí světa mám uložený jinde Důležitý je že dokud si kluci z NSA dají bacha na hubu a nebudou to nikde šířit, tak to pro moje účely stačí.

[Jendа]

Spíš bych viděl problém v tom „jednoduchá symetrická bloková šifra realizovaná v hw“. Vyrobit kvalitní šifrovací algoritmus není nejjednodušší a viděli jsme třeba crypto1 z Mifare Classic, že.

[rADOn]

asi tak

[rADOn]

Proč overkill, co když ti ntb ukradnou? Pak se do něj bez hesla nikdo nedostane.

Vsak ja nemam nic proti sifrovani dulezitych veci. Reagoval jsem na to ze (nejen) Jenda radil sifrovani celyho fs, i kdyz to v danem pripade valne nicemu nepomuze a tazatel dokonce vyslovne psal ze mu staci /home.

[Šangala]

Nikdy nevíš komu se to dostane do ruky a co s tím bude dělat a je to, to nejsnazší co lze udělat (pokud se dané distro umí vypořádat s uspáním na disk, jinak si musíš sám-si-sám).
A takový disk můžeš kdykoliv v klidu reklamovat (pokud po tobě jde NSA, tak ho poleješ neředěnou kyselinou a přejedeš tankem).

[Petr]

A jaké distro či utilitka nebo volba umí zapomenout heslo k zašifrovanému /home? OpenSUSE se mi po hibernaci probudí a disk je stále přístupný i bez opětovného zadání hesla.

[Jendа]

Jendian.

[Šangala]

To je právě krávovina .
Ale pokud zašifruješ celý disk včetně swapu, tak uspání na disk proběhne do swapu a po probuzení je třeba swap „dešifrovat“ aby bylo možné přečíst obraz - není místa, kde by se heslo uchovalo (což je správně) a nevím, které distro to má by-default nastaveno tak, aby to fungovalo správně. Nicméně pokud je šifrovaný disk a až na něm třeba LVM ze swapem, tak je to snad jednoduché nastavit (možná ani ten problém není - nevím, ale dřív jsem ho měl a musel si to upravit), horší je když je třeba swap šifrovaný zvlášť náhodným heslem.

[Josef Kufner]

Na Debianu to instalátor udělal tak, že vyrobil zašifrovaný disk, tam dal LVM a v něm vyrobil / a swap. Takže připrobouzení z disku naběhne jádro, initrd a zeptá se to na heslo k disku. Odemkne, zjistí, že systém byl uspán a začne probouzet. Vše je tedy šifrováno jedním heslem a uspání na disk je stejně bezpečné jako úplně vypnutý systém.

[Šangala]

Na Debianu jedu a v minulosti jsem to musel dořešit(, ale je pravdou že instalátor nepoužívám na dělení disku snad v žádné distribuci, bo nevím co to dělá :) ), pokud to je tedy přes instalátor out-of-box, tak padá jakýkoliv zádrhel.

[Josef Kufner]

Možnost zapomenout hesla k zašifrovaným diskům při uspání do paměti jsem už někde viděl. Ale tuším, že to byl jen feature request a nějaká diskuse k němu. A matně si vybavuju, že tam bylo i zmíněno šifrování obsahu paměti při uspání, ale kdo ví, co to bylo.

Nicméně LUKS umožňuje zamknout a odemknout přimountovaný disk, jen je potřeba se ujistit, že nebude potřeba z toho disku číst, v době, kdy je zamčený, neboť se to zasekne a pokud je zrovna potřeba načíst binárku potřebnou k odemčení...

[Jendа]

Možnost zapomenout hesla k zašifrovaným diskům při uspání do paměti jsem už někde viděl. Ale tuším, že to byl jen feature request a nějaká diskuse k němu.

luksSuspend funguje už dost dlouho (viz odkaz na Jendian)

A matně si vybavuju, že tam bylo i zmíněno šifrování obsahu paměti při uspání, ale kdo ví, co to bylo

Prostě bych to ukládal do dm-cryptového blockdevice.

Nicméně LUKS umožňuje zamknout a odemknout přimountovaný disk, jen je potřeba se ujistit, že nebude potřeba z toho disku číst, v době, kdy je zamčený, neboť se to zasekne a pokud je zrovna potřeba načíst binárku potřebnou k odemčení...

No tak se zasekne ten proces, co čte. Binárka pro odemčení samozřejmě musí být jinde. Mrkva to řešil.

[marbu]

U Fedory to jde nastavit přímo v instalátoru: vytvoříš luks oddíl a na něm lvm, kde je všechno mimo /boot. Příklad:

$ lsblk --output NAME,TYPE,MOUNTPOINT
NAME                                          TYPE  MOUNTPOINT
sda                                           disk  
├─sda1                                        part  /boot
└─sda2                                        part  
  └─luks-2584ca8e-635c-49a7-b559-445d0667ff63 crypt 
    ├─vg_dione_crypt-lv_root                  lvm   /
    ├─vg_dione_crypt-lv_swap                  lvm   [SWAP]
    └─vg_dione_crypt-lv_home                  lvm   /home

Při probuzení je vše potřebné v initramfs v /boot, takže jsi normálně dotázán na heslo.

Zádrhel je akorát v tom, že co letos přepsali instalátor, ne úplně snadno se to v něm nastavuje. A to ne proto, že by to nešlo nebo že by bylo třeba nějak složitě to konfigurovat, ale protože není vůbec zřejmé co to klikátko nakonec udělá - musel jsem si to víckrát zkusit.

[Šangala]

…ne úplně snadno se to v něm nastavuje… …- musel jsem si to víckrát zkusit.

No právě, například u CentOS v textové instalaci nenastavíš skoro nic, u Bubuntu na to hledím jak čáp do trubky, takže ty instalátory nepoužívám, a normálně si disk předem nachystám, jak potřebuji včetně LUKS, LVM a často i FS (přes PartedMagics), a možná tím jsem si v minulosti způsobil to, že to instalátor nezvládá.

[little.owl]

…ne úplně snadno se to v něm nastavuje… …- musel jsem si to víckrát zkusit.

A to bylo hodnoceni F19 nebo F20?

F20 je prvni verze nove Anacondy, kterou jsem zatim nedonutil pokusy spadnout, takze pomalu zacinam byt spokojen.

Cloveku po F18 staci malo.

[marbu]

Byla to hned ta F18. Anakondou z F19 jsem pouzil jen jednou a zdalo se mi to o neco lepsi, ale rekl bych, ze to bylo spis tim, ze jsem uz tento typ interface videl. Fedoru 20 jsem jeste nezkousel. Jeste bych doplnil ze to hodnoceni se vztahuje na tzv. 'custom layout', kdy uz mam dopredu jasnou predstavu jak chci disk rozdelit a ne pouzit default.

Ale na druhou stranu diky tomu prepsani by nemel byt velky problem to deleni disku predelat, feedbacku k tomu bylo docela dost.

[little.owl]

Tak to ano. Take pouzivam "Custom Layout" a u F18 a F19 jsem radsi vytvoril partitions v rescue modu rucne a pak doufal, ze layout prezije instalaci. U F20 to vypada uz lepe.

[Josef Kufner]

Například /var/lib je plné uživatelských dat od různých démonů. /etc obsahuje také mnoho zajímavých dat.

[Jendа]

Ditto swap – při dnešních velikostech ram by měl být většinu času prázdný (můj rozhodně je)

Mně to swapuje minimálně kousky Evince, OpenSCADu, Gnuradia a Xilinx ISE. Mám 8 GB RAM.

Kdyby náhodou nebyl /tmp na ramdisku, co tak tragického může leaknout?

Třeba Firefox když otvírá dokumenty, tak je tam stahuje. Totéž Thunderbird s přílohama. Nebo třeba historie terminálu.

Dále, v /usr/local mám patchnuté Gnuradio a OsmocomBB, v /opt Metasploit (ani nechci vědět, co si to tam všechno ukládá), ve /var/lib databázi, v /root sem tam něco a ve /var/log jsou věci jako kde jsem byl (SSID wifi sítí) a co jsem tam dělal.

[pedro]

Třeba Firefox když otvírá dokumenty, tak je tam stahuje.

Určitě? Teď jsem to zkoušel... Podle mě je ukládá na /home/ do cache.

/var/log jsou věci jako kde jsem byl (SSID wifi sítí) a co jsem tam dělal

Zálěží na tom, jak se připojuješ. I když budeš používat třeba NetworkManager, který skutečně loguje do /var/log, tak A) úroveň logování je nastavitelná, B) defaultně je myslím nastavená na warning, takže určitě se z toho logu nelze dozvědět, co a kde jsi dělal.

Pro někoho může mít šifrování / smysl, ale pro většinu uživatelů je to overkill.

[Jendа]

Určitě? Teď jsem to zkoušel... Podle mě je ukládá na /home/ do cache.

Kliknu na PDF odkaz, dám Open with Evince, otevře se Evince se souborem /tmp/název.pdf. Iceweasel 24.

Zálěží na tom, jak se připojuješ. I když budeš používat třeba NetworkManager, který skutečně loguje do /var/log, tak A) úroveň logování je nastavitelná, B) defaultně je myslím nastavená na warning, takže určitě se z toho logu nelze dozvědět, co a kde jsi dělal.

...a co jsem tam dělal. Namátkou mounty, připojená zařízení, a i vůbec informace, kdy byl počítač spuštěn.

[pedro]

Podle mého názoru je účelem šifrování pro soukromé účely chránit osobní data typu fotky z dovolené. Mounty, připojená zařízení, informace o spuštění atd. nejsou data soukromého charakteru a většinu lidí nezajímají.

Samozřejmě, že šifrování celého disku je bezpečnější. Na druhou stranu jestli o tom začnu uvažovat jako o trade-off výkon-bezpečnost, tak radši budu mít silně šifrovaný /home, než slabě šifrovaný /.

[Josef Kufner]

Pokud zašifruješ celý disk, nemusíš ho dělit (efektivnější využití kapacity), nemusíš se bát, že ti někde unikne něco citlivého (logy, /tmp, /var a mnoho různých drobností), a hlavně to je mnohem jednodušší na nastavení. Takže z pohledu uživatele je overkill to řešit a šifrovat jen kousek.

[pedro]

Naopak je to dost nepraktické.

1) Buď máme celou partition na / (to je nepraktické např. z hlediska instalace systému);

2) Nebo máme >=2 partitiony a >=2 hesla (to je nepraktické, musím si je pamatovat);

3) Nebo máme místo hesla např. keyfile (to je ještě nebezpečnější, stačí zjistit co a kde je keyfile, heslo by ze mně musel někdo vymlátit silou nebo použít sofistikované řešení typu keylogger).

Případně dej vědět, jak to řešíš, možná mi něco uniká.

Podle mě mají distra grafická udělátka při instalaci, která šifrování /home zajistí. Fakt je, že osobně to nepoužívám a dokonce i mountování /home si nastavuji ručně. Ale to je tím, že jsem paranoidní k bídně dokumentovaným nástrojům třetí strany a radši si to udělám ručně.

[Jendа]

1) Máš blbej instalátor/blbou distribuci :)

2) Můžeš mít stejné heslo do obou.

3) Na jedné šifrované partition může být keyfile ke druhé. Keyfile je někde, kde ho může číst pouze root. A když už má někdo roota, může číst i klíč z paměti nebo si soubory rovnou zkopírovat.

Já jsem chtěl mít keyfile pro / na oddílu, kde je /home a /home při suspendu odpojovat. Bohužel tato konfigurace keyfiles na Debianu vyžaduje přepsat cryptroot hook v initramdisku, což se mi nechtělo.

Distra (minimálně Debian) mají udělátka, která automaticky zařídí šifrování / (umí i třeba šifrované LVM na RAIDem na pár zmáčknutí kláves). A dokonce umí i nastavit ssh server v initramdisku, takže lze třeba server odemykat vzdáleně (což samozřejmě vyžaduje tamper-evident fyzickou bezpečnost).

[pedro]

Hmm, ta možnost (2) je jednak nejspíše kryptograficky blbost, jednak to stejně budu muset zadávat 2x. Možnost (3) nevím, co jsi tím chtěl říct - pokud má někdo přes nějaký backdoor přístup, tak se nemáme o čem bavit, pokud má root ve smyslu root heslo, tak to nic neznamená. V každým případě platí, co jsem napsal - heslo, které si pamatuji je pokud je silné mnohem bezpečnější, než keyfile, kde más problém s fyzickou bezpečností.

(1) bylo nejspíš myšleno, že mám prostě upgradovat, ne reinstalovat, to je ovšem otázka osobní volby a situace.

Samozřejmě, že distra umějí šifrovat /, umějí ale také šifrovat /home, takže argument výše o složitém nastavení je podle mě lichý.

[Jendа]

Hmm, ta možnost (2) je jednak nejspíše kryptograficky blbost

Proč? Heslo projde nějakým náhodným počtem iterací PBKDF2 (s trochou štěstí bude u každého oddílu různý a s trochou štěstí na PBKDF2 nefunguje hash extension attack :) a hlavně se solí.

jednak to stejně budu muset zadávat 2x

Jo, to je problém :-/.

Možnost (3) nevím, co jsi tím chtěl říct

No prostě když už chceš mít mermomocí dva oddíly, tak si zašifruješ heslem / a do /etc/crypttab dáš

lvm-data_crypt /dev/mapper/lvm-data /etc/data.key luks

Já bych to ale chtěl mít opačně (tj. klíč k / mít v /home) a to na Debianu rozumně nejde.

(1) bylo nejspíš myšleno, že mám prostě upgradovat, ne reinstalovat, to je ovšem otázka osobní volby a situace.

Ne, (1) bylo myšleno, že moje distribuce nemá problém s instalací, aniž by zničila data, které tam už jsou.

[pedro]

No, protože jsi si jinak odpověděl sám , tak jenom k variante keyfile na první šifrované partition, to není o moc bezpečnější než pouze šifrování jedné z nich, že?

Njn, člověk věří distribučním vývojářům tak dlouho, až se něco po..

[Jendа]

k variante keyfile na první šifrované partition, to není o moc bezpečnější než pouze šifrování jedné z nich, že?

Není, ale se dvěma hesly taky ne… Jediný útok bych tam viděl vyownování stroje.

Tu šaškárnu s /home jsem chtěl proto, že /home mám „bezpečnější“ - při některých příležitostech ho odpojuju.

[pedro]

Za předpokladu, že se použije stejná šifra a stejně silné heslo, tak vlastně ne. Takže je to v podstatě celé o tom, zda se člověk bojí o systém samotný, má nějká citlivá data mimo /home, nebo se obává leaknutí citlivých dat mimo /home. Já bych neodsuzoval ani jednu možnost, záleží to na podmínkách

[Josef Kufner]

Příloha:

• 23wJQ.png (5056 bytů)

No... viz příloha. Asi tak.

Heslo je jedno k celému disku, všechny partitions vyjma /boot jsou uvnitř šifrovaného kontejneru = jedno heslo, žádný keyfile, libovolný počet fyzických disků.

[pedro]

Aha, díky beru tu výhradu zpět.

[pedro]

Pro upřesnění nepoužívám to, protože bych neměl z Win přístup na ty oddíly. Ledaže se nechám poučit, že už to nějak jde

[mich]

Zajímavé.

• Začali jsme u Ubuntu a to AFAIK k šifrování home používa encfs, kvůli kterému disk dělit také netřeba.
• Nezáleží náhodou na tom proč a před kým se uživatel rozhodl šifrovat? Například někdo kdo počítač používá k práci a nerad by aby jeho díla (ať už se jedná o zdrojové kódy, hudbu nebo třeba obrázky), která má uložená v různých podadresářích svého home někdo získal při odcizení notebooku asi nepotřebuje šifrovat celý disk.
• Pokud máte pocit, že šifrování home není dostatečné, tak overkill asi není to správné slovo.
• Některým uživatelům může stačit šifrovat jen home, nebo dokonce jen určitý adresář s citlivými daty a proto pro ně může být encfs výhodnější. Například proto, že k jeho použití nepotřebují root práva a nebo proto, že to v nějakém Ubuntu či podobné distribuci nastaví přes klikátko.

[Jooky (inactive)]

hmm, preco sa tu poslednu dobu vsetky diskusie zvrhnu na kto ma vacsi ? ... font pri pisani odpovedi.

a teraz vazne ...

Ako uz bolo spomenute, tak sifrovanie len /home adresaru nie je najbezpecnesia volba. Sifrovane data mozu "ujst" do nesifrovanej casti. V pripade, ze ide naozaj o dolezite data, alebo sa notebook prenasa, tak je lepsia volba sifrovat cely disk. Ono sa to nezda, ale aj sukromny kalendar, fotky priatelky, logy zo servra a podobne data vedia napachat problemy, ak su v zlych rukach. Preto doporucujem sifrovat cely disk.

S pohladu pouzivania nie je velky rozdiel. Pocas instalacie sa zada jedno heslo navyse (heslo k disku) a toto heslo si system vyziada pocas bootovania. "Spomalenie", ak sa to tak da nazvat nie je bezne viditelne a pokial masina nema nejaky strasne stary/pomaly CPU tak takmer nemeratelne.

Ja sam pouzivam Ubuntu a full disk encryption uplne bez problemov. Dokonca pocas pracovnej doby bezim aj fy virtualku (Win7) a nejake spomalenie nie je badat.

a co sa tyka nesifrovanej /boot particie. Lepsie riesenie proste nie je, kedze kernel a nejaky zakladny set binariek sa proste od niekde musi nacitat. Riesenie ako chranit /boot je cislo na HW urovni. Neviem ako su na tom ostatne booky, ale napr. HP uz dlhsiu dobu neriesi klasicky "cmos", ale kombinaciu TMP + eeprom. Na takom booku staci nastavit heslo do biosu a zakazat bootovanie s inych zariadeni ako z interneho disku. Popripade sa da nastavit aj heslo pred bootovanim z disku. Pri takej konfiguracii potencialny utocnik nema moc moznosti ako "nakazit" system. Rozoberanie by mu uz nieco trvalo (pristup k disku) a v pripade kradeze mu je HW na ... kedze "reset cmos" proste taky book nema.

ak bude cielovy disk ssd, tak konfiguraciu systemu mam celkom detailne spomenutu na svojej wiki stranke.

[Šangala]

Chránit boot, můžeš tím, že ho máš na flashce a po nastartování ho odpojíš a fashku vytáhneš.

[Jooky (inactive)]

dovod ?

heslo do biosu = utocnik musi rozobrat notebook aby mohol s /boot manipulovat
heslo na disk = utocnik musi rozobrat aj disk ...

viz. nizsie ... a ked by som zistil, ze mi niekto manipuloval s notebookom, tak rovno prehlasim data v nom za nepouzitelne.

[Šangala]

dovod ?

Na ten si musíš přijít sám, uvedl jsem jakou máš možnost.

[Jooky (inactive)]

skoro som zabudol.

V pripade poskodenia disku sa to tvari takmer ako keby tam sifrovanie nebolo. Mapovanie je riesene cez bloky a v pripade poskodenia sektoru na disku dojde k nepristupneniu celeho sifrovaneho bloku. Ak tento blok padne do nejakej dolezitej casti, tak je to zle (obdobne ak by taky blok padol niekde do metadat fs). V tom pripade sa treba pomodlit, ze aspon niektori dalsi blok metadat bude pristupny a fs tooly sa s tym popasuju. V pripade ak taky sektor padne (vratane sifrovaneho bloku) do nejakej datovej casti, tak v lepsom pripade to poskodi len nejaky *.iso subor.

Teoria je sice pekna, no najlepsie je mat backup. Podla moznosti na dobrom mieste a tiez sifrovany :o)

Co sa tyka TrueCrypt a inych veci. Ja by som to neskusal "lamat cez koleno" a davat tam nieco ine. Kombinacia luks(dm-crypt)/ext4, ktoru pripravi samotny ubuntu instalator je v pohode a hlavne nativne podporovana.

a posledna vec na zaver. V pripade maximalnej paranoje sa da nastavit aj heslo pre elektorniku na disku a v tom pripade debata ohladom nesifrovaneho bootu uz uplne straca zmysel :o)

[pedro]

"Spomalenie", ak sa to tak da nazvat nie je bezne viditelne a pokial masina nema nejaky strasne stary/pomaly CPU tak takmer nemeratelne.

To záleží na tom, jakou použiješ šifru, velikost klíče, hash + proti jak odhodlanému útočníkovi to stavíš (proti náhodnému zloději stačí cokoliv). Tak jak to popisuješ je to strašně zjednodušené. O DES se také léta tvrdilo. že je to bezpečná šifra.

[Jendа]

O DES se také léta tvrdilo. že je to bezpečná šifra.

Nemyslím si. Konspirační teorie kolem velikosti keyspace vznikly chvíli po zveřejnění.

[pedro]

Konspirační teorie existují vždycky, kolem AES jsou dnes konspirační teorie také. Viz hromadné přecházení na AES-256.

Otázka samozřejmě je, jestli to jsou konspirační teorie nebo smysluplná opatrnost. Já myslím, že to druhé

[Jendа]

Viz hromadné přecházení na AES-256.

Já naopak vidím hromadné přecházení na AES128, protože někdo zdramatizoval nepodstatnou chybu v key schedule AES256.

Btw. AES256 je odolný proti útoků, které udělají sqrt(keyspace), což je třeba taková ta kvantová věc, které nerozumím. Z AES128 se stane 64, což už je dneska cracknutelné i pro nadšeného smrtelníka.

[pedro]

Mno, myslel jsem to, co uvádíš v druhém odstavci. Objevený a navrhovaný kryptoanalytický postup jsem také nepochopil (na to nejsem dost velká bedna), nicméně jsem pochopil, že jeho implementace se současnou technologií je obtížná a naděje jsou vkládány do kvantových počítačů

[lertimir]

DES, v rámci své délky klíče, je bezpečná šifra. Na 16 kolový DES nebyl nikdy nalezen kryptografický útok, který by byl lepší než útok hrubou silou. Jediné kryptografické útoky, které byly nalezeny, byly na DES s omezeným počtem kol. A rozhodně se o prolomení po 20 let staraly největší mozky v oboru (tedy alespoň ty mozky, které pracovaly a pracují v akademické svéře.) To, že délka klíče odpovídá schopnostem počítačů 70 let a je již nějakou dobu překonaná, je jiná věc.

[pedro]

Tak to jednak není pravda, nicméně pointa je v tom, že pokud k tomu optimisticky udělám analogii, tak AES bude prolomen cca v roce 2018. Je samozřejmě nutné si uvědomit, že se tady bavíme o teoretických útocích, které jsou extrémně náročné na technologie. Pokud se budeme bavit o dnešní realitě, tak proti AES lze použít cold-boot útok a následné nalezení klíče je zrovna u této šifry díky existující optimalizaci dětská slavnost...

Tim nechci nijak utocit na AES. Ale ono máme "bezpečnost" a bezpečnost. Jak to vyznělo v příspěvku výše, tak tam šlo spíše o "bezpečnost", proto jsem na to takto reagoval.

[lertimir]

Máte odkaz na skutečný útok na 16 kolový DES nebo je to jen jedna paní povídala?

[pedro]

Eli Biham, Alex Biryukov: An Improvement of Davies' Attack on DES. J. Cryptology 10(3): 195-206 (1997). Text je dostupný ze Springeru, možná i někde jinde.

DES byl navíc prolomený hrubou silou někdy koncem 90. let, takže mi zastávání se DES připadá poněkud srandovní

[Jendа]

In this paper we improve Davies’ attack [2] on DES to become capable of breaking the full 16-round DES faster than the exhaustive search. Our attack requires 2⁵⁰ known plaintexts and 2⁵⁰ complexity of analysis.

Tak určitěěěě…

Ano, chtělo by to updatovat předchozí tvrzení na vyžadující praktický útok.

[lertimir]

Já se nepřu, že DES je dávno prolomený, ale o kvalitu šifry. Ten článek znamená, že po 20 letech útoků na DES snížili komplexitu útoku z 2^56 útoku hrubou silou na komplexitu 2^50 s tím, že potřebují prostor 2^50. Což je pravda, že jsem se mýlil, že není útok, ale zase získání 6 bitů není moc. Pokud na AES se najde útok, který sníží prostor o 20 bitů pořád to bude dostatečně bezpečná.

[pedro]

Pánové, to ale je praktický útok, praktičnost se vyznačuje tím, že jej lze v praxi provést (tzn. s využitím současné, bežně dostupné techniky) a to uvedený útok lze.

Předmětem kryptoanalýzy NENÍ nějakým zázračným způsobem prolomit šifru, cílem JE šifru oslabit tak, aby se snížila původní výpočetní náročnost jejího prolomení (hrubou silou).

Celé mi to přijde od vás obou, že jste se prostě rozhodli bránit pozici, které ani sami nevěříte.

U Jendy nechápu, že na jedné straně přesvědčuje výše k šifrování celého disku, že by snad mohlo něco leaknout (což respektuji), na druhé straně mu ale zřejmě každá šifra včetně DES připadá dost dobrá (to není vzájemně moc konsistentní).

U lertimira je to jednoduchoučká otázka, budeš tedy svá data šiftovat pomocí DES, nebo ne?

[Jendа]

Pánové, to ale je praktický útok, praktičnost se vyznačuje tím, že jej lze v praxi provést

OK, předveď nějaký kryptosystém, kde toto lze provést.

ale zřejmě každá šifra včetně DES připadá dost dobrá (to není vzájemně moc konsistentní).

To jsi vyvěštil kde?

[lertimir]

Samozřejmě, že bych v současnosti data DESem nešifroval. V současnosti bych nešifroval ani 3DES a to si o něm myslím, že je bezpečný i proti praktickému útoku. Ten důvod by nebyl v nebezpečnosti, ale v pomalosti a zastaralosti. Na DESu je jasně vidět technologie 70, let tedy to, že raději provedu bitové permutace, než nějakou standardní operaci ve vhodné grupě. Permutace se efektivně dělají jen přímým zadrátování. Na současných 64 bitových procesorech přímo prohazovat bity je strašně neefektivní. Ale stejně tak nepoužívám RSA s 512 bitovým klíčem a před 15 lety jsem to dělal.

[pedro]

Hmm, tak prostě máme jiné názory. Podle mě DES bezpečný není, což jsem se snažil nějak doložit, proto bych ho nepoužíval. Stejně tak bych nepoužil AES-128, ne proto, že v této chvíli není bezpečný, ale proto, že pokud jde o rezervu do budoucnosti, tak jsou lepší šifry.

[Jendа]

Hmm, tak prostě máme jiné názory. Podle mě DES bezpečný není

Já jsem z lertimirových příspěvků nabyl dojmu, že má tentýž názor.

[lertimir]

Ok. Myslím, že se dostáváme, ke vzájemnému porozumění názorů nás obou. Jen poslední poznámku k DESu. To že za celou dobu jeho existence se podařilo mít útok jen o 6 bitů kratší než je plný klíč a ještě s nutným prostorem 2^50 považuji za skvělý výsledek. Navíc to jsou útoky "known plaintex" (Junod útok je ještě o něco efektivnější), "ciphertext only" je na tom samozřejmě hůř. To, že v současnosti je triviálně zlomitelný díky malému prostoru klíče na tom, že to byla dobře navržená šifra nic nemění.

K současné bezpečnosti: V současnosti považuji prakticky dosažitelné lámání ve velikosti 2^70-75 a očekávám, že během 10-15 let se prostor zvedne tak na 2^90. Více asi ne, protože přímý výkon na jádro se zastavuje a ten nárůst vidím hlavně v masivní paralelizaci. K čemuž AES-128 má ještě nějakou rezervu, ale souhlasím, že už jí moc nemá. Na druhou stranu se ukáže, jestli related key attack z roku 2009 ve kterém se prostor pro AES-256 dost zmenšil, bude mít nějaké praktické důsledky. Beru, že krypto je hlavně o dostatečné rezervě, mimo jiné Schneier už dost dávno psal, že AES má málo kol na opravdu bezpečnou rezervu

[Míra]

Tak jsem zkusil to zašifrování celého disku dm-crypt. Jen se mi moc nelíbí, že to není moc hezky udělaný. Například tam chybí možnost počítač vypnout, když ten, kdo ho zapnul zjistí, že potřebuje heslo.

[Šangala]

Na to tam má tlačítko

[Míra]

Já to vím, ale co BFU? Prostě ta možnost by tam slušela...

[Šangala]

No nevím, dle mé zkušenosti BFU mačká tlačítka jako první a jedno kde zrovna jsou a kde je ups-ka :)

[Míra]

1. to tlačítko na vypnutí je ale potřeba podržet, než to celý spadne - tvrdej power down. Vo tom fakt moc běžnejch uživatlů neví. A ani mně se to moc nelíbí...
2. Zašifrování celého disku pomocí dm-crypt je asi bezpečné, ale půjčování notebooku v rodině (manželka, děti,...) to neřeší.
3. šifrování /home pomocí encfs je uživatelsky daleko příjemnější, ale moc se mi nelíbí když jde procházet adresářovou strukturou...
4. můj původní dotaz vzniknul proto, že když si na dovolenou beru svůj noťas, tak v něm chci mít co nejvíc dat, jako bych byl doma. Ale jak ho zabezpečit pro případ krádeže?
5. TrueCryp mi přijde uživatelsky nejpříjemnější, ale nevím, jestli se mu dá věřit. Záloha je zde strašně jednoduchá - prostě se ten zašifrovanej kontejner někam uloží...

Zálohu mám, ale kdyby se noťas ztratil, tak data na něm musí být k ničemu...
Netušil, jsem, že se kolem toho rozvine taková debata, ale díky za ni...

[Jendа]

5. V čem je TrueCrypt v souboru jednodušší na zálohování než dm-crypt v souboru? V čem je TrueCrypt na blokovém zařízení jednodušší na zálohování než dm-crypt na blokovém zařízení?

[Šangala]

1. To tak prostě je, je to prostě maximálně bezpečné, je funkční jen to nejmenší možné minimum.

2. Proč to neřeší? Každý může mít své heslo (pokud vás tedy není roj, ale roj na jeden NTB je z principu blbost).

3. No právě.

4. Tady je to jádro, šifrovat můžeme z různých důvodů, dle toho čemu chceme zabránit. A pokud je to proti krádeži obecně, tak je nejednoduší jistota šifrovat celý disk, bo už to zde bylo zmíněno, adresář /var, či /tmp někdy i /etc může obsahovat spoustu zajímavých dat, stejně tak jako swap. Pokud budu mít v NTB klíčenku s hesly (byť je šifrovaná) ke službám, či certifikáty na nešifrovaném svazku, tak při krádeži mám měsíc práce a nevím „jestli to stihnu dřív než oni“, ale pokud mám šifrovaný celý disk a vím, že mi NTB zmizel, když byl vypnutý a mám dostatečné dlouhé neslovníkové heslo, tak jsem naprosto v klidu.

5. Nerozumím, zálohovat lze jednoduše cokoliv.

[Jendа]

2. Při leaknutí (nebo slabosti) jednoho hesla se dostanou do všech ~ (jestli jsem pochopil správně, jak to myslíš).

[Šangala]

Ano, je tak.

Nenašel jsem jiný důvod v souvislosti s ochranou dat vůči krádeži, který by bránil půjčování NTB v rodině, krom sdílení jednoho hesla.

[Nicky726]

ad 2) LUKS oddíl může mít více hesel (to řeší ty nutně sdílené jako /) a s použitím pam_mount lze odemykat LUKS oddíl uživatelským heslem do systému, takže lze pak mít user-friendly přístupné oddíly pouze pro daného uživatele.

[Jooky (inactive)]

V momente ked si pyta prve heslo (k disku), tak este nie je nic namontovane. Bez akehokolvek problemu je mozne PC vypnut hw tlacidlom. Pred namontovanim root disku ma system len minimalny set binariek na obsluhu disku a sifrovania.

[MilanK]

EncFS používám od doby, kdy tuším v Ubuntu dali dokupy automatizované skripty a PAMencfs pro automount po přihlášení. Takže už hodně let. Sice v Arch Linuxu, ale implementace bude IMHO stejná.

Plně vyhovuje neboť:

• Počítač používá více lidí a /home/... šifrují pouze někteří.
• Počítač musí jít spustit vzdáleně (WOL) a současně musí být spustitelný lokálně, i když nebude fungovat síť.
• Je-li třeba, lze samostatně šifrovat /tmp i /swap (různými způsoby) - nicméně zatím necítím potřebu.
• /opt ani /var ani /usr/local neobsahují data, která bych potřeboval šifrovat.

V adresáři /home/.ecryptfs/user/ jsem dodatečně vytvořil:

• ./ssh/authorized_keys - pro přihlašování s klíči
• .face - pro zobrazení avataru uživatele před přihlášením v DM

"Podkladovým" FS je ZFS - je nepochybně pomalejší než např. ext4, ale vyhovuje mi z jiných důvodů. EncFS přidá další zpomalení, to mne také moc netrápí. Nejvíce se pomalost projevuje při otevírání Evolution (používám maildir, tedy hodně malých souborů).

Při poškození FS: ztraceny jsou jen jednotlivé šifrované soubory. Poškodí-li se klíč, pak je pochopitelně v háji vše. (Od toho jsou zálohy.)

Kdysi dávno bývaly problémy, že např. GDM si chtělo sáhnout do /home/user/.kamsi dříve, než proběhlo dešifrování adresáře, ale to už je tuším vyřešeno.

Pokud byste používal hooodně dlouhé názvy souborů, mohl byste narazit o něco dříve, než byste narazil bez EncFS (šifrované názvy souborů jsou o něco delší).

Jinak z uživatelského hlediska problémy při denním používání nepozoruji.

[little.owl]

EncFS je pomale a trpy fragmentaci, a v kombinaci se ZFS to tedy musi byt lahudka. Skutecne nevidim ve vetsine pripadu uziti duvod nahrazovat LUKS a libovolny FS timto user spacovym kramplem.

[JanM]

Ano, ZFS má problémy s fragmentací a postupným zpomalením zvláště při takovém tom domácím použití (ZIL ani L2ARC nemám na extra discích, používám pouze raid0 pro rychlejší čtení).

Jenže mi náramně vyhovuje jednoduchá logika "ovládání" celého FS (pouze dva příkazy zpool a zfs), rychlé snapshoty, snadné automatické připojení snapshotů přímo v jakémkoliv souborovém manažeru a jistota konzistence dat (respektive upozornění v případě nekonzistence).

Prostě se mi to lépe používá než ostatní alternativy a jsem ochoten tolerovat stinné stránky tohoto FS.

YMMV.

[little.owl]

Ano, ZFS má problémy s fragmentací a postupným zpomalením

Problem je, ze to ma i EncFS, takze mame dve vrstvy se stejnymi problemy.

a jsem ochoten tolerovat stinné stránky

Jinak byste to nedelal.

Ja cekam na btrfs, i kdyz zabudovana encryption v nedohlednu.

[JanM]

ZFS on Linux také zatím šifrování nepodporuje, proto ten EncFS. Snad časem, ale nejspíše se toho nedožiju [1].

[1] https://github.com/zfsonlinux/zfs/issues/494

V btrfs také doufám, ale ta krkolomnost používání mne moc netěší - byť pro ajťáka to asi zásadní problém nebude. (Viz třeba přístup do snapshotů - ono je nutné je ručně přimountovat a mít admin práva...)

[JanM]

A ještě bych doplnil jeden aspekt:

Každý uživatel má k dešifrování svého HOME _vlastní_ klíč.

Při použití LUKSu sice lze vytvořit vícero klíčů, ale každý z nich dešifruje celý LUKS oddíl - tedy data všech uživatelů. Řešením je vytvořit pro každého uživatele vlastní diskový oddíl, ale pak je to IMHO nekonečný boj s místem... Pořešit by se to možná dalo se ZFS, pakliže by se dataset exportoval jako blokové zařízení (nejsem si jist, zda-li to jde)...

[little.owl]

Každý uživatel má k dešifrování svého HOME _vlastní_ klíč.

To mi prijde jako jedina vyhoda vaseho reseni, respektive pouziti EncFS.