Különféle titkosítási rendszerek teljesítményének összehasonlítása linux alatt. Adattitkosítás Linux Luks titkosításban

  • Dátum: 14.05.2021

Ebben a cikkben elmondom, hogyan hozhat létre rejtett titkosítási tárolót a szabványos Linux operációs rendszer eszközeivel (LUKS és cryptsetup). A LUKS beépített funkciói (például külső fejlécek használata és valós adatok elhelyezése egy adott eltolásnál) lehetővé teszik a felhasználó számára, hogy hozzáférjen egy meglévő tárolóban rejtett adatokhoz, valamint megtagadja az ilyen adatok létezését.

UPD: Mivel ez a bejegyzés egy hónapja készült el, el sem tudtam képzelni a projekt ilyen furcsa és váratlan halálát. Nos, igen, lehet, hogy még nem halt ki teljesen, lássuk... Ennek ellenére ebben a szövegben úgy döntöttem, hogy minden utalást a TrueCrypt-re úgy hagyok, ahogy van.

Mi az a „valószínű tagadás”?

Erről a fogalomról nagyon hosszú és részletes leírást találhat a Wikipédián: http://en.wikipedia.org/wiki/Plausible_deniability. Ez röviden annyit jelent, hogy rendelkezhet (vagy tehetett volna valamit), aminek a jelenlétét senki sem gyanítja, nem tudja bizonyítani (hacsak persze maga nem ismeri be). Utána pedig letagadhatod ennek a valaminek a létezését (vagy megtételének tényét), ha valaki vádolni akar, hiszen (ismétlem) ez a tény bizonyíthatatlan. Nos, ha például egy gyerek fenéken rúgná az öccsét, és a testvér elmenne a szüleihez igazat keresni, akkor ebben az esetben mi történne?

Hát... Mintha mi sem történne. Mert ez a csávó visszautasítja, a szülei pedig formálisan nem fogják kézen fogni (mert egyrészt hülye tanúk sincsenek, másrészt az öccs tudja játszani a piszkos játékát). Így senkit sem büntetnek meg. Nos, vagy mindkettőt megbüntetik minden tűzoltóért. Ez csak egy példa volt arra, hogy egy agresszióra hajlamos gyermek kihasználja a valószínű tagadás lehetőségét. De te és én természetesen fehérek és bolyhosak vagyunk, és csak azért fogunk rejtett konténereket használni, hogy megvédjük személyes adatainkat a rosszfiúktól. Így jobb? Persze, hogy „mi a „jó” és mi a „rossz”” az egy külön kérdés... De inkább a lényeg.

A megvalósítás általános ötlete

Tegyük fel, hogy fontos adatokat szeretnénk tárolni egy titkosított fájlban. Általában valamilyen kriptográfiai védelmi programot fogunk használni, amely elvégzi helyettünk az összes piszkos munkát. Előfordulhat, hogy a titkosított fájlt virtuális lemezként kezelhetjük, és ez jelentősen csökkenti a lehetséges jelöltek számát. Van azonban egy "de". Szinte minden ilyen program úgy működik egy fájllal, mint egy titkosított adattal. Hadd magyarázzam el: a felhasználó általában rendelkezik egy jelszó (és talán néhány "tartalék"). minden adatok a tárolóban. Ez azt jelenti, hogy van legalább egy gyenge hivatkozás: a tároló jelszava. Nem akarom megemlíteni, hogy a jelszónak titkosításilag erősnek kell lennie, mert ez egy általános igazság. Arra gondolok, hogy ha a felhasználó valamilyen okból (pl. kényszer hatására) feladja ezt a jelszót, akkor minden adat beolvasásra kerül. És ez a tény szomorúnak és teljesen helytelennek tűnik számomra...

Általában azonban van remény. :) Például van egy olyan program, mint a , ami elég okos. A felhasználó egy fájlban két konténert hozhat létre: az egyik egy „dummy” bizonyos számú „tiltott”, de viszonylag biztonságos fájllal, a másik pedig egy valódi, olyan adatokkal, amelyeket semmilyen körülmények között nem szabad nyilvánosságra hozni. Így a TrueCrypt két különböző jelszót kér, amikor a felhasználó ilyen „kettős” tárolót szeretne létrehozni. Működés közben a felhasználó csak egy jelszót ír be az "igazi" részhez, és azzal dolgozik. Abban az esetben, ha külső körülmények nyomására a felhasználó kénytelen harmadik félnek felfedni a konténer tartalmát, egyszerűen más jelszót ír be, és a TrueCrypt megnyitja a "hamisítványt". Hangsúlyozom (és ez nagyon fontos), hogy a rejtett rész meglétét nem lehet bizonyítani, ha a kutató nem ismeri a hozzá tartozó jelszót.

És most gyorsan kitaláljuk, hogyan működik ez a szemét ... Valójában minden nagyon egyszerű. A szoftver a konténerfájlt két (általában nem egyenlő) részre osztja. Az első rész, amely viszonylag kicsi, speciálisan előkészített adatokat tartalmaz; a második az igazi. Ennek megfelelően a programnak képesnek kell lennie arra, hogy két különböző részhez két különböző fejléccel (konfigurációval) működjön, és a felhasználó által megadott jelszó függvényében ki kell tudnia választani, hogy melyik részt kívánja visszafejteni. És azt kell mondanom, hogy nem ez a legtriviálisabb része a munkának. Nos, egyszerűen azért, mert "hivatalosan" csak egy "hamis" konfiguráció legyen látható: ha a tárolónak szabványos fejléce van, az csak "hamis" fejléc legyen; ha a konténer paraméterei külön konfigurációban vannak tárolva, akkor ennek a konfigurációnak csak a "hamis" rész visszafejtését kell lehetővé tennie. A "hamis" rész megfejtése után pedig egyetlen utalás sem lehet az igazi jelenlétére. Teljesen függetlennek kell lenniük. Ezenkívül a „hamis” rész kinyitásakor a szoftvernek a kriptotároló teljes kapacitását kell mutatnia, még akkor is, ha ennek a résznek a térfogata sokkal kisebb.

Szóval mi van a LUKS-szal?

Nos, van egy jó hírünk és… ööö… még több jó hírünk.

A jó hír az, hogy a cryptsetup képes visszafejteni és felcsatolni a TrueCrypt által készített köteteket. Csak olvasható, de ez nonszensz. Mivel van jobb hír is. Nevezetesen, hogy kizárólag a segítségével tudunk "rejtett" konténereket létrehozni. Ezenkívül ez a segédprogram lehetővé teszi tetszőleges számú "rejtett" alkatrész létrehozását. Természetesen ésszerű keretek között. És itt van, hogyan lehet ezt megtenni.

De mielőtt folytatná,

ÓRIÁSI KÖRÖS ijesztő FIGYELEM!!!

  • Az alábbiakban leírtak visszafordíthatatlan adatvesztést okozhatnak.
  • Az Ön országában az erős kriptográfia használata tilos lehet, így előfordulhat, hogy nem valós információkért kerül börtönbe, hanem egyszerűen azért, mert van egy titkosítási konténer, amelyet a csavaron találnak.
  • A kriptográfia megvédheti adatait, de nem védi meg a kínzástól. Egy rejtett tároló segíthet megőrizni az értékes információkat, de nem tagadhatja meg jelenlétét árulás vagy feljelentés esetén.
  • Azok a srácok, akiket érdekelnek a titkosított adataid, nem biztos, hogy olyan buták, mint amire számítottál. Még ha nem is tudják bizonyítani a konténer rejtett részének jelenlétét, egy cellába zárhatják a tapasztalt bûnözõkkel, és néhány napon belül emlékezni fog az összes rejtett adat jelszavára.
  • Ha vannak közeli embereid (barátnő/barát, rokonok, barátok), ők is ugyanígy a kemény nyomás célpontjává válhatnak. És ez minden bizonnyal segít abban, hogy általában sokkal gyorsabban emlékezzen mindenre, beleértve azt is, amit nem is tud.

Ezért jobb, ha kétszer is meggondolja, mennyi információ értékesebb, mint az ön és a szerettei élete. És készíts biztonsági másolatot. Csak abban az esetben.

Tehát a man cryptsetup sok érdekes részletet képes elmondani a segédprogram parancssori paramétereiről. Nos, például nézzük a --header opciót:

Hát rendben. Ez azt jelenti, hogy egy adatkötet tele van véletlenszerű szeméttel, értelmes aláírások nélkül. Ennek az opciónak a leírása egy kicsit több információt, óvintézkedéseket és figyelmeztetéseket tartalmaz, de az alsó sorban csak ez szükséges. Ennek ellenére nagyon ajánlom ennek a kiváló útmutatónak az elolvasását.

Egy másik nagyon hasznos lehetőség a --align-payload , amely lehetővé teszi, hogy a valós adatokat egy bizonyos eltolásra helyezze el a kötet elejéhez képest:

És ez azért is klassz, mert most már szabadon áthelyezhetjük adatainkat a kötet bármely részére. Érted az ötletet, igaz?

  1. A kötetet inicializáljuk a titkosításhoz: teljesen felülírjuk véletlenszerű adatokkal.
  2. Készítünk egy „hivatalos” titkosított kötetet, és egy kicsit ledobjuk fertőzött varese, feltekeredett muzla, pron hasznos ingyenes szoftverek, amatőr rockzenekar felvételei, szerelmes filmek stb., általában olyasmi, amiért legfeljebb két év próbaidőt kap.
  3. A fenti ezoterikus kriptabeállítási lehetőségeket felhasználva létrehozunk egy rejtett kötetet (a „hivataloson” belül), és ennek címét külső médiára visszük át, ahol valóban veszélyes információkat tárolhatunk (például óvodai fotóit vagy világhódító terveit).

Valójában, emberek, ez minden. Nincs varázslat. Természetesen a "hivatalos" titkosított lemezt nem lehet telítettségre megtölteni azon egyszerű oknál fogva, hogy a terület egy része egy rejtett tárolónak van átadva. És ahogy az elején mondtam, ha akarod, több rejtett meghajtót is létrehozhatsz ugyanazon logika szerint.

Itt ... És ha még mindig szüksége van a részletekre, akkor különösen az Ön számára -

Végigjátszás

Figyelem!

A következő parancsok megsemmisítik az adatait, ha az agy bekapcsolása nélkül hajtják végre őket. Az elveszett információkat nem lehet visszaállítani, mert az olyan segédprogramok, mint a dd, alacsony szinten (vagyis a fájlrendszer szintje alatt) működnek. Ezért a változtatások visszaállítása vagy hatásuk visszavonása nem lehetséges, még akkor sem, ha azonnal megszakítja az indítást.

Röviden: ne tegye ezt, hacsak nem tud értelmes magyarázatot találni arra, hogy az egyes lépések hogyan kapcsolódnak a céljaihoz. És készíts biztonsági másolatot. Most.

Tegyük fel, hogy több partícióval rendelkező eszközünk van. Legyen ez például a /dev/sdb. És legyen a /dev/sdb1 egy viszonylag kicsi (8 GB) titkosításra szánt partíció. 5-3-ra osztjuk, ahol az 5 GB-os rész lesz "hivatalos", a 3 GB-os pedig rejtett. Tételezzük fel azt is, hogy a titkosított lemez kulcsát az /etc/keys könyvtárban, a rejtett konténer fejlécét pedig egy külső USB meghajtón fogjuk megőrizni, amit a /media/user/ExtUSBStick mappába fogunk csatolni. Feltételezem, hogy már tudja, milyen jogosultságokat kell beállítania a kulcstárolóban, hogyan kell beállítani az encfs-t / ecryptfs-t a bizalmas adatok biztonságos tárolására nem biztonságos eszközökön, és azt is, hogy van értelme valódi titkos kulcsokat másolni, és több, egymástól földrajzilag elválasztott széfben tárolni.

Nos, oké, lekötöm a morgolódást, és rátérek a kérdés lényegére.

    Eszköz inicializálása /dev/sdb1:

    Dd if=/dev/urandom of=/dev/sdb1 bs=16M

    A titkosított kötethez kulcsot készítünk. 512 bit (64 bájt) a tetőn keresztül:

    Dd if=/dev/urandom bs=64 count=1 >/etc/keys/secret.key 2>/dev/null

    A kötet titkosítása az újonnan létrehozott kulccsal:

    Cryptsetup luksFormat /dev/sdb1 /etc/keys/secret.key

    Nyissa meg a titkosított eszközt, és konfigurálja a leképezést a titkos adatokban:

    Cryptsetup luksOpen --key-file /etc/keys/secret.key \ /dev/sdb1 titkos adatok

    Hozzon létre egy fájlrendszert a titkosított köteten (például btrfs):

    Mkfs.btrfs -L SecretData /dev/mapper/secretdata

    ... és szereld fel:

    Csatlakoztassa a /dev/mapper/secretdata /var/secretdata/

    Az 5 giga korlátot szem előtt tartva állítsa be a részmennyiségi kvótát:

    Btrfs kvóta engedélyezése /var/secretdata/

    Mivel a btrfs kvóták csak az alkötetekre vonatkoznak, hozzunk létre egy ilyet:

    brfs alkötet létrehozása /var/secretdata/workingvolume

    ... és alkalmazza rá a megadott kvótát (vegye figyelembe, hogy a btrfs alkötetek normál fájlrendszerként is felcsatolhatók, így kényelmesebb lehet, ha később ezt az alkötetet csatolja a teljes fs helyett):

    btrfs qgroup limit 5G /var/secretdata/workingvolume

    Néhány adattal kitöltjük:

    debootstrap --variant=buildd tesztelés /var/secretdata/workingvolume

    Ennyi, ezt a részt most elfelejtheted:

    Umount /var/secretdata cryptsetup luks A titkos adatok bezárása

    Most hozzunk létre egy "halat" a fejléchez, és tegyünk bele véletlenszerű szemetet:

    Dd if=/dev/urandom of=/media/user/ExtUSBStick/hidden.head bs=4M count=1

    És most jön el az a pillanat, amikor elkezdődik az igazi varázslat. (Mi? Mondtam, hogy nincs varázslat? Tehát hazudtam.) Ugyanazt a titkos kulcsot használjuk, de nem teljes egészében, hanem csak a felét (32 bájtos eltolástól). A fennmaradó 256 véletlenszerű bit azonban képes jó kulcsot készíteni. Ezután szétválasztjuk a fejlécet, és a flash meghajtóra helyezzük. Végül elmondjuk a cryptsetup "y"-nek, hogy a rejtett tárolónkat 5 GB-tal (azaz 10485760 512 bájtos blokkokkal) szeretnénk eltolni a kötet elejétől:

    Cryptsetup --keyfile-offset 32> --header /media/user/ExtUSBStick/hidden.head \ --align-payload 10485760 luksFormat /dev/sdb1 /etc/keys/secret.key

    Igen, ez ilyen egyszerű. Most nyissunk meg egy új titkosított eszközt:

    Cryptsetup luksOpen --key-file /etc/keys/secret.key --keyfile-offset 32\ --header /media/user/ExtUSBStick/hidden.head /dev/sdb1 realsecretdata

    Dobjunk tetszőleges fs-t:

    Mkfs.btrfs /dev/mapper/realsecretdata

Hasznos Linkek

Azok számára, akik egy kicsit többet szeretnének tudni, íme néhány további információforrás:

  • lemeztitkosítás, általános információk a lemeztitkosításról: https://wiki.archlinux.org/index.php/Disk_encryption
  • Titkosítás megtagadva, a fogalom valamivel szűkebb, mint a "valószínű tagadhatóság", csak a kriptográfia területére vonatkozik: https://en.wikipedia.org/wiki/Deniable_encryption
  • TrueCrypt

Napjainkban a fontos adatok tiszta helyen való tárolása veszélyesebbé vált, mint valaha. És még csak nem is az állami megfigyelés miatt (ha akarják, találnak majd panaszt, stb.), hanem azok miatt, akik el akarják lopni ezeket az adatokat. Elvileg sok módszer létezik az információk védelmére, de a cikk pontosan leírja a kriptográfiai eszközöket.


Más operációs rendszerekkel ellentétben a Linux számos eszközzel rendelkezik az információk kriptográfiai védelmére – a levelezési levelezés titkosításától a fájlok és blokkolóeszközök titkosításáig. Érdeklődünk a fájlrendszerek, fájlok és blokkeszközök szintjén történő titkosítás iránt. Először is érdemes megérteni, mi a különbség. A fájlrendszer szintű titkosítás egy réteget foglal magában az alapul szolgáló fájlrendszer (kivéve persze, ha maga a fájlrendszer támogatja a titkosítást) és a felhasználó között.

Előny ebből a típusból titkosítás – hogy az összes felhasználó kulcsa eltérő. Hátránya, hogy ha engedélyezzük a fájlnév-titkosítást, az érvényes név hossza csökken, ráadásul a felhasználó a fájlt más helyre mentheti a lemezen, ami automatikusan kiegyenlíti az előnyt. És még valami – még ha a névtitkosítás engedélyezve is van, az időbélyegek változatlanok maradnak. A blokkeszközök titkosítása alacsonyabb szinten, a fájlrendszer alatt történik. Ugyanakkor maga a fájlrendszer természetesen nem tudja, hogy titkosított köteten található.

Ennek a módszernek az előnyei ellentétesek az előző hátrányaival. Hátránya, hogy minden rendszerindításkor/csatoláskor jelszót kell megadni. A második hátrány az, hogy ha futás közben egy támadó hozzáfér a kripto-
teiner, minden - írd elpazarolt. Pontosan ez a védelem az offline támadások ellen. Ezenkívül az esetek túlnyomó többségében, amikor egy kriptotárolót a felhőbe ment, teljesen újra fel kell töltenie.

A cikk a következő titkosítási módszerek konfigurációját írja le:
dm-crypt/LUKS- cryptocontainer létrehozása eszközleképező és CryptoAPI kernellel;
eCryptfs- titkosítás fájlrendszerek szintjén;
EncFS- hasonló a fentiekhez, de nem igényel kernelmodulok betöltését.

DM-CRYPT/LUKS
Kétféle dm-crypt beállítás létezik – sima és LUKS. A különbség az, hogy a LUKS használata esetén a titkosítási kötet elején metaadatok találhatók, amelyek lehetővé teszik több kulcs használatát és megváltoztatását. Ugyanakkor egy ilyen fejléc jelenléte bizonyos esetekben önmagában is kompromittáló – azonban a legtöbb ilyen esetben egy nagy entrópiával rendelkező terület is kompromittáló. Egyszerű dm-crypt beállítása kulcsfájllal és jelmondattal Nézzük meg, hogyan állíthatunk be egy egyszerű dm-crypt kötet kombinációját egy LUKS-tárolóban található kulcsfájllal titkosítva. Először is érdemes eldönteni, hogy a szakaszok pontosan hogyan lesznek elhelyezve. Három fő lehetőség van:
csak egy kriptokötet;
először egy kriptokötet, majd a tetejére LVM;
először kriptokötet, majd RAID, majd LVM.

És mindenféle kombináció. Próbáljuk meg a második lehetőséget. Először is hozzunk létre egy LUKS-tárolót a kulcsfájl tárolására, hogy ezt a fájlt a jelszóval együtt használhassuk. Ebben az esetben a sima dm-crypttel titkosított kötet kriptográfiai elemzésének valószínűsége csökken:

# dd if=/dev/zero of=/root/key.luks bs=512 count=2057

# cryptsetup --align-payload=1 luks Format /root/key.luks

# cryptsetup luks Nyissa meg a /root/key.luks kriptokulcsot

# dd if=/dev/urandom of=/dev/mapper/cryptokey

Az első parancs előkészíti a tárolófájlt, a második létrehozza ezt a tárolót, a harmadik csatlakozik, a negyedik kulcsinformációkat generál. Érdemes megjegyezni, hogy a --align-payload=1 opcióra azért van szükség, hogy a LUKS metaadatok mérete ne 4096 512 bájtos blokk legyen, hanem csak 2056. Így 512 bájt marad a tényleges kulcsinformációhoz.
Ezután folytatjuk a kriptotóma létrehozását. Ezen a ponton opcionálisan megtöltheti a lemezt pszeudo-véletlen adatokkal, hogy megnehezítse a kriptoanalízist, ha van ilyen. Ezután már létrehozhat egy kriptotómot. Ennek parancsa a következő (persze más esetekben az azonosítók eltérhetnek, ezért vigyázni kell):

# cryptsetup --cipher=serpent-xts-plain64 --offset=0--key-file=/dev/mapper/cryptokey --key-size=512 open --type=plain/dev/disk/by-id/ ata-VBOX_HARDDISK_VB05eadebe-f25e8d59 crypto0


Ha szükséges, ismételje meg ugyanazt a parancsot más, titkosítást igénylő eszközökön. Ezután létrehozzuk az LVM-et a kriptotomokon és az FS-t rajta:

Hozzuk létre az /etc/initramfs-tools/hooks/cryptokeys fájlt a következő tartalommal (a szkript szolgáltatási része kimarad):

És az /etc/initramfs-tools/scripts/local-top/cryptokeys fájl (ismét a szolgáltatás része
vagy kimaradt):

# <...>

modprobe -b dm_crypt

míg! (/sbin/cryptsetup luks Nyissa meg az /etc/crypto/key .luks cryptokey

/dev/disk/by-id/ata-VBOX_HARDDISK_VB05eadebe-f25e8d59 crypto0

&& /sbin/cryptsetup plainOpen -- kulcs - file=/dev/mapper/cryptokey

/dev/disk/by-id/ata-VBOX_HARDDISK_VBc2414841-cfeccde5 crypto1

&& /sbin/cryptsetup luksA titkosítási kulcs bezárása

) ; csináld

echo „Próbáld újra . . . ”

Kész

Ennek a két fájlnak futtathatónak kell lennie. Ezután létrehozunk egy initrd-t:

# update-initramfs -u -k all -v

A következő újraindításkor a rendszer jelszót kér a LUKS tárolóhoz. Sima dm-crypt használata esetén van egy másik lehetőség - egy közös alsó réteg, amely lehetővé teszi olyasmiket, mint a TrueCrypt rejtett kötetek. Egyszerűbb példát mondani:

# cryptsetup --cipher=serpent-xts-plain64 --offset=0--size=2097152 --shared open --type=plain/dev/disk/by-id/ata-VBOX_HARDDISK_VBcda8398f-f1f1deec crypto

# cryptsetup --cipher=serpent-xts-plain64 --offset=2097152--size=2097152 --shared open --type=plain/dev/disk/by-id/ata-VBOX_HARDDISK_VBcda8398f-f1f1deec crypto_shared

A méret és az eltolás 512 bájtos blokkban van megadva.


A LUKS speciális funkciói
Nézzük meg a LUKS konténerek használatának speciális funkcióit is. Ide tartozik a kulcscsere. Erre akkor van szükség, ha újrakulcsolási szabályzatot sért vagy létrehoz. Ennek első lépése a tárolófejléc biztonsági mentése. Zuhanok
normál esetben a kulcscsere után megsemmisülhet. Ezt természetesen titkosítatlan partíción tesszük:

Végül adjon hozzá egy új kulcsot a rendszerhez:

Fontolja meg a LUKS-kötetek visszaállításának eljárását. A legegyszerűbb lehetőség természetesen az, ha van a fejléc másolata. Ebben az esetben csak egy parancsra van szükség a visszaállításhoz:

A leghosszabb folyamatos sor a főkulcs lesz. Egy titkosítatlan köteten lévő fájlba kell másolni, majd bináris formátumba konvertálni (előtte győződjön meg arról, hogy adott fájl nincsenek
sorvégi karakterek):

ENCFS
Nézzük meg, hogyan kell beállítani az EncFS-t, hogy bejelentkezéskor automatikusan csatlakozzon. Először telepítsük a szükséges csomagokat:

Szakértői módban történő beállításkor számos kérdést feltesznek: titkosítás típusa (csak AES és Blowfish elérhető), kulcsméret, blokkméret, fájlnevek titkosítása - blokk titkosítás (amely teljesen elrejti a fájl nevét, beleértve a hosszt is ), streaming (amely a lehető legközelebbi hosszúsággal titkosít, ami néha kényelmes, ha a nevek túl hosszúak, és blokk-rejtjel használatakor meglehetősen nagy a valószínűsége annak, hogy túllépi a megengedett maximális hosszúságot), vagy teljesen hiányzik ... a végén egy jelszót kell kérni, annak meg kell egyeznie a belépéshez használtal, különben nem fog működni az automount.

Ezután szerkesztenie kell az /etc/security/pam_encfs.conf fájlt:

És az /etc/fuse.conf fájl:

És adja hozzá a felhasználót a biztosítékcsoporthoz:

$ sudo usermod -a -G biztosíték $USER

Kijelentkezés-bejelentkezés után a privát telefonkönyv személyes adatok tárolására használható. Érdemes azonban megjegyezni, hogy az audit során feltártak néhány (elég komoly) biztonsági problémát, amelyek miatt ezt a rendszert Nagyon nem ajánlott igazán fontos adatok tárolására használni.

TITKOSÍTÁSOK
Ismeretes, hogy az eCryptFS-t az Ubuntu alapértelmezett saját könyvtárvédelmi eszközként használja. Lássuk, hogyan működik – hozzunk létre egy titkosított könyvtárat manuálisan. Csomagok telepítése:

Az eCryptFS létrehozása

És csatolja az FS-t (az első felcsatolás során minden szükséges metaadat létrejön):

$ sudo mount -t ecryptfs /home/rom/ . titkos/otthon/rom/titok

Jelszót fog kérni (csak egyszer, a re-entry nem valósul meg, ami nem tűnik jó megoldásnak, tekintve, hogy hosszúnak kell lennie), majd kéri a titkosítás típusát (AES, Blowfish, 3DES, Twofish , CAST6 és CAST5), méretkulcs, felteszik a kérdést, hogy engedélyezzük-e vagy tiltsuk le a titkosítatlan fájlokat egy olyan könyvtárban, ahol titkosítottak, titkosítsuk-e a fájlneveket... és a végén megkérdezi, hogy valóban szeretnénk-e felcsatolni és menteni. az aláírás egy adott fájlhoz. A kérdés nem olyan hülye, mint amilyennek elsőre tűnik: ebben a szoftverben aláírás hiányában nem lehet megkülönböztetni a helyes jelszót a helytelentől.

A felhasználó saját könyvtárának titkosítása

Az első futtatás során előfordulhat, hogy több folyamatot le kell állítania. A titkosítást követően azonnal be kell jelentkeznie felhasználóként, és meg kell írnia vagy ki kell nyomtatnia a titkosításhoz generált és a felhasználó jelszavával védett jelszót. Ez szükséges a helyreállításhoz vészhelyzet esetén.


Ne felejtse el a jelszavas figyelmeztetést

Lássuk, hogyan lehet visszaállítani. Tételezzük fel, hogy a jelszó nincs rögzítve, és a helyreállítás Live CD-ről érkezik. Feltételezzük, hogy az FS fel van szerelve. Lépjen a home/.ecryptfs/rom/.ecryptfs könyvtárba, és írja be a következő parancsot:

dm-verify
A dm-verify modul a blokkeszközök integritásának ellenőrzésére szolgál. Az ellenőrzést hash-fa segítségével végezzük, ahol a „levelek” a blokkok hash összegei, az „ágak” pedig a „levelek” halmazainak hash összegei. Így egy blokkeszköz (legyen az partíció vagy lemez) ellenőrzéséhez elegendő csak egy ellenőrző összeget ellenőrizni.
Ezt a mechanizmust (a digitális aláírással együtt) egyes Android-eszközök a módosítások elleni védelemre használják rendszerpartíciók, valamint a Google Chromium OS rendszerben.

KÖVETKEZTETÉS
A Linux valóban sok eszközt tartalmaz a kriptográfiai információk védelmére. A leírt három eszköz közül legalább egy jelen van minden modernben Linux disztribúciók. De mit válasszunk?
dm-crypt/LUKS olyan esetekben kell használni, amikor és mikor lehetséges egy titkosított kötet gyors letiltása biztonsági mentések vagy nincs szükség rájuk, vagy más módon vannak besorolva. Ebben az esetben ez a megoldás több mint hatékony, különös tekintettel arra, hogy tetszőleges beágyazás és típus (például AES-Twofish-AES) lépcsőzetes titkosítására van lehetőség - ez egy igazi paradicsom
a paranoiásnak.
eCryptFS alkalmas olyan esetekben, amikor titkosított adatokat kell mentenie valahova - például a felhőbe. Meglehetősen erős titkosítást biztosít (bár az alapértelmezett 128 bites változat két bittel csökkentheti a biztonságot), és átlátható a végfelhasználó számára.
EncFS de - egy öregember körülbelül egy évtizeddel ezelőtt, még régebbi művek alapján. Jelenleg az esetleges biztonsági rések miatt nem javasolt a használata, de többplatformos eszközként használható a felhőkben lévő nem érzékeny adatok védelmére.

Ha ilyen eszközöket kell használnia, mindig emlékezzen arra, hogy a védelemnek átfogónak kell lennie.

Bevezetés

Az adatok titkosított formában történő tárolása nagyszerű módja annak, hogy megvédjük az információkat, hogy azok ne jussanak el a támadóhoz. A kriptográfiai rendszereket a szellemi tulajdon, az üzleti titkok vagy a személyes adatok védelmére fejlesztették ki. Különféle formákban készülhetnek, különböző szintű funkcionalitást kínálnak, és tetszőleges számú opciót tartalmazhatnak, hogy megfeleljenek a működési környezetek és környezetek széles skálájának. Ma a korszerű kriptográfiai módszerek, algoritmusok és megoldások száma sokkal nagyobb, mint korábban. A fejlesztés minősége pedig sokkal jobb. Sőt, számos működőképes nyílt forráskódú megoldás létezik a piacon, amelyek lehetővé teszik a megfelelő szintű védelem elérését anélkül, hogy nagy összegeket kellene elkölteni.

2005 decemberében a Ponemon Intézet felmérést végzett különböző információbiztonsági szakemberek körében a titkosítással és az adatvédelemmel kapcsolatban. A 6298 válaszadó közül csak a válaszadók 4 százaléka használt vállalati szintű titkosítást. Ugyanez a felmérés három fő okot tárt fel a hivatalos titkosítási szabályokkal szembeni határozott ellenállásra:

  • A megkérdezettek 69%-a teljesítményproblémákat említett;
  • A válaszadók 44%-a említett végrehajtási nehézségeket;
  • A válaszadók 25%-a beszélt a kriptográfiai algoritmusok megvalósításának magas költségeiről.

A szervezetekre sok országban számos nyomás nehezedik munkájuk „átláthatóságának” növelése érdekében. Másrészt viszont törvényi felelősségük van azért, hogy ne biztosítsák a bizalmas információk biztonságát. Ez különösen az Egyesült Államokban működő DSW cipőboltok esetében volt így.

Az Egyesült Államok Szövetségi Kereskedelmi Bizottsága pert indított a DSW ellen, amely megállapította, hogy nem biztosított megfelelő szintű információvédelmet, és nem tett megfelelő intézkedéseket az adatokhoz való hozzáférés korlátozására, valamint a hálózati kapcsolatok rossz védelmére. bolti és irodai számítógépek között. A DSW esetében körülbelül 1,4 millió hitelkártya és körülbelül 96 000 csekkszámla állt potenciálisan a bűnözők rendelkezésére. A cég és az FTC közötti megállapodások megkötése előtt pedig ezeket a számlákat már illegálisan használták.

Napjainkban minden eddiginél jobban elérhetők az adatok titkosítására szolgáló szoftverek és mérnöki megoldások. Intelligens kártyák helyett egyre gyakrabban használják a napról napra olcsóbb USB kulcsot. Utóbbit viszont gyakran meg lehet találni, mert a legtöbb laptop tartalmaz intelligenskártya-olvasót.

A fogyasztók egyre gyakrabban kezdenek gondolkodni a személyes adatok, tulajdonosi adatok, hitelkártyaszámok ellopásával járó veszélyekről. Ezeket a félelmeket pedig csak az ilyen értékes adatokkal megbízott intézményektől származó ellopott információk tömeges eladásairól szóló jelentések táplálják.

A fogyasztók is kezdik felismerni, hogy nemcsak online, hanem offline is fontos a személyes adatok védelme. Végül is az adataihoz való nem kívánt hozzáférés nem mindig az interneten keresztül történik. Ez a probléma különösen fontos azok számára, akiknek a védelem nélküli laptopja vagy a szervizszemélyzet kezébe kerülhet a konfiguráció megváltoztatása érdekében, vagy a szervizbe kerülhet javításra.

Technikai titkosítási problémák

A titkosítási funkciók elengedhetetlenek minden modern többfelhasználós számítógépes rendszerben, ahol az adatok, folyamatok és felhasználói információk logikailag el vannak választva. A felhasználó hitelesítéséhez egy ilyen rendszerben a bejelentkezési neveket és a jelszavakat kivonatolja, és összehasonlítja a rendszerben már található kivonatokkal (vagy a hash segítségével dekódolják a munkamenetkulcsot, amelyet ezután ellenőriznek az érvényesség szempontjából). A személyes adatok jogosulatlan megtekintésének megakadályozása érdekében egyes fájlok vagy teljes szakaszok titkosított tárolókban tárolhatók. A hálózati protokollok, például az SSL\TLS és az IPSec pedig lehetővé teszik a különféle eszközök (/dev/random, /dev/urandom stb.) kriptográfiai védelmének megerősítését a kernellel működő moduláris algoritmusok segítségével. operációs rendszer.

Bármely lemeztitkosítási technológia célja, hogy megvédje a személyes adatokhoz való nem kívánt hozzáférést, és csökkentse a szellemi tulajdon elvesztését, amely egy fizikai eszköz illegális hozzáféréséből vagy ellopásából ered. Műtőszoba Linux rendszer a kernel 2.6.4-es verziójával bevezetett egy fejlett kriptográfiai infrastruktúrát, amely egyszerűen és biztonságosan védi a személyes adatokat számos szinten szoftver. Egész szabványok léteznek az alacsony szinten titkosított adatok tárolására, mint például a Linux Unified Key Setup (LUKS) és a felhasználói szintű megvalósítások, mint például az EncFS és a CryptoFS fájlrendszerek, amelyek viszont a Fast Userspace fájlrendszeren (FUSE) alapulnak. ) Linux alatt. Természetesen minden kriptográfiai rendszer csak annyira ellenáll a feltöréseknek, mint a jelszavai és a hozzáférési kulcsai. Összességében három fő szinten alkalmazzák a titkosítási technológiákat:

  • a fájlok szintje és a fájlrendszer (fájlonkénti titkosítás, konténer fájlokkal);
  • alacsony blokkszint (fájlrendszerű tároló);
  • hardverszint (speciális kriptográfiai eszközök).

A fájlszintű titkosítás egy nagyon egyszerű technika, amelyet gyakran használnak a fájlmegosztáshoz. A titkosítást eseti alapon alkalmazzuk, ami praktikus ésszerű számú fájl átviteléhez. A többfelhasználós fájlrendszerek esetében kulcskezelési probléma adódik, mivel a különböző felhasználók mappáit és fájljait más-más kulccsal titkosítják. Természetesen használhat egy kulcsot, de akkor kapunk egy olyan technológiát, amely hasonlít a lemeztitkosításra. Mint mindig, most is a felhasználó felelőssége a legbiztonságosabb jelszó kiválasztása.

A fejlettebb kriptográfiai alkalmazások a fájlrendszer szintjén működnek, és nyomon követik a fájlokat létrehozásuk, írásuk vagy módosításukkor. Ez a módszer a legjobb védelmet nyújtja a személyes adatok számára bármilyen felhasználási mód esetén, és sok fájl esetén is jó. Ezenkívül nem kell aggódnia az olyan alkalmazások miatt, amelyek nem tudják, hogyan kell egyenként titkosítani a fájlokat.

Egyes kriptográfiai technológiák ingyenesek, és számos disztribúcióban megtalálhatók. A Windows legújabb verziói egyébként egy speciális fájlrendszerrel vannak felszerelve, amely támogatja az Encrypted File System (EFS) titkosítást. A Fedora számos titkosítási lehetőséget támogat, beleértve a LUKS-t (a LUKS támogatást Windows alatt is engedélyezheti, ha FAT vagy FAT32 fájlrendszert és FreeOTFE alkalmazást használ). A FUSE és az EncFS pedig Extra csomagokban érhető el. A CryptoFS innen letöltve is telepíthető hivatalos oldal. .

A FUSE infrastruktúra egy betölthető kernel modulból és egy felhasználói terület könyvtárból áll, amely mind a CryptoFS, mind a titkosított fájlrendszer alapjául szolgál. fájlrendszer(EncFS). Kialakításánál fogva a FUSE nem befolyásolja a kernel forráskódját, ugyanakkor nagy rugalmasságot biztosít számos érdekes kiegészítés, például a Secure Shell fájlrendszer (SSHFS) távolról csatolt fájlrendszer megvalósításához.

A CryptoFS a titkosított adatokat a szokásos könyvtárstruktúrában tárolja, két fő részre osztva: szöveges információkra (fájlok listája, mappák, archívumok) és a ténylegesen titkosított adatokra. Titkosított könyvtárat csak a kulccsal csatlakoztathat újra. A CryptoFS használatakor nincs szükség különleges jogosultságokra, és a beállítása is egyszerű.

Az EncFS fájlrendszer egyben a FUSE könyvtáron alapuló felhasználói terület megvalósítás, amely védelmet nyújt az információlopás ellen, és a fájlonkénti titkosítás elvén működik. Szerkezetét a korábbi verzióktól örökölte, de mind formai, mind funkciói fejlesztésekkel. Az EncFS fájlrendszer dinamikusan bővíthető, hogy megfeleljen a növekvő felhasználói igényeknek. A fájlok különféle paraméterek szerint titkosíthatók (például tartalom, attribútumok megváltoztatásakor stb.). Alapvetően az EncFS mögöttes tárolója bármi lehet az ISO lemezképtől a hálózati partícióig vagy akár egy elosztott fájlrendszerig.

Mindkét fájlrendszer teljes körű, és más fájlrendszereken és logikai absztrakciókon, például naplókon vagy kiterjesztett fájlrendszereken felül is használható, amelyek logikai partíciókezelő (LVM) segítségével több fizikai adathordozón is eloszthatók. A következő ábra sematikusan mutatja be a fájlrendszer működését: ezen az ábrán a látható könyvtár a /mount (EncFS titkosítatlan adatszint).

Felhasználói terület fedvény, amely a FUSE és az EncFS közötti interakciót mutatja.

A fájlrendszer absztrakciós rétege alatt olyan alacsony szintű (blokk) titkosítási sémák találhatók, mint a LUKS-ban használtak. Az ilyen típusú sémák csak lemezblokkon működnek, nem figyelve a magasabb szintű fájlrendszer absztrakcióira. Hasonló sémák használhatók cserefájlokhoz, különféle tárolókhoz, vagy akár teljes fizikai adathordozóhoz, beleértve a gyökérpartíció teljes titkosítását.


A LUKS a fájlrendszer formátumának pontos ismerete nélkül működik.

A LUKS a Trusted Key Setup #1 (TKS1) szerint készült, és kompatibilis a Windows rendszerrel, ha valamilyen általános fájlrendszer-formátumot (FAT/FAT32) használ. A rendszer kiválóan alkalmas mobil felhasználók számára, támogatja a Gnu Privacy Guard (GPG) kulcsok kiadását és visszavonását, és teljesen ingyenes. A LUKS sokkal többre képes, mint bármely más, ebben a cikkben leírt megvalósítás. Ezenkívül a LUKS számos megoldást támogat a LUKS titkosított eszközök létrehozására és kezelésére.

A CryptoFS fájlrendszer csak jelszót fogad el, míg a LUKS-szal titkosított adathordozó bármilyen PGP (Pretty Good Privacy) kulccsal működik, tetszőleges számú jelszóval. Az EncFS jelszót is használ a fájlok védelmére, de a megfelelő gyökérkönyvtárban tárolt kulcsot nyit meg.

Az alacsony szintű és a felhasználói terület implementációi közötti különbségek legjobban a gyakorlati teszteken láthatók. Alacsony szinten az adatok "átláthatóan" átvihetők a fájlrendszerbe, amely sokkal hatékonyabban kezeli az írást és az olvasást.

Tesztkonfiguráció

Tesztplatformunk a Dell Latitude C610 laptop volt, amely kissé elavult, de még így is elég fürge képviselője a 2002-es modell technológiájának. Akkumulátorról a C610 733 MHz-re csökkenti a CPU órajelét. Ezért a tesztelés során nem húztuk ki a laptopot a konnektorból. Az alábbi táblázat a laptop konfigurációját mutatja be

A teszteredményeket az EXT3 fájlrendszer használatával kaptuk Linux alatt. Talán az EXT3 nem a legteljesítményesebb a többi naplózó fájlrendszerhez képest. De a rendszerformátum, a blokkméret, a meghajtóparaméterek stb. finomhangolásával kapcsolatos kísérletek szóba sem jöhetnek. nem teszteljük őket, mivel nem felelnek meg az egyszerű beállítás és konfiguráció kritériumainak. Emlékezzünk vissza, hogy a cikk célja az volt, hogy bemutassa, hogyan teszik egyszerűvé, hatékonyan és olcsóvá a biztonságos adattárak létrehozását a Linux kriptográfiai megoldásaival.

Telepítés

A LUKS, a FUSE és az EncFS elérhető a Fedora disztribúcióban, így nincs szükség további erőfeszítésekre. De a CryptoFS-t külön kell letölteni.

A CryptoFS forrásból való fordítása meglehetősen egyszerű. Csomagolja ki az archívumot, futtassa a konfigurációs szkriptet a célkönyvtárban, majd futtassa a make parancsot az ábrán látható módon. A konfigurációs fájl négy paramétert tartalmaz: titkosítási rejtjel, üzenetkivonat algoritmus, blokkméret és titkosítási sószám.


A CryptoFS telepítési folyamata egyszerű.

A konfiguráció a kezdő- és zárókönyvtár elérési útjának meghatározásából áll (titkosított és titkosítatlan adatokhoz). Ezután a következő ábrán látható módon futtathatja a cryptofs parancsot.


CryptoFS beállítása.

Ezután futtathatja a mount parancsot, amely után láthatja a felcsatolt partíciót.

Először feltétlenül töltse be a FUSE kernel modult (modprobe biztosíték). Az EncFS leegyszerűsíti a titkosított tároló létrehozásának folyamatát, amint az a következő ábrán látható.


A kulcstelepítési folyamat elhagyásával (amely minden helyzetre jellemző), a LUKS könnyen konfigurálható az alábbiak szerint.


Benchmarkok és teljesítményelemzés

A natív telepítés és a LUKS-titkosított telepítés közötti teljesítménybeli különbségek meglehetősen csekélyek. Főleg, ha figyelembe vesszük a userspace megoldások észrevehető különbségét. A titkosított fájlrendszerek teljesítményének egyenkénti értékeléséhez az Iozont használtuk. A tesztekhez 4 KB és 16 MB közötti rekordokat használnak, a fájl mérete 64 KB és 512 MB között változik, az eredményt pedig KB/s-ban adják meg.

Következtetés

Legalábbis ott, ahol a LUKS-t használják, nem kell aggódnia a teljesítmény miatt. Bár természetesen némi teljesítménycsökkenést okoz az "átlátszó" adattitkosítás. A LUKS könnyen és egyszerűen telepíthető, és Linuxon és Windowson egyaránt használható.

A vállalati felhasználóknak minden bizonnyal meg kell küzdeniük a vállalati politikával kapcsolatos korlátozásokkal. Gyakran tiltják a nyílt forráskódú megoldásokat, vagy tiltanak bizonyos megvalósításokat. Ezenkívül néha fontolóra kell vennie a titkosítási technológiák importálásának / exportjának korlátozását a kód erőssége tekintetében, vagy az informatikai részleg telefonos támogatást igényel a megoldás szolgáltatójától, amely lehetővé teszi, hogy elfelejtse a LUKS-t, az EncFS-t és a CryptoFS-t. A LUKS mindenesetre remek megoldás, ha nincsenek ilyen problémák. Jó lehetőség kisvállalkozások vagy otthoni felhasználók számára.

De ne feledje, hogy az adattitkosítás nem csodaszer. Mivel a titkosítás átlátható, a felhasználó nevében futó bármely trójai hozzáférhet a titkosított adatokhoz.

A szerkesztő véleménye

A CryptoFS és az EncFS felhasználói terület megvalósítások. Amint azt korábban kifejtettük, tervezésük és megvalósításuk egyszerű, de a teljesítmény és a szolgáltatások ára van. Ez különösen nyilvánvaló a LUKS-szal összehasonlítva. Nemcsak észrevehetően gyorsabb, de egy vagy több PGP-kulcsot is támogat, és egy teljes partíción használható.

A felhasználóiterület-tárolók elsősorban azon felhasználók számára fontosak, akik többfelhasználós környezetben szeretnék megvédeni a személyes adatokat. És kinek kell megvédenie az adatait, hogy még egy rendszergazda sem férhessen hozzá hardver- vagy szoftverforrásokhoz. A teljesítmény és a többplatformos támogatási előnyök mellett a LUKS jól integrálható a GNOME és PGP kulcskezelő rendszerekkel. És könnyedség mindennapi használat A titkosított LUKS partíciók egyszerűen lenyűgözőek. Az EncFS egyébként támogatja a Pluggable Authentication Module-t (PAM) Linux alatt a megfelelő környezetekben.

A saját könyvtár titkosítása megbízható védelmet nyújt a merevlemezen vagy más adathordozón tárolt adatok számára. A titkosítás különösen fontos laptopokon, többszörös hozzáférésű számítógépeken és bármilyen más környezetben. A Linux Mint telepítésekor elérhető a kezdőkönyvtár-titkosítás.

A saját könyvtár teljes titkosításának fő bökkenője az, hogy a titkosított adatokat tartalmazó könyvtárat a csatolási ponton kívülre kell „mozgatni”.

A teljesítmény kissé csökken, legalábbis SWAP használata nélkül. A SWAP egy speciális lemezpartíció vagy fájl, amelybe az operációs rendszer áthelyezi a RAM egyes blokkjait, ha nincs elég RAM az alkalmazások futtatásához. A SWAP akkor is titkosított, ha a telepítőben a saját könyvtár titkosítását választja, és a hibernált mód nem működik.

Ne titkosítsa a SWAP-ot titkosított saját könyvtárral – ez potenciálisan veszélyes, mivel a titkosított fájlokból származó adatok lehetnek tiszta szövegben – a titkosítás lényege elvész. A Linux Mint 14-es verziójától kezdve a telepítés során lehetőség van a teljes lemez titkosításának kiválasztására. Ez az opció a legalkalmasabb személyes adatok hordozható eszközökön történő tárolására (amelyeknek általában csak egy felhasználójuk van).

1.3 Titkosítás a gnome-ban - Seahorse

A Linux Mint rendelkezik egy „Jelszavak és kulcsok” vagy Seahorse nevű beépített segédprogrammal. Lehetőségeit kihasználva a felhasználó az ebben az operációs rendszerben elérhető összes kulccsal, jelszóval és tanúsítvánnyal működhet.

Lényegében a Seahorse egy alkalmazás a GNOME-hoz (a GNOME egy ingyenes asztali környezet Unix-szerű operációs rendszerekhez), amely a GnuPG (információk titkosítására és digitális aláírások létrehozására szolgáló ingyenes program) front-endje, és a titkosítás kezelésére szolgál. kulcsokat és jelszavakat. A GNOME kulcstartó helyett jött, amelyet teljesen lecseréltek a GNOME 2.22-ben, bár a GNOME 2.18-ban bejelentették. Lehetővé teszi az összes művelet végrehajtását, amelyet korábban a parancssorban kellett végrehajtania, és egyetlen felület alatt egyesíteni őket:

    kezelheti munkakörnyezete és OpenPGP- és SSH-kulcsai biztonságát;

    fájlok és szöveg titkosítása, bővítése és ellenőrzése;

    digitális aláírás hozzáadása és ellenőrzése a dokumentumokhoz;

    szinkronizálja a kulcsokat a kulcsszerverekkel;

    kulcsok létrehozása és közzététele;

    kulcsfontosságú információk lefoglalása;

    hozzáadhat képeket bármely támogatott GDK-ban OpenGPG fényképes azonosítóként;

1.4 TrueCrypt

A TrueCrypt meglehetősen felhasználóbarát grafikus felülettel rendelkezik, de sajnos a fejlesztők a Nautilus fájlkezelővel vezetékesen integrálták a kódot.

Az adatok titkosítására különféle módszerek használhatók.

Először létre kell hoznia egy úgynevezett tárolót, amely titkosításra szánt fájlmappákat tartalmaz. A tároló lehet tetszőleges nevű fájl, vagy akár egy teljes lemezpartíció is. A tároló eléréséhez meg kell adnia egy jelszót, és létrehozhat egy kulcsfájlt (opcionális), amelyet az információk titkosítására használunk. A konténer korlátozott.

Titkosított partíciók/fájlok létrehozása

Kulcsfájl létrehozása:

truecrypt -create-keyfile /home/user/test/file , ahol a fájl a kulcsfájl neve.

Tároló létrehozása, jelen esetben egy szakasz:

sudo truecrypt -k /home/user/test/file -c /dev/sda9

A /dev/sda9 partíció helyett teljesen lehetséges egy fájl megadása, például /home/user/test/cryptofile, de ebben az esetben meg kell adni a méretét, ez a -size= paranccsal történik. 5G paraméter a -c paraméter előtt. Ez a példa egy 5 GB-os kriptográfiai fájlt hoz létre. A TrueCrypt néha csak bájtban fogadja el a méretet, 5 GB-nál vagy előre kiszámolhatod az értéket és megadhatod a -size=5368709120 értéket, vagy így írhatod: -size=`echo 1024^3*5 | bc`.

A titkosításhoz egy már elkészített kulcsfájlt használunk.

Létrehozáskor a rendszer kéri, hogy válassza ki a tároló típusát (normál / rejtett), a fájlrendszert (FAT, ext2 / 3/4 vagy FS nélkül), ebben a példában az FS használata nélküli módot választottuk ki. A rendszer felajánlja a titkosítási algoritmusok (például AES) és a hash algoritmusok (például SHA-1) kiválasztását is az adatfolyamok titkosításához.

A TrueCrypt az adatok menet közbeni titkosítására szolgál, vagyis a konténer felcsatolásával a szokásos módon dolgozhatunk a benne lévő fájlokkal (megnyitás/szerkesztés/bezárás/létrehozás/törlés), ami nagyon kényelmes.

Létrejött egy titkosított partíció/fájl. Most, ha a belső fájlrendszerét (a továbbiakban FS) a kívántra kell formáznia, tegye a következőket.

Válassza ki a kívánt partíciót a Truecrypt segítségével:

truecrypt -k /home/user/test/file /dev/sda9

Alapértelmezés szerint a létrehozott Truecrypt eszköz /dev/mapper/truecrypt0 lesz használatban. Az eszközhöz való hozzáféréssel módosíthatja például a fájlrendszert egy titkosított tárolóban. Ebben az esetben meg kell tenni.

sudo mkfs.ext4 -v /dev/mapper/truecrypt0

Ezzel az ext4 FS ebben a titkosított tárolóban készült.

Továbbá, mivel ez a tároló már „csatolva van” a /dev/mapper/truecrypt0 eszközhöz, csak be kell csatolni valamilyen könyvtárba. Ennek a beillesztési könyvtárnak már léteznie kell a rendszeren.

sudo mount /dev/mapper/truecrypt0 /mnt/crypto, ahol az /mnt/crypto az a könyvtár, amelybe a titkosított tároló fel van csatolva.

truecrypt -d

Most a kulcsfájl és a jelszó ismerete nélkül senki sem tudja elolvasni a rejtett információkat.

: - Orosz

Az oldal aktív fejlesztése befejeződött

Ha van mit kiegészíteni, akkor egészítse ki a rovatokat új információkkal. A cikkben található elgépeléseink, hibáink biztonságosan szerkeszthetők, nem kell levélben bejelenteni, kérjük kövesse az oldal stílusát és használjon szakaszelválasztókat (különböző vastagságú szürke vonalak).

Adattitkosítás a Debianban

Sokan úgy gondolják, hogy nem kell titkosítania az adatait. A mindennapi életben azonban gyakran találkozunk olyan helyzetekkel, hogy „elveszett egy pendrive” vagy „javításra adták át a laptopot” stb. Ha az adatai titkosítva vannak, akkor egyáltalán nem kell aggódnia: senki sem teszi közzé az interneten, vagy más módon nem használja fel.

Titkosítás cryptsetup segítségével

Telepítse a szükséges alkatrészeket:

# apt-get install cryptsetup

Szabványos szintaxis

/dev/sda2. Írjuk be a parancsot:

# cryptsetup létrehozása sda2_crypt /dev/sda2

Ez a parancs titkosított kapcsolatot hoz létre a lemezünkkel. Katalógusban /dev/mapper egy új eszköz jelenik meg az általunk kért névvel: /dev/mapper/sda2_crypt, amelynek eléréséhez titkosított lemezelérést használunk. A LUKS esetében ez lenne a név /dev/mapper/sda2_crypt

Ha már volt fájlrendszer a lemezen, és arra szeretnénk adatokat menteni, akkor ezeket titkosítanunk kell a későbbi felhasználáshoz:

# dd if=/dev/sda2 of=/dev/mapper/sda2_crypt

Ha létrejön új lemez egy üres partíción formázhatja:

# mkfs.ext3 /dev/mapper/sda2_crypt

Később ezt a lemezt bárhová csatlakoztathatja:

# mount /dev/mapper/sda2_crypt /path/to/mount/point

Ellenőrizze az adatok integritását (a szokásos módon, a legjobb, ha nem csatlakoztatott állapotban használja):

# fsck.ext3 /dev/mapper/sda2_crypt

És még visszafejteni is, ha már nem akarunk titkosítást használni:

# dd if=/dev/mapper/sda2_crypt of=/dev/sda2

LUKS szintaxis

A fenti lépéseket a LUKS szabvány szerint lehet elvégezni

Inicializáljuk a szakaszt:

cryptsetup luksFormat /dev/sda2

Csatlakozunk a rendszerhez:

cryptsetup luksNyissa meg a /dev/sda2 sda2_crypt fájlt

Formázás:

mkfs.ext4 -v -L DATA /dev/mapper/sda2_crypt

Szereljük:

mount /dev/mapper/sda2_crypt /mnt/data

A rendszerről szóló rész manuálisan letiltható

cryptsetup luksZárja be az sda2_crypt fájlt

Csatlakozás indításkor

A fájl erre a célra szolgál. crypttab.

A lemezünkre írja be a következő sort:

nano /etc/crypttab # névleképező eszközkulcs params/options # Standard szintaxis sda2_crypt /dev/sda2 none aes-cbc-plain:sha256 # és/vagy LUKS szabvány sda2_crypt /dev/sda2 nincs luks

Alapértelmezés szerint a titkosítás a felhasználó által megadott jelszóval történik. Így minden alkalommal, amikor elindítja a számítógépet, a rendszer minden alkalommal jelszót kér az egyes titkosított partíciók csatlakoztatásához. Még akkor is, ha ezek a szakaszok nincsenek regisztrálva az fstab-ban.

Ha manuálisan szeretnénk felszerelni, akkor adjuk hozzá a lehetőséget auto a "Beállítások/Opciók" mezőben.

Titkosított partíció manuális csatlakoztatása az /etc/crypttab fájlból származó adatok szerint

cryptdisks_start msda2_crypt

És leállítás előre szerelt fs-sel.

cryptdisks_stop sda2_crypt

Az fs automatikus csatlakoztatásához a csatlakoztatott titkosított partícióhoz adjon hozzá egy sort /etc/fstab

/dev/mapper/sda2_crypt /mnt/data ext4 alapértékek 0 0

Kulcsokkal végzett munka a LUKS-ban

A LUKS szekció 8 különböző kulcsot támogat, amelyek mindegyike a saját nyílásába illeszkedik.

Tekintse meg a használt kulcsok listáját

cryptsetup luksDump /dev/sda2

A LUKS-ban kétféle kulcs használható – kulcskifejezések és fájlok.

Hozzáadhat kulcsszót

cryptsetup luksAddKey /dev/sda2

Hozzáadhat egy kulcsfájlt (2048 bit), és hozzáférési jogokat állíthat be hozzá.

dd if=/dev/urandom of=/root/ext2.key bs=512 count=4 cryptsetup luksAddKey /dev/sda2 /root/ext2.key chmod 400 /root/sda2.key cryptsetup -d /root/sda2.key luksNyissa meg a /dev/sda2 sda2_crypt fájlt

Az indításkor a kulcs segítségével történő csatlakozáshoz szerkessze az /etc/crypttab fájlt

nano /etc/crypttab sda2_crypt /dev/sda2 /root/sda2.key luks

Eltávolíthat egy jelmondatot vagy kulcsot egy szakaszból

cryptsetup luksKillSlot /dev/sda2 1

Vészszerelés "idegen" disztribúcióban

Senki sincs biztonságban a problémáktól, és néha el kell érnie egy titkosított partíciót egy mentő LiveCD-ről.

Indítjuk, csatlakoztatjuk a partíciót a rendszerhez, és csatoljuk az fs-t:

cryptsetup luksOpen /dev/sda2 sda2_crypt mount -t ext4 /dev/mapper/sda2_crypt /mnt/backup

Munka után válassza le az fs-t, és válassza le a titkosított partíciót a rendszerről

umount /mnt/backup cryptsetup luksClose sda2_crypt

Leállítási hibaüzenetek

Ha a gyökérpartíció titkosított, akkor egy üzenet jelenik meg a leállításkor

a korai kriptolemezek leállítása... nem sikerült

Ez technikai hiba. Leállításkor először mindig a fájlrendszereket bontják le, és csak ezután szerelik le a partíciót. Ennek eredményeként kiderül, hogy a gyökér unmounted partíción található cryptsetup segédprogram már nem indítható el, amiről az INIT tájékoztat. Mankók nélkül ez a probléma nem oldható meg, mert. ehhez mérlegelnie kell a cryptsetup RAM lemezre való átvitelének lehetőségeit

Hasonló helyzet fordul elő gyökérpartíciót tartalmazó szoftveres RAID használatakor. nyolc)

Titkosítás a loop-aes modullal

Merevlemez-partíció titkosítása, flash meghajtó jelszóval

Ebben hogyan kell titkosítási módszer leírása AES256, más módszerek is hasonlóképpen alkalmazhatók (a metódus nevét a megfelelőre cserélve). A következő csomagokra lesz szükségünk:

# apt-get install loop-aes-utils loop-aes-modules-`uname -r`

jegyzet: ha olyan kernelt használ, amelyhez a szükséges loop-aes-modules nincs a tárolóban, akkor a következő parancsokkal telepítheti a modulokat:

# apt-get install modul-assistant loop-aes-source # modul-assistant a-i loop-aes

Első fázis

A kezdeti szakaszban titkosítással előkészítjük a lemezt, hogy működjön vele.

Válasszuk ki a titkosítani kívánt lemez (vagy flash meghajtó) partícióját, pl. /dev/sda2. Írjuk be a parancsot:

#lostup -e AES256 -T /dev/loop0 /dev/sda2

A parancs végrehajtása után minden hívás az eszközre /dev/loop0 titkosításra és titkosításra kerül, és átirányítja az eszközre /dev/sda2. Most már titkosított és titkosítatlan csatornáink is vannak a tárolóeszközhöz. Az adatok titkosítása a veszteség végrehajtásakor megadott jelszóval történik.

Most például formázhatjuk az eszközt:

# mkfs.ext3 /dev/loop0

Felszerelhetjük:

# mount /dev/loop0 /path/to/mount

letilthatjuk a titkosítást:

#lostup -d /dev/loop0

és ami a legfontosabb: titkosíthatjuk a partíciót adatvesztés nélkül:

# dd if=/dev/sda2 of=/dev/loop0

és dekódolni is, ha úgy döntünk, hogy a titkosítás nem a mi módszerünk:

# dd if=/dev/loop0 of=/dev/sda2

Nos, a legjobb az egészben az, hogy ellenőrizhetjük a fájlrendszer integritását:

# fsck.ext3 /dev/loop0

Ez a szolgáltatás nem érhető el minden partíciótitkosítási módszernél.

Mindennapi használat

Ha már volt szakaszbejegyzése /dev/sda2 a tiédben /etc/fstab, akkor csak opciókat kell hozzáadnia, és ha nem, akkor írjon valami ilyesmit:

/dev/sda2 /path/to/mount ext3 loop,encryption=AES256 0 0

Most, amikor elindítja az operációs rendszert, a rendszer jelszót kér a csatlakoztatáshoz.

Ha nem szeretné, hogy a letöltési folyamatot megszakítsa egy jelszókérés, akkor további lehetőségeket adhat hozzá auto,felhasználó jegyzőkönyvbe /etc/fstab:

/dev/sda2 /path/to/mount ext3 loop,encryption=AES256,noauto,user 0 0

Természetesen manuálisan (vagy szkriptből) csatlakoztatható:

# mount /dev/sda2 /path/to/mount -o loop,encryption=AES256

Több fájlrendszer csatlakoztatása

Néha több szakaszt szeretne titkosítani egyidejűleg adatokkal, de azért, hogy ne adjon meg egy tengernyi jelszót mindegyikhez hegy. Például van egy pendrive, amelyet otthonról a munkahelyére visz magával, egy hordozható merevlemez stb. Vagy csak néhány partíció/merevlemez.

Tegyük fel, hogy van egy titkosított partíciónk /dev/sda2, amelyet minden rendszerindításkor felcsatolunk a könyvtárba /mnt1. Új merevlemez érkezett /dev/sdb1és azt akarjuk, hogy automatikusan felcsatolódjon a könyvtárba mnt2 az első felszerelésekor. Természetesen létrehozhat közös rendszer valami ilyesmin LVM, de járhatsz az egyszerűbb úton is:

beírni fstab mint a következő sor:

/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0

A rendszer a rendszerindításkor a pontokat ugyanabban a sorrendben csatlakoztatja, mint ahogy az itt leírtak fstab, tehát ha az első partíció nincs csatlakoztatva, akkor a második partíció csatlakoztatásának kulcsa elérhetetlen marad, és a második partíció sem lesz csatlakoztatva.

A jelszó tárolása: egyszerű szöveg ez persze nem túl szép, de egy titkosított partíción van tárolva (ami lecsatolható). Használhatja helyette gpg-key, de ez nem ad nagy biztonságot (ha már el tudják lopni a kulcsot, akkor nem lesz nagy különbség, hogy mi lesz ez a kulcs), titkosítási lehetőség gpg-ban leírt kulcs ember elveszett, itt csak egy példát mondok a felvételre fstab:

/dev/sda2 /mnt1 ext3 noatime,exec,loop,encryption=AES256 0 0

Megjegyzések

A támogatott titkosítási algoritmusokkal kapcsolatos további információkért lásd: ember elveszett, láthatja a többi programlehetőség leírását is elveszett.

Ha problémái vannak az AES modulok telepítésével, olvassa el a csomaghoz mellékelt dokumentációt loop-aes-source.

GRUB és titkosított gyökérlemez

Amikor root partíciót telepít egy titkosított lemezre, a GRUB hibákat jeleníthet meg a főmenüben. Ez azért történik, mert a /usr/share/grub/unicode.pf2 szabványos betűtípus nem érhető el. A betűtípus másolása

cp /usr/share/grub/unicode.pf2 /boot/grub/

Adja meg a beállítást

nano /etc/default/grub GRUB_FONT=/boot/grub/unicode.pf2

A beállítás alkalmazása:

update-grub