Ebben a cikkben megpróbálom összehasonlítani a teljesítményt különféle rendszerek titkosítás linux alatt. Elméletileg persze ismert, hogy melyik rendszer termelékenyebb, és megpróbálja kiszámítani a teljesítményt különböző rendszerek voltak (). A Truecrypt még egy beépített benchmarkot is tartalmaz (ami viszont a RAM-on való teljesítményt mutatja, csak a különböző titkosítási algoritmusok sebességének értékelésére használható). Valami mást fogok csinálni - a különféle eszközökkel titkosított fájlrendszer sebességét százalékban fogom mérni a hagyományos titkosítatlan fájlrendszerhez képest.
Egy külön partíciót titkosítunk egy különálló merevlemezen, amely nem tartalmazza a gyökérkönyvtárat fájlrendszer, az egyes esetekben használt alapértelmezett algoritmus. Hétköznapi felhasználóként nem értem a titkosítási szabványok árnyalatait (például miben különbözik a RIPEMD-160 hash a Whirpooltól, melyik mód gyorsabb, melyik járul hozzá a nagyobb biztonsághoz), ezért csak a tényre hagyatkozunk. hogy a gyártók mindegyik szoftver termék megfelelően titkosításálló alapértelmezett paramétereket választott. Talán ez nem teljesen helyes, mert a különböző titkosítási algoritmusok teljesítménye nem azonos. Kívánt esetben természetesen módosíthatja a titkosítás típusát, de nem vagyok benne biztos, hogy minden tesztelt termékben teljesen azonos algoritmuskészlet található. Teszteljük:
3) eCryptfs - az alapértelmezett rendszer Ubuntu felhasználók saját könyvtárak titkosításához, ezért szerepel ebben a tesztben. Meglévő fájlrendszeren működik. Minden fájlt külön titkosít, így mindenki láthatja a jogokat, a módosítás dátumát, a titkosított fájlok számát; alapértelmezés szerint a fájlnevek is láthatók, bár van lehetőség titkosításukra. A valaha volt legkevésbé működő eszköz.
4) EncFS - az eCryptfs hozzávetőleges analógja, de FUSE-t használ.
Tehát a tesztekhez egy különálló, meglehetősen fejlett korú gépet választottak ki a következő konfigurációban: CPU - Intel Celeron 2000Mhz, RAM - 512 Mb DDR PC2700, rendszer HDD - WD Caviar SE 5400 RPM 80Gb, tesztelje a HDD-t- WD Caviar SE 7200RPM 80Gb.
OS - Ubuntu 12.04 LTS, az összes szoftver verziója releváns az operációs rendszer lerakatai számára a jelen írás idején (a Truecrypt 7.1a-linux-x86 nem a tárolókból származik).
A legtöbb disztribúcióhoz az alapértelmezett ext4 fájlrendszert fogjuk tesztelni. A teljesítmény teszteléséhez az izone3 segédprogramot és a „térdre” írt shell scriptet fogjuk használni a tesztek százalékos különbségének mérésére.
Számoló szkript. A kód tisztaságára nem fordítottak különösebb figyelmet, az írás egyetlen kritériuma a helyes eredmény megléte volt.
#!/bin/sh gendiffffile () ( #az eljárás egy olyan fájlt hoz létre, amely alkalmas az elemzésre. Először is a nem értelmezhető sorokat a rendszer csonkolja; másodszor pedig minden sorban az első két számot a rendszer csonkolja, jelezve a #fájl méretét és rekordját méretben ; harmadszor, a teljes fájl soronként jelenik meg - #soronként egy teszteredmény cat $1 | LINE olvasás közben ; do echo $LINE| grep "^[[:space:]]*[[:digit:] ]" | awk "(for (i=3;i<=NF;i++) {print $i}}" done > > $2 ) getline () ( #procedure a $2 sorszámot adja ki a $1 fájlból head -n $2 "$1" | tail -n 1 ) összehasonlít () ( #procedure soronként összehasonlítja a $1 és $2 fájlt, kiszámítva az egyes fájlok százalékos különbségét tesztpár #majd kiszámítja a számtani átlagot, hány százalékkal gyorsabb vagy lassabb #a tesztek első csoportját tartalmazó fájl, a második csoportot tartalmazó fájl P=0 MAX=0 L1=`cat "$1" | wc -l` #szám tesztek közül a fájlban L2=`cat "$2" | wc -l` ha [ $L1 -ne $L2 ]; akkor #ha a fájlok eltérő számú tesztet tartalmaznak, akkor nem hasonlítjuk össze őket echo error return fi STEP =$(($L1*5/100)) J=0 I-re a "seq 1 $L1"-ben; tegye a J=$(($J+1)), ha [ $J -eq $STEP ]; akkor J= 0 echo "$((100*$I/$ L1))% kész ($L1 $I)" fi A=`getline "$1" $I` B=`getline "$2" $I` if [ `visszhang $A \> $B|bc -l` - eq 1 ], majd D=`echo "100-($B*100/$A)"|bc -l` if [ `echo $D \> $MAX| bc -l` -eq "1" ]; akkor MAX=$D alvás 5 fi else D=`echo "100-($A*100/$B)"|bc -l` if [ `echo $D \> $MAX| bc -l` -eq "1" ]; akkor MAX=$D alvás 5 fi D="-$D" #ha az értéknek "-" jele van, akkor ez a teszt gyorsabban futott #a második fájlban mint az első fi P=`echo "$P+ $D"| bc -l`done P=`echo $P/$L1| bc -l` #számtani átlag kiszámítása echo PERCENT=$P MAX_PERCENT=$MAX ) genaverage () ( #egy elemzésre előkészített fájl létrehozásának eljárása, amelynek minden sora az összes jelentés megfelelő sorainak #számtani átlaga fájlok az elemzett könyvtárban találhatók ennek a feltételezésnek a helyessége, ha [ ! -d " $1" -o $F -lt 2 ]; akkor echo error >/dev/stderr #ebben az eljárásban az összes üzenetet a stderr-nek adjuk ki, mivel az #stdout egy másikra van behelyettesítve procedúra rm -f $AVG kilépés fi TMP=` mktemp` "$1" keresése -type f| a FILE olvasása közben; csináld #minden egyes izone jelentésfájlhoz az adott könyvtárban I=`mktemp` #gendifffile "$FILE" "$I " #names minden ilyen fájlt "TMP"-be ír soronként echo "$I">>$TMP kész L=`cat \`getline "$TMP" 1\`|wc -l` cat "$TMP"| LINE olvasás közben; jó #egy kis ellenőrzés L1=`cat "$LINE"| wc -l` #minden fájl ugyanannyi tesztet tartalmaz, ha [ $L -ne $L1 ]; majd echo error >/dev/stderr kilépés fi kész STEP=$(($L*5/100)) J=0 for I in `seq 1 $L`; do J=$(($J+1)) if [ $J -eq $STEP ]; akkor J=0 echo "$((100*$I/$L))% kész ($I of $L)" >/dev/stderr fi SUMFILE=`mktemp` #így megkapom a SUM változó értékét a beágyazott hurokból SUM=0 cat "$TMP"| LINE olvasás közben; do SUM=$((`getline "$LINE" $I`+$SUM)) echo $SUM > "$SUMFILE" kész echo `tail -n 1 "$SUMFILE"`/$F|bc -l >> $ AVG #kérje ki a számtani középértéket #és írja be #az AVG fájl megfelelő helyére rm -f "$SUMFILE" kész cat "$TMP"| LINE olvasás közben; do #delete ideiglenes fájlokat rm -f "$LINE" kész rm -f "$TMP" echo $AVG ) printf %b "\\033, TPM chippel vagy anélkül), vagy
A második módszerhez tekintse meg a Linux Full Disk Encryption (LFDE) projektet a következő címen: http://lfde.org/, amely egy telepítés utáni szkriptet biztosít a /boot partíció külső USB-meghajtóra történő áthelyezéséhez titkosítással. a kulcsot GPG-vel és USB-n is tárolni. Így a rendszerindítási útvonal gyenge része (a titkosítatlan /boot partíció) mindig veled van (csak te leszel az egyetlen, aki fizikailag hozzáférhet a dekódoló kódhoz és a kulcshoz). ( jegyzet: ez az oldal elveszett, és a szerző blogja is eltűnt, de a régi fájlokat megtalálod a https://github.com/mv-code/lfde oldalon, csak megjegyezve, hogy az utolsó fejlesztés 6 éve történt). Könnyebb alternatívaként az operációs rendszer telepítésekor titkosítatlan rendszerindító partíciót csatlakoztathat egy USB-meghajtóra.
Üdvözlettel: M.V.
Tedd titkosítatlanná az első RAM-lemezt és /boot mappát.
Ez egy "minimális" kernelt hív meg illesztőprogramokkal és támogatással, hogy átváltson egy "igazi" titkosított gyökérfájlrendszerre.
Mielőtt kijelentené, hogy "ez egy feltörés", ne feledje: a legtöbb (ha nem az összes) Linux disztribúció ma alapértelmezés szerint elindul. Ez kifejezetten lehetővé teszi a rendszer számára, hogy betöltse és betöltse a gyökér FS-t olyan modulok használatával, amelyeket a fájlrendszerből kell betölteni. (Amolyan csirke-tojás probléma). Például, ha a gyökér fájlrendszer hardveres RAID köteten volt, és a gyökér FS csatlakoztatása előtt be kellett töltenie annak illesztőprogramját.
Megnéztem az általad közzétett linket - bár nincs rendszerindító partíció, a merevlemezen még mindig van egy titkosítatlan rendszerbetöltő, amelyet rosszindulatú támadás érhet és veszélyeztethet. Kerestem egy hasonló beállítást, amiben nincs titkosítatlan adat a merevlemezen, de eddig csak cserélhető meghajtóról jöttem rá, hogy a bootloadert futtassam.
Úgy gondolom, hogy a legtöbb, amire szüksége van, az az utasítás, hogy hogyan telepítse az operációs rendszert titkosított HD-vel.
Az Ubuntunak van egy szép oldala, amely utasításokat tartalmaz a titkosított partíciók, LMVP, mappák stb. létrehozásához, csak a disztribúciód verziójához...
Nem, nem hiszem.
Valóban titkosítani/feltölteni kell? Gyanítom, hogy nem. A fájlrendszer többi része titkosítható normál Linux-szoftverrel, amely a /boot fájl initramfs-jében található, és ennek megfelelően kéri a felhasználót.
Úgy tűnik, hogy olyasmit kér, amit nem lehet megtenni, és összehasonlítja a Windows megoldással, ami igen elrejti előled a megvalósítást, de valójában ugyanazt csinálja, mint a Linux.
A legközelebbi megoldás egy olyan merevlemez használata, amely biztonsági jelszót és titkosítást valósít meg. Egyes Thinkpad laptopok ezeket a hardvermegoldásokat használják.
A válasz a cikkben található. "Ez most már lehetséges a következő generációs GRUB2 rendszerbetöltő bővítményeivel, amelyet úgy javítottak, hogy ne csak egyszerűen támogassanak" és "később szeretnénk telepíteni egy új luks grub2-képes képet", valamint "Most a GRUB2 forrást a LUKS-szal fordítjuk támogatás. Úgy tűnik, hogy van egy javítás vagy bővítmény, amelyet be kell szereznie és engedélyeznie kell a GRUB2 vagy a GRUB2 elágazó forrás segítségével.
A Grub2 2.02-beta3 verziója sok mindent képes megtenni, amit a Grub2 2.02-beta2 verziója nem, ellenőriztem:
Ez elindít egy másik Grub2-t, ami a titkosított partíción belül van, az evil mad attacknak nincs itt helye... CD-ről indítok (csak olvasható), majd felcsatolom a titkosított partíciót (nem jelszó, semmi!), majd innen indulok. titkosított partíción belül és saját menüvel indítja el a Grub2-t stb.
Figyelmeztetés: A Grub2 2.02~beta2 verziója nem tudja megtenni ugyanezt, mivel a cryptomount parancshoz kapcsolódó hibák vannak benne (amelyek a Grub2 2.02~beta3 verziójában javítva vannak)...
A béta2 hibákról beszélek:
béta 3-nál:
Mellékes megjegyzés: Nem jöttem rá, hogyan tudom lecsatolni őket azon kívül, hogy újraindítok vagy elindítok egy másik vagy egy rendszerbetöltő grub2/other stb.
Remélem, ez segít tisztázni a dolgokat, és remélem, hogy a Grub2 2.02~beta3 verziója beépül a LiveCD-be, így telepíthetjük anélkül, hogy magunknak kellene lefordítanunk.
PD: Super Grub 2 meghajtóval nem látom a módját a Grub2 2.02~beta3 verziójának MBR/boot partícióra stb.
Ne feledje, ennek a munkának a szerzője az általa használt lemezpartíciók titkosítási módszereiről beszél.
Ez a kézikönyv használ Linux dm-crypt (eszköz-leképező) a magon 2.6 . Titkosítjuk a részt /dev/sdc1, lehet bármilyen partíció, lemez, USB vagy létrehozott fájl elveszett. Itt fogjuk használni /dev/loop0, néz . eszközleképező címkét használ a szakasz azonosítására, ebben a példában sdc1, de lehet bármilyen más karakterlánc is.
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ásokkal ellentétben operációs rendszer, 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ó más helyre mentheti a fájlt a lemezen, ami automatikusan kiegyenlíti az előnyt. És még egy dolog - még ha a névtitkosítás engedélyezve is van, az időbélyegek ugyanazok 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ó.
Előnyök ez a módszer szemben az előző hiányosságaival. 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 a 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 a kriptotároló felhőbe mentésekor a legtöbb esetben teljesen újra fel kell töltenie.
A cikk a következő kriptográfiai védelmi 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 cím jelenléte bizonyos esetekben önmagában is kompromittáló – a legtöbb esetben azonban hasonló esetek nagy entrópiával rendelkező, kompromittáló terület lesz. Sima 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 kihagyva):
# <...> modprobe -b dm_crypt míg! (/sbin/cryptsetup luks Nyissa meg /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 luksZárja be a titkosítási kulcsot ) ; 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 jelszót kell megadni 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. Ezek közé tartozik a kulcscsere. Erre akkor van szükség, ha újrakulcsolási szabályzatot sértenek vagy hoznak létre. 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 hozzátesszük új kulcs a rendszerbe:
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 másolat a fejlécről. 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 egy sor 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 kézzel. 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 kell kérni (csak egyszer, az újbóli belépést nem hajtják végre, ami nem néz ki túl jól jó döntés, mivel hosszúnak kell lennie), akkor kérni fogja a titkosítás típusát (AES, Blowfish, 3DES, Twofish, CAST6 és CAST5), kulcsméretet, rákérdez, hogy engedélyezi-e vagy letiltja-e a titkosítatlan fájlokat a könyvtárban a titkosított fájlokkal, titkosítani kell-e a fájlneveket... és a végén megkérdezi, hogy valóban fel akarjuk-e csatolni és elmenteni az aláírást egy adott fájlba. 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ás után azonnal be kell jelentkeznie felhasználóként, és a rendszer kéri, hogy írjon vagy nyomtatjon jelmondat titkosításra generált és védett, viszont felhasználói jelszó. Ez szükséges a helyreállításhoz vészhelyzet esetén.
Ne felejtse el a jelmondat-figyelmeztetést Lássuk, hogyan lehet visszaállítani. Tegyük fel, hogy a jelszó nincs rögzítve, és a helyreállítás egy Live CD-ről történik. 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és egy hash-fa segítségével történik, 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.
Ez a mechanizmus (együtt digitális aláírás) bizonyos Android-eszközökön 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 jó néhány eszközt tartalmaz az információk kriptográfiai védelmére. A leírt három gyógymód közül legalább egy minden modern termékben megtalálható Linux disztribúciók. De mit válasszunk?
dm-crypt/LUKS olyan esetekben kell használni, amikor lehetséges egy titkosított kötet gyors letiltása, és mikor biztonsági mentések vagy nincs szükség rájuk, vagy más módon vannak besorolva. Ebben az esetben ezt a döntést több mint hatékony, különösen, ha figyelembe vesszük, hogy tetszőleges egymásba ágyazás és típus (például AES-Twofish-AES) sorozatában titkosíthat – 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 ősibb művek alapján. Jelenleg nem ajánlott az esetleges biztonsági rések miatt, 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.
Nem titok, hogy ma az adatok titkosítása az egyetlen módja annak, hogy valahogy megmentsék őket. Ma megtanuljuk, hogyan lehet titkosított partíciót létrehozni Linuxon a luks (Linux Unified Key Setup) szabvány segítségével. Például képernyőképeket adok a CentOS Linux operációs rendszerről.
Tehát mindenekelőtt elkészítjük azt a részt, amelyet titkosítunk. Azon belül Virtuális gép Létrehoztam egy új meghajtót, csatlakoztattam hozzá SATA interfész, a /dev/sdb eszköz megjelent a rendszerben
Hozzunk létre rajta egy fő partíciót:
# fdisk /dev/sdb
Létrehozott 1 partíciót (sdb1), és megadta neki az összes szabad helyet.
Remek, most formázzuk meg a /dev/sdb1 partíciót jelmondat-kriptovédelmi eszközökkel. A rendszer kérni fogja a jelszó megadását. Ismételjük meg kétszer, hogy ne tévedjünk.
# cryptsetup --verbose --verify-passphrase luksFormat /dev/sdb1
Az alapértelmezett algoritmus az AES 256 bites. Ha szükséges, választhat másik algoritmust a switches -c algoritmus -s kulcshossz megadásával
# cryptsetup -c aes -s 1024 --verbose --verify-passphrase luksFormat /dev/sdb1
Ezután aktiváljuk a biztonságosnak nevezett kriptotárolót:
# cryptsetup luksNyissa meg a /dev/sdb1 biztonságos mappát
Ennek eredményeként egy új blokkeszköz jön létre a /dev/mapper/ könyvtárban safe néven.
Hozzon létre egy fájlrendszert:
# mkfs.ext3 /dev/mapper/safe
Mi van, ha azt akarjuk, hogy a partíciónk minden induláskor aktiválódjon (természetesen jelmondat kérésével)?
Szerkesszük az /etc/crypttab fájlt, amely hasonló az /etc/fstab fájlhoz
# vim /etc/crypttab
Adjunk hozzá egy sort:
biztonságos /dev/sdb1 nincs
És a következőket az /etc/fstab fájlban:
/dev/mapper/safe /safe ext3 alapértékei 0 0
Igen, a helyzet. Létrehoztunk egy titkosított részt. Tudjuk a kulcsot. Lehetséges-e a rovat nem csak a kulcsunkkal elérhetővé tenni, hanem más módon is. Vagyis hozzáférést akarunk adni „Vasya”-nak, hogy egyenrangúan dolgozhasson velünk. Könnyen.
Adjunk hozzá még egy kulcsot a kriptotárolóhoz.
Összesen legfeljebb 8 kulcsot hozhat létre, amelyek mindegyike elfér a saját nyílásába.
A foglalt helyeket így jelenítheti meg:
# cryptsetup luksDump /dev/sdb1
Amint látja, a 0-s és 1-es hely foglalt.A kulcsfájlok is használhatók jelszavak helyett.
A kriptotároló állapotát így jelenítheti meg:
# cryptsetup állapot biztonságos
Cél: Védelem USB eszköz a kíváncsi szemek elől.
Csatlakoztassuk a flash meghajtót a rendszerünkhöz:
A flash meghajtót sdc-eszközként határozták meg. Ez azt jelenti, hogy megjelent a /dev/sdc eszköz. Ha fat vagy ntfs partíciók voltak a flash meghajtón, akkor jobb információ ejtse el valahova, mert a készülék titkosítása után minden elvész.
Tehát a flash meghajtót az fdisk segítségével particionálhatjuk, hagyhatjuk úgy, ahogy van.
# cryptsetup luksFormat /dev/sdc
Adjon meg egy jelszót.
Most csatlakoztassuk titkosított eszközünket, hogy megjelöljük az új fájlrendszerben:
# cryptsetup luksNyissa meg a /dev/sdc flash fájlt
Most egy jelszót kérünk, aminek megadása után egy új eszköz /dev/mapper/ jelenik meg a rendszerben<имя>, esetünkben vaku.
Hozzon létre egy fájlrendszert ezen az eszközön:
# mkfs.ext3 /dev/mapper/flash
Kész. Nos, itt az ideje létrehozni azokat a kulcsokat, amelyeket az eszköz eléréséhez fog használni. Több kulcs is elkészíthető (összesen maximum 8 slot, bár a 0. helyet már foglalt egy jelmondat, de törölhető).
# dd if=/dev/urandom of=~/keyfile.key bs=1 count=256
Így létrehozunk egy 256 bájtos fájlt, eltömődött véletlen számok. Így ellenőrizheti:
# xxd ~/kulcsfájl.kulcs
Igazán. teljes véletlenszerű. Most már csak hozzá kell adni ezt a kulcsot a flash meghajtónkhoz.
Egyelőre tiltsuk le a kriptotárolót.
# cryptsetup luksClose flash
Kulcs hozzáadása:
# cryptsetup luksAddKey /dev/sdc ~/keyfile.key
A rendszer felkér minket, hogy adjunk meg egy jelszót, hogy megbizonyosodjunk arról, hogy hozzáférünk ehhez a tárolóhoz.
# cryptsetup luksDump /dev/sdc
Nagy! Most mentsük el a kulcsot egy biztonságos helyre, mert szükségünk lesz rá a konténer eléréséhez.
Az „A” felhasználó egy fájlt szeretne feltölteni a flash meghajtóra, ismerve a jelszót:
Jelszóval oldottuk fel egy mydisk eszköz létrehozásával, majd csatoltuk a mydisket a kezdőkönyvtárhoz. Létrehozva szöveges fájl hello.txt tartalommal. A tároló letiltva.
Feloldotta kulcsfájl, létrehozott egy flashka készüléket. Felcsatoltuk sergey felhasználó kezdőkönyvtárába, olvassa el a fájlt - minden rendben!
