EncFS - sifrovaci filesystem

13.6.2005 09:50 | Přečteno: 1475× | Linux

Paranoia si pyta svoju krutu dan a preto maju obcas jedinci silnu potrebu sifrovat svoje data. O sifrovani posty cez GPG resp. PGP sa vseobecne polemizuje a podla zlych jazykov sa zacinaju presadzovat pravne normy, ze kto sifruje nieco musi skryvat a preto je terorista, extremista, separatista, fundamentalista...*ista.

Sifrovanie dat pod Linuxom nie je ziadna horuca novinka. Pouziva sa cryptoloop, ale ten sa vraj vseobecne povazuje za nie velmi bezpecnu zalezitost. Do popredia prichadza dm-crypt (uprimne povedane, nepodarilo sa mi to rozchodit ale to je mozno aj tym ze som povodne chcel iba vytvorit subor a ten cez loop pouzivat ako dalsiu particiu; tento postup ale nie je odporucany pri zurnalovacich FS).

Po hladani mi pan Google poradil EncFS. Nazov je zaujimavy a mozem konstatovat ze mi EncFS funguje Polovicnym uspechom je mat v systeme FUSE a to tak ze musi aj fungovat. Potom uz iba staci EncFS

Vyhody

• nepotrebuje zvlast particiu
• dynamicky sa meni velkost podla potreby
• lahke zalohovanie

Nevyhody

• da sa lahko zistit objem dat ktore sifrujeme
• jednotlive sifrovane subory su viditelne (velkost, prava)

EncFS pouziva na samotne sifrovanie OpenSSL a podla toho vyuziva aj rozne sifry. Samotne pouzivanie EncFS je velmi lahke.
encfs ~/.crypt/Mail ~/Mail
encfs - samotny program
~/.crypt/Mail - umiestnenie zasifrovanych suborov
~/Mail - mountpoint pre desifrovane subory

Pri spusteni si program pozrie ci uz existuje takyto sifrovaci fs a ak nie tak sa spustie sprievodca. Ten sa opyta na pozadovane parametre sifrovania (sifra, velkost kluca, init. vektor, mac...). Pre bezneho laika su prednastavene 2 stupne zabezpecenia - standart (Blowfish Key Size: 160 bits Filesystem Block Size: 512 bytes Filename Encoding: Block encoding with IV chaining Unique initialization vector file headers) a paranoia (AES Key Size: 256 bits Filesystem Block Size: 512 bytes Filename Encoding: Block encoding with IV chaining Unique initialization vector file headers Message Authentication Code block headers External IV Chaining), expert ma moznost si nastavit parametre bola vlastneho uvazenia. Samozrejme po tejto procedure si program vyziada heslo a ako pri inych sifrovacich nastrojoch aj tu je heslo povazovane za slabinu. Takze cim vacsie a komplikovaniejsie heslo, tym lepsie.

Ak uz existuje sifrovaci fs, program si vyziada heslo a mozete pracovat. Odmountovanie fs zabezpeci prikaz fusermount -u ~/Mail

       

Komentáře

[Ritchie]

Návod, jak zprovoznit dm-crypt, je odkazován v jiné diskuzi.

[Jaris]

dakujem, prestudujem

[azurIt]

"cim vacsie a komplikovaniejsie heslo, tym lepsie"

toto nie je celkom pravda. vybranie spravneho hesla nie je az tak jednoduche :) praveze nesmie byt prilis dlhe ani prilis zlozite (tazko sa pameta - pouzivatel je nuteny si heslo niekam zapisat) a zase naopak nesmie byt ani prilis kratke ani prilis jednoduche. cize najlepsia je stredna cesta ;) (ako takmer vsade)

[Mikos]

Na zprovoznění dm-cryptu opravdu nic není, stačí si přečíst dokumentaci na webu a prostudovat nějaký ten příklad. Zvládl sem to tak v pohodě i já, tak by to snad opravdu problém být neměl Pokud to chcete vyzkoušet jen nad souborem (který připojíte přes loop), tak můžete postupovat třeba takto:

# pro zacatek hromada promennych secure_filesize=100 secure_file="~/secure/securedisk01.img" secure_key="~/secure/securedisk01.key.gpg"

secure_loop="/dev/loop0" secure_dm="securedisk01" secure_mountpoint="~/secure/securedisk01"

secure_keysize=256 secure_hash="sha256" secure_cipher="aes-cbc-essiv:sha256"

# vygenerovani klice a jeho zasifrovani pomoci GPG head -c 2880 /dev/urandom | uuencode -m - | head -n 65 | tail -n 64 | gpg -c --cipher-algo AES256 > ${secure_key}

# vytvoreni souboru, ktery budu mountovat dd if=/dev/urandom of=${secure_file} bs=1M count=${secure_filesize}

# nahozeni loop nad vytvorenym souborem losetup ${secure_loop} ${secure_file}

# nahozeni sifrovaneho zarizeni nad loopem gpg -q --cipher-algo AES256 --decrypt ${secure_key} | cryptsetup -v -h ${secure_hash} --key-size=${secure_keysize} --cipher=${secure_c ipher} create ${secure_dm} ${secure_loop}

# vytvoreni filesystemu na sifrovanem zarizeni mke2fs -j -m0 /dev/mapper/${secure_dm}

# primountovani sifrovaneho zarizeni mount -t ext3 -o noatime /dev/mapper/${secure_dm} ${secure_mountpoint}

[Mikos]

Jinak bych jeste doplnil, ze cryptoloop uz je (pokud vim) deprecated a ma co se bezpecnosti tyce sve problemy. dm-crypt je mnohem lepsi a nahrazuje jej. A spolu s sifrovanim aes-cbc-essiv:sha256 (ktere bylo pridano tusim v kernelu 2.6.10 a je imunni vuci watermark utoku) uz z meho pohledu neexistuje jediny duvod, proc pouzivat neco jineho (treba loop-aes nebo to co ste objevil vy).

[Mikos]

Ouuu, koukam ze tag <code> se nechova tak jak jsem cekal Tak jeste jednou ten postup vytvoreni kryptovaneho souboru a jeho primountovani, tentokrat s pouzitim tagu <pre>

# pro zacatek hromada promennych 
secure_filesize=100
secure_file="~/secure/securedisk01.img"
secure_key="~/secure/securedisk01.key.gpg"
secure_loop="/dev/loop0"
secure_dm="securedisk01"
secure_mountpoint="~/secure/securedisk01"
secure_keysize=256
secure_hash="sha256"
secure_cipher="aes-cbc-essiv:sha256"

# vygenerovani klice a jeho zasifrovani pomoci GPG
head -c 2880 /dev/urandom | uuencode -m - | head -n 65 | tail -n 64 | gpg -c --cipher-algo AES256 > ${secure_key}

# vytvoreni souboru, ktery budu mountovat
dd if=/dev/urandom of=${secure_file} bs=1M count=${secure_filesize}

# nahozeni loop nad vytvorenym souborem
losetup ${secure_loop} ${secure_file}

# nahozeni sifrovaneho zarizeni nad loopem
gpg -q --cipher-algo AES256 --decrypt ${secure_key} | cryptsetup -v -h ${secure_hash} --key-size=${secure_keysize} --cipher=${secure_cipher} create ${secure_dm} ${secure_loop}

# vytvoreni filesystemu na sifrovanem zarizeni
mke2fs -j -m0 /dev/mapper/${secure_dm}

# primountovani sifrovaneho zarizeni
mount -t ext3 -o noatime /dev/mapper/${secure_dm} ${secure_mountpoint}

[Ritchie]

Jistě se nebudete zlobit, když váš postup podrobím kritice.

Způsob generování klíče je docela šílenost. Proč používáte pro získávání dat pseudonáhodné (urandom) namísto náhodného (random) zařízení?

Protože používáte na klíč 256b hash, mělo by teoreticky stačit 32 B zcela náhodných dat. Jako paranoik jich vezmu pro jistotu 64 B.

dd if=/dev/random bs=1 count=64 | gpg...

Není mně jasné, proč zadáváte key-size, když klíč negenerujete z nekonečného zařízení. Parametr key-size slouží, když se např. klíč čte z /dev/random pro šifrování swapu.

BTW Osobně používám na hashování hesla raději SHA512.

[Mikos]

Vaší kritiku beru, díky za ní. Já nejsem žádný odborník přes kryptologii a tenhle skript sem si vytvořil jen po přečtení webové dokumentace k dm-crypt a ještě nějakého příkladu. Toho že by mělo stačit teoreticky 32B když použiji hash sha256 jsem si vědom, nicméně použitím delšího přece člověk nic nezkazí Key-size sem zadával jen pro jistotu, abych na to nezapomínal v případě že bych někdy v budoucnu zvolil klíč jiné délky, který by byl třeba delší (zatím sem si s tím jenom hrál).

Co se týče /dev/random a /dev/urandom, tak tam jsem nikdy přesně netušil jak to s tím je. Věděl sem jen že /dev/random by mělo produkovat zcela náhodná data (narozdíl od pseudo-náhodných u /dev/urandom), ale jejich vygenerování mi přišlo že trvá moc dlouho (holt asi než se "nahromadí" dostatek entropie... ježiš fuj, to je ale hnusně a blbě formulovaný, ale teď mě nenapadá jak to formulovat lépe ) a jelikož jsem si s tím jen hrál, použil sem /dev/urandom.

[Mikos]

Btw. už si vzpomínám proč sem použil ten postup s vygenerováním mnohem dalšího klíče a aplikováním uuencode - chtěl jsem aby ten klíč neobsahoval žádné "paznaky".

[Ritchie]

64 B se přečte z /dev/random natotata a víc bytů skutečně není třeba. Hlavně jsem se pozastavoval nad tím složitým příkazem pro generování zašifrovaného klíče, když stačí dd a gpg.

Přeci nevadí, že jsou klíčem binární data. Pokud jej potřebujete uchovat v čitelné formě, tak jej můžete do ASCII jednoduše převést třeba pomocí uuencode či algoritmem base64 apod. Pokud přímo trváte na ASCII klíči, tak jednoduše vložte mezi dd a gpg příkaz pro překódování do ASCII.

Key-size má smysluplné použití skutečně jen tehdy, čte-li se klíč z nekonečného zařízení, aby se čtení někdy skončilo. Key-size omezuje velikost vstupu, který se bude hashovat. Vlastní šifrovací klíč pro algoritmus AES je pak výstup hashe, a je tudíž vždy tolikabitový, kolikabitová je použitá hash.

O entropii mi nehovořte, čeká na mě zkouška ze statistické termodynamiky.

[Mikos]

Jinak jeste jednou veci sem si nebyl jisty kdyz sem ten postup vymyslel - chtel sem za kazdou cenu pouzit GPG (symetrickou sifru), ale nevim zda je lepsi defaultni CAST5 nebo AES256 (kterou jsem nakonec zvolil). Zkousel sem ohledne porovnani techto dvou sifrovacich algoritmu najit nejake materialy, ale moc se nezadarilo... Nevite jak na tom ty sifry jsou? Pripadne srovnani jeste s nejakou jinou na podobne urovni, kterou GPG nabizi?

[Ritchie]

Ani já v kryptografii moc zběhlý nejsem. Do matematické podstaty hashí a šifer vážně nevidím, takže vám bohužel nemohu poradit.