titkosítás cloudban tárolt fájlokra

Linux-haladó

Sziasztok!

Van pár fájlom, amiket szívesen tárolnék valami google drive vagy dropbox szerű helyen, több gépről elérhetően. Viszont nem szeretném, ha bárki csak úgy el tudná ezeket olvasni.
Elsősorban Linux alól akarom használni, de ha mondjuk Windows alól is elérhető, az hasznos lenne.

Hasonló problémára mit ajánlanátok?

Nekem az jutott eszembe első közelítésre, hogy készítek dd-vel egy valamekkora fájlt, monjduk 1GiB méretűt, ezt teszem a szinkronizált könyvtárba, készítek bele valami titkosított fájlrendszert és felmountolom Linux alatt, amikor ezek a fájlok kellenek.

Feltételezem, ez működne, de persze Win alól nem, meg Linux alól se tudom, mennyire kényelmes.

Esetleg valakinek valami más ötlete lenne?

Köszi,
G

  • 12982 megtekintés

( Proci85 v | 2012. 11. 21., sze – 10:47 )

Ha TrueCrypt-ot használsz és azzal készíted el a konténer fájlodat, akkor linux és windows alól is menni fog.

Én TrueCrypt-tel próbálkoztam, de ugye a titkosított file rendszernek az a lényege, hogy ne lehessen követni, mi történik benne, ennélfogva ha valami apróságot módosítasz, akkor a fájl nagyon megváltozik és szinkronizálhatod az egészet. Nem volt kényelmes amit összeraktam, maradtam a pendrive-nál.

A teljes image file-t nem azért kellett feltöltened, mert a TrueCrypt az egészet átírta volna (ha ez lenne a helyzet, nagyjából használhatatlan lenne bármilyen random-access (=block) device-on; szinte biztos, hogy LRW-t vagy XTS-t használ). Azért kellett feltöltened az egész image-et, mert a cloud tárhely csak file-szintű szinkronizálást támogatott.

( johans | 2012. 11. 21., sze – 11:57 )

Az encfs jó kompromisszum lehet. Nem annyira biztonságos, mint a truecrypt, mert titkosított fájlok darabszámát és körülbelüli méretét ki lehet találni, de a pontos fájlnevet és a tartalmat az iparági standard AES256 védi. Cserébe, ha csak 1 fájl változik, akkor csak 1 fájl szinkronizálódik fel, nem az egész device. Van windowsos implementációja is, bár azt nem próbáltam. Androidon és Linuxon ment szépen.

Ezzel meg a fentiekkel az a baj, hogy adott fix erősségű titkosítással tolsz ki adatot a netre, melynek erőssége idővel folyamatosan gyengül. Nem jó megoldás fontos adatok tárolására, mert ki garantálja, hogy a használt titkosítási algoritmusnak nem fedeznek fel hibáját a közeljövőben? Illetve hogy a számítási kapacitás nem lesz akkora, hogy a törési idő pár napra redukálódik? Közben amit kitoltál meg ott lehet akárhol, le-cache-elve.

Egy SSL kapcsolaton a kezdeti asszimetrikus titkosítással minden session-höz más szimmetrikus titkosító kulcs használható. De itt most egy helyen koncentrált sok adatról beszélünk, amelynél mind 1 fajta módszerrel és 1 kulccsal van titkosítva. Ezt így ki publikusba elgondolkodtató. Persze családi képekhez elmegy, de egyébként nem maga a tökély.

Szerintem több ponton téves az érvelésed.

- Először is ezek a cryptók nem ECB-t, hanem CBC-t vagy hasonlót használnak, így az eredeti kulcsra csak a legelső blokk utal.

- Az AES brute-force töréséhez az ismert matematika és fizika határain belül egy 100 petaflops teljesítményű gépnek 3x10^51 évre lenne szüksége. Összehasonlításként: a világ top10 ismert szuperszámítógépének az összesített elméleti peak teljesítménye ~90 petaflops, a valós ~68 petaflops. Azt hiszem az én életemben nem fog akkora teljesítmény ugrás bekövetkezni, hogy az AES napok alatt törhető legyen.

- Az AES titkosítást még Rijndael néven nevezték 2001-ben a DES/3DES leváltására kiírt pályázatra. Az utolsó körbe bekerült 5 algoritmust (Rijndael, Serpent, Twofish, RC6, MARS) 5 évig próbálták támadni a világ vezető matematikusai az összes ismert és újonnan kitalált módszerrel, sikertelenül. Természetesen azóta is próbálkoznak, több irányban: az egyik az, hogy az eredeti kulcs ismeretében a titkosított stream "közepétől" visszafejthető legyen, ez nem vezetett gyakorlati eredményre. A másik fontos irány, hogy magát a kulcsot állítsák vissza az eredeti tartalom brute-force megtörésénél kisebb számításigénnyel. 2011-ben publikáltak egy ilyen irányú sikeres törést, itt a számításigényt kb. a negyedére sikerült levinni. Ez azt jelenti, hogy az elképzelt 100 petaflops-os gépednek már csak 7,5x10^50 évet kell dolgoznia.

Valódi sikert az AES ellen csak az úgynevezett side-channel támadással értek el. Ez azt jelenti, hogy nem az AES kódolást, hanem az implementációt, az implementációból következő adatszivárgást támadják. Ezeknek a közös tulajdonsága viszont, hogy a támadó kódnak a titkosító kóddal egy hardveren, egy időben kell futnia.

Összefoglalva: egészen biztos lehetsz benne, hogy ha minden adatodat ugyan azzal a (megfelelően erős) kulccsal tárolod, akkor nem lesz senki, aki visszafejtse ezt a te életedben. Az xkcd klasszikus megoldástól sokkal nagyobb a félnivalód.

Amit leírtál, azok részletek. Habár lehet fontos, de a logikai problémát nem oldja meg: adott egy fix módszerrel titkosított adat, amit feltolnak a felhőbe. Ettől kezdve ezt már kint levőnek tekinthetjük örökké (nincs bizonyosság arra hogy nem). A hozzá felhasznált titkosítás erőssége biztos hogy nem lesz erősebb, de lehet hogy gyengébb.

Csak azt akarom mondani ezzel, hogy ezek nem feltétlen non plus ultra megoldások, habár annak tüntetik fel őket. Nyilván nem aggódok az adataimért és én is használom a felhőt, nincsenek is olyan adataim amikért a fenti probléma miatt aggódnék, de attól még ez a tuti nem biztos hogy az.

lehet, hogy neked is egy kicsit jobban kellett volna ertelmezni a dolgot. Mert ok, hogy a mai hw-ken (elmeletben) 10^51 ev nagysagrendu a dolog, de mi van, ha pl. 15 ev mulva mar kommersz kvantumszamitogepek lesznek otthon, aminek - ha igaz - lenyegesen nagyobb a kapacitasa, vagy ki tudja azt elore megcafolni, hogy egy mesterseges intelligencia 20 ev mulva nem tori romma az AES-protected cuccodat? Szoval a lenyeg az, hogy a szamitastechnika olyan szinten rohamleptekben fejlodik, hogy akar csak par evre elore is eleg nehez helytalloan josolgatni.

Miert kell nekem sajnalnom a Klubradiot?

:) Ez kész. Csak a kedvedért elmondom, hogy 2000-ben diplomáztam programtervező-matematika szakon az ELTE-n, és a diplomamunkám a kriptográfiáról szólt - legfőképp az éppen folyó AES szabványosításról. De hát értem nem jött el Neo, hogy kiszabadítson a gonosz MI markából, szóval én tényleg nem foghatom fel.

Egyiktől sem kellene hasra esned, csak jeleztem, hogy valami elképzelésem van arról, hogy mit jelent az AES vagy a mesterséges intelligencia - mint ahogy neked láthatóan nincs. Meg - már csak koromnál fogva is - egy ideje nem érzem magam taknyosnak. Szóval óvatosabban kellene bánnod a nagy szavak használatával.

De nem etetem tovább a trollokat, részemről a téma lezárva.

Meg mielott nagyon belemelegednel a meg nem ertett zseni szerepebe (meg hogy _szerinted_ kinek mirol van vagy nincs fogalma, LOL), hadd mondjam el mas szavakkal, de tenyleg csak azert, hogy meg te is megertsd, hogy meg annyi feltalalni-/felfedezni-/tokeletesitenivalo van, hogy siman lehetseges egy olyan szamitogep a valamikori jovoben, ami meglehetosen megvaltoztatja azt, amit addig a szamitastechnikarol tudtunk. Erre hoztam peldakent mondjuk a kvantumszamitogepeket vagy a DNS-szamitogepeket, amelyek potencialis kapacitasat meg aligha tudjuk megfeleloen felmerni. Ezert irtam, hogy ami a jelenlegi hw-n 10^sok ev, az meglehet, hogy meg az en eletemben ennel sokkal kevesebbre olvad majd az akkori hw-ken. Mindez persze a szemellenzos korlatoltaknak hollywood. Jaja, nem is lehet mas, LOL, OMFI...

Miert kell nekem sajnalnom a Klubradiot?

en nem feltetlen igy fognam meg a dolgot. Pl. a villamossagtanban egy sor problema nagyon nehezen oldhato meg a konvencionalis eszkozokkel. Viszont komplex szamokkal (es egyenletekkel) pikk-pakk megoldhato a dolog. Es amint probaltam is utalni ra, folosleges elore bemondanod, hogy 'vegyuk azt, hogy 10^9-szer gyorsabb, ...', mert meg nem tudjuk felmerni, hogy mennyivel lesznek a fentebb hivatkozott eszkozok egyreszt gyorsabbak, stb, es azt sem feltetlen, hogy nem lesz-e a matekban egy olyan eredmeny, amivel jelentosen leroviditheto egy kripto algoritmus feltoresehez szukseges ido.

Matolcsy ur, mondjon mar le!

Ez nem is olyan biztos. Vegyük például az RSA-t. Az RSA-t azért nehéz feltörni, mert a faktorizáció problémáját - úgy tudjuk* - az elmúlt 2000 évben senki nem tudta megoldani, és lehetséges, hogy erre nincs is megoldás. De ha erre valaki álmodik egy képletet, az RSA-t mint titkosítást el lehet felejteni, és lehet kezdeni a kármentést. Mármint ha kiderül. És nagyjából ez a helyzet az összes többivel.

* valójában csak úgy tudjuk. Mert ha az NSA egy matekosa ezt megoldja/megoldotta, biztos nem kürtöli/kürtölheti világgá.

------------------------

Épp arról van szó, hogy van egy elméletileg iszonyat sokára törhető titkosítás, aminek az implementációja sose lesz jobb az elméleti maximumnál, jó esetben elérheti azt.

Viszont aki be akar törni nyilván nem a legerősebb ponton fog betörni, hanem keres jóval gyengébbet. Nyilván akad annyi pénz, olyan módszer, amivel rá lehet venni a szükséges számú alkalmazottat, hogy pl. patkolt klienst terjesszenek az ügyfelek felé, így megszerezve gee féltett adatait.

Ellenben ha emberünk egy saját űberbrutál titkosítást használ, akkor az Ő ujjait kezdik el kalapáccsal széttörni, és gyanítom, hogy rettenetesen hamar ki fog derülni a kérdéses jelszó/kulcs/miegyéb.

Már feltéve ha vannak olyan adatai, amikért érdemes bármit is tenni :D

Ezeket a titkosításokat mennyire gyengíti a számítógép által generált véletlen- vagy prímszám befolyásolása? Mert nagy erőforrásokról beszélünk a töréshez, de ha azok a számok mégsem annyira véletlenek, akkor elvileg nagyban romlik ezek hatékonysága. Én pedig nem látok a bele a processzorba, így nem tudom megítélni, hogy hardveresen mi megy végbe odabent.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
Szerinted…

( veresh | 2012. 11. 25., v – 18:44 )

Nem lenne az megoldás, hogy a felhőben tárolandó fájlokat először gpg-vel titkosítod (pl. nyilvános kulcsú titkosítással) és utána töltöd át a már titkosított fájlt abba a mappába, amelyik a felhőbe van szinkronizálva?

Nem használom és nem próbáltam ezt a módszert, de szerintem működőképes.

Ez túl egyszerű :)De valszeg én is ezt használnám, ha szükségem lenne illetve lenne olyan cuccom, amit titkosítani kellene és feltétlen szükségét érezném, hogy mindenféle platformról (még olajfúróról is) elérhető legyen. Persze sok fájlnál már egy kicsit macerás a dolog.

Jelenleg kevés védeni kívánt fájl van a felhőben, ezek így vannak titkosítva. Illetve nem pont így, de mindegyiknek megvan a maga titkosítása, jellemzően applikáció szintű.
Ez egyszerű, amikor egy szövegfájlról van szó, amit mondjuk vim-mel nyitok meg.

De szívesen felraknék mást is, pl. adóbevallás fájljait, könyvelőprogram adatfájljait, más adatbázisokat, amik programja nem támogat applikáció szintű titkosítást.

Szívesebben használnék egy egyszerű, transzparens megoldást, nem pedig elkezdeni keresni, hogy mondjuk hogyan lehet egy Openoffice-ban jelszavas/titkosításos védelmet bekapcsolni, hogy lehet ugyanezt egy másik, harmadik, negyedik programban.

Persze készíthetnék egy jelszóval (vagy gpg-vel) védett tömörített állományt, egy könyvtárstruktúráról, és ezt tölthetném fel, de ezzel pont a kényelem veszne el, az, hogy jelenleg a védett fájlokra rákattintok, megnyílik, és használom. Esetleg jelszót kér, és használom.
Nem szeretném használat előtt kitömöríteni, bemásolni a megfelelő helyre, elindítani pl. az adatbáziskezelőt, használni, használat után leállítani, tömöríteni, várni, bemásolni...

( handler | 2014. 06. 16., h – 19:58 )

FYI:

"This term came about because most currently popular public-key cryptosystems rely on the integer factorization problem or discrete logarithm problem, both of which would be easily solvable on large enough quantum computers using Shor's algorithm.[1][2]"

https://en.wikipedia.org/wiki/Post-quantum_cryptography