- Csatlakoztatjuk a megfelelő pendrive-ot
- Cryptsetup segítségével megnyitjuk a pendrive partícióját a számítógépen tárolt kulcs felhasználásával és felcsatoljuk.
- Cryptsetup segítségével megnyitjuk a számítógép partícióját a pendrive-on tárolt kulcs felhasználásával és felcsatoljuk.
- Lecsatoljuk a pendrive partícióját és bezárjuk a crypto eszközt.
- Örülünk :)
- A hozzászóláshoz be kell jelentkezni
- 3546 megtekintés
Hozzászólások
Hardwarekulcs házilag? Tökjó!
- A hozzászóláshoz be kell jelentkezni
Mi van akkor ha megbakkan a pendrive?
Be kell tenni egy liveCD-t?
- A hozzászóláshoz be kell jelentkezni
a livecd sem fogja a tikosított anyagot kititkosítani. ez az ötlet lényge. mire jó az a biztosnság, amit egy livecd-vel ki lehet kerülni?
- A hozzászóláshoz be kell jelentkezni
Tényleg, mi van ha egy az egyben lemásolom a pendriveot?
- A hozzászóláshoz be kell jelentkezni
De akkor is szükséged van a számítógépre...
Vagy backup-nak gondolod? Ahhoz fölösleges az egész pendrive-ot lemásolni.
IMHO elég a kulcs, és akkor - ha megzakkant a pendrive - kézzel kiadva a parancsokat vissza tudod szerezni a titkosított anyagot. Hogy ez gyengesége a rendszernek vagy nem, azt mindenkinek magának kell eldöntenie!
Én valahogy nyugottabb vagyok, ha általános megoldást használok, és nem valami hardver vagy sw szállító egyéni megvalósítását... :-o
- A hozzászóláshoz be kell jelentkezni
Inkább az kéne hogy egy kulcsot ne lehessen lemásolni, de gondolom nincsen serialja egy pendrivenak. Vagyis nincs arra mód hogy szoftvert adjunk el pendriveon adott hardware-kulccsal mert felesleges lenne hiszen úgyis feltörhető.
- A hozzászóláshoz be kell jelentkezni
A kulcsot ki lehet írni valahova backup gyanánt, mondjuk gpg-vel titkosítva. Csak a kulcsnak nem szabad elvesznie...
Illetve használhatsz több jelszót is... Howto use Cryptsetup with LUKS support.
- A hozzászóláshoz be kell jelentkezni
Szerintem érdemes lenne a partíció feloldásához egy jelszót is felvenni a luks headerbe arra az esetere, ha akár a pendrive-on lévő, akár annak titkosítására használt kulcs sérülne, és nem lenne elérhető a backup záros időn belül. Sőt... Ebben az esetben mégcsak backup sem nagyon kellene a kulcsokról, hiszen ha elvész, generálsz újakat.
Ha csak a cikkben szereplő megoldásra összpontosítunk, akkor érdemes lenne kiemelni, hogy a kulcsokról feltétlenül készüljön backup valami überbiztonságos helyre! Pl. nyomtassa ki a kulcsokat és zárja páncél szekrénybe, vagy tanulja meg a delikvens. ;)
Én speciel ennek a kulcsok kulcsának kulccsal való titkosításának nem sok értelmét látom, de ez a cikk értékét cseppet sem csökkenti (a szememben). Véded egy partíció adatait egy eszközön tárolt kulccsal. Ha illetéktelen kezekbe kerül ez a token, és tudják, hogy mire kell használni, hozzáférhetnek az adataidhoz. Pont. Ezzel a felállással - ami a cikkben szerepel - amennyiben eltulajdonítják a kulcsot, és tudják mire kell használni, ugynúgy hozzáférnek az adataidhoz, szóval ebből a szempontból extra biztonságot nem nyújt. Ha ez ellen védekeznél, akkor inkább titkosítsd le jelszóval a kulcsot, és máris két faktoros autentikációd van (szükséges a kulcs fizikai bírtoklása és a jelszó tudása a feloldáshoz).
Ha van más szempont, amit nem vettem figyelembe, akkor ne tartsd vissza plz.
- A hozzászóláshoz be kell jelentkezni
Ezzel teljesen egyetértek.
Nekem is megfordult a fejemben a kulcs jelszóval való védése, sajnos nincs rá ötletem, hogy valósítsam meg a felhasználói interackiót gdm bejelentkezés kezelőnél.
Persze persze, vannak workaround-ok, de én alapjában véve lusta ember vagyok... :) És ez már több lépéses dolog, és nem csak annyival, hogy beírok egy jelszót.
Ha tudsz rá egy megoldást, hogy a gdm-en, ha bedugom a pendrive-ot, feljön egy ablak és bekér egy jelszót, azt megköszönöm...
By the way, eredetileg arra is gondoltam ennél a pendrive partíció titkosításnál, hogy lehet egy olyan hatása, hogy a pendrive egy partíciója csak a számítógéppel érhető el...
Tehát a pendrive vigyáz a gépre a gép vigyáz a pendrive-ra :) Persze, ha mindkettőt egyszerre lopják, akkor minden megvan nekik :( Mondjuk ez a gyenge pont. De a pendrive-ot zsebre lehet vágni... :-o
És akkor még ott vannak az ötletek a titkosított swap-ról és a többi hozzászólás :-) itt ...
- A hozzászóláshoz be kell jelentkezni
A megoldás, be kell betonozni a pendriveot.
- A hozzászóláshoz be kell jelentkezni
"hogy valósítsam meg a felhasználói interackiót gdm bejelentkezés kezelőnél." - A pendrive-t, ami a /home feloldásához szükséges kulcsot tartalmazza titkosítod szintén dm-crypt+luks párossal, de ebben az esetben jelszót használsz. Ezután pam-mount-tal meg lehet oldani, hogy a bejelentkezéshez megadott jelszót használja (use_first_pass) a pendrive felcsatolásához. Miután az usbkulcs fel van csatolva, jöhet a /home. Ezt célszerű úgy megoldani, hogy a /home volume-t a pam_mount.conf-ban a pendrive után definiálod, tehát mire az futtatásra kerül, már elérhető a kulcs is. Ez elméletben működik, gyakorlatban nem próbáltam. (A pam-mount-ot igen, de konkrétan ezt a felállást nem.)
Ennek ellenére én laptop-on a "sima" pam_mount-os egy faktoros (jelszavas) titkosítást készülök megvalósítani (nagyjából így), míg otthon - ahol a gép bejelentkezett felhasználó nélkül is el kell, hogy érje a /home-t samba, nfs, stb. miatt - jöhetne szóba a kulcs+jelszó, de azt meg csak úgy tudnám a jelenlegi tudásommal megoldani, hogy a bootolás közben kérje be a jelszót, ami engem speciel nem zavar, de lehet, hogy mást igen. Jelenleg egyébként "csak" jelszavas védelem alatt állnak a partíciók, de pl a backup partíció kulcsa, a /home-on van, amit jelszóval fel kell oldjak, hogy hozzáférhető legyen. Ez kb. a pendrive-os megoldásnak felel meg annyi különbséggel, hogy a kulcsot tartalmazó volume nem mobilis.
- A hozzászóláshoz be kell jelentkezni
Nem rossz ;)
- A hozzászóláshoz be kell jelentkezni
Mégvalami.
"A dokumentum mindenkori aktuális verziója megtalálható a HupWikin." - Ez ebben a szent minutumban nem fedi a valóságot, pl. a cpmount2-vel foglalkozó rész teljes egészében hiányzik a HupWiki-s verzióból. Gondolom csak delay. :)
Továbbá a titkosított partíció létrehozására:
"cryptsetup -c aes-cbc-essiv:sha256 luksFormat /dev/hda5 /mnt/usb/pendrive/root.key" parancsot használod a linuxbox.hu-s cikkben, míg
"cryptsetup -c aes-cbc-essiv:sha256 --key-file /mnt/usb/pendrive/root.key luksFormat /dev/hda5" parancsot a HupWiki-s változatban. Nem vagyok 100%-ig biztos benne, de szerintem a második verzió nem helyes.
"--key-file" kapcsolóval csak luksOpen esetén specifikálod a kulcsot, luksFormat esetén "luksFormat device [key file]" a megfelelő formátum.
- A hozzászóláshoz be kell jelentkezni
Igen, csak delay...
És igen, tegnap este vettem észre a cikk bővítésekor, hogy a parancs hibásan volt megadva, és a "cryptsetup -c aes-cbc-essiv:sha256 luksFormat /dev/hda5 /mnt/usb/pendrive/root.key" a helyes megoldás.
Amint lesz egy kis időm javítom a hup wikit.
- A hozzászóláshoz be kell jelentkezni
Frissítve.
- A hozzászóláshoz be kell jelentkezni
Ha nem tudom felmountolni a cryptfs-t, akkor hogyan futtatok rajta fsck-t?
- A hozzászóláshoz be kell jelentkezni
fsck felcsatolt particíónál???
- A hozzászóláshoz be kell jelentkezni
kell egy
cryptsetup ... luksOpen ...
ekkor létrejön egy
/dev/mapper/
eszköz, és ezen az eszközön lehet fsck-zni.
- A hozzászóláshoz be kell jelentkezni
Üdv!
Az elérhető titkosító algoritmusok (AES, DES stb. )teljesítményében van valami eltérés? Én egy hasonló összeállítást csináltam (nem is tudom pontosan milyen kódolással) , egy nagyobb file le- vagy felmásolásakor 30-40%-ra megy fel a CPU usage, ha történetesen ketten-hárman egyszerre dolgoznak a titkosított köteten, simán 100%-on jár a proci, pedig nem gyenge gépről van szó.
Ez normális? Vagy csak én választottam lassú kódolást? Tervezek egy másik gépen ilyesmit, de ott LVM is lenne. Az mennyi procit fog enni? (tehát partíciók > LVM > cryptfs > filerendszer) Várhatok ettől normális sebességet?
Petya
- A hozzászóláshoz be kell jelentkezni
Üdvözletem!
Én még most ismerkedek a témával. Találtam a neten Ubuntu-hoz való leírást, igaz én openSuse rendszert használok.
Az eredeti leírást itt találja akit érdekel:
http://sugo.ubuntu.hu/10.04/html/serverguide/hu/ecryptfs.html
Ezt szeretném megvalósítani a saját rendszeremen. Ami azt illeti sikerült is, de apró pici hiba van.
Megcsináltam a leírtak alapján a .ertyptfsrc fájlt saját adataimnak megfelelően.
Létrehoztam a külön jelszófájlt pendrive-ra. Fájlrendszere Ext3, egyenlőre nem titkosított.
Megcsináltam az fstab beállítását is, természetesen saját kívánalmaknak megfelelően, hogy jó legyen.
A gép indításakor a pendrive ha csatlakozutatva van, a titkosított fájlrendszer rendben csatolásra kerül. Ez volt a cél, ez tökéletesen működik. A hiba ott van, ha a pendrive nincs csatlakoztatva és úgy próbálok indítani rendszert. Ekkor megáll a betöltés, mert nem találja a megadott fájlrendszert és nem tudja azt csatolni.
Gyanítom, hogy az fstab beállításaiban kellene valamit módosítani, hogy ha nincs csatlakoztatva a pendrive, akkor átlépje az egész folyamatot és befejezze a rendszer betöltését a titkosított tartalom csatolása nélkül.
Ezt hogyan tudnám megvalósítani? Az elképzelés jól működik ennyi hibával. Nekem egyenlőre ennyire lenne szükségem, annyira nem vagyok még profi a dologban.
Ha a fent linkelt oldal nem lenne elérhető, akkor itt a lényeg:
A .ecryptfsrc létrehozva a /root mappában, tartalma:
key=passphrase:passphrase_passwd_file=/mnt/usb/jelszófájl.txt
ecryptfs_sig=5826dd62cf81c615
ecryptfs_cipher=aes
ecryptfs_key_bytes=16
ecryptfs_passthrough=n
ecryptfs_enable_filename_crypto=n
A jelszófájl létrehozva a pendrive-on, tartalma:
passphrase_passwd=jelszó
Fstab módosítások:
/dev/sdb1 /mnt/usb ext3 ro 0 0
/srv /srv ecryptfs defaults 0 0
Előre is köszönöm a segítségeket!
- A hozzászóláshoz be kell jelentkezni