Problémás a teljes lemez titkosítás

A hiba platformfüggetlen.

A kényes adatok védelmében nagyon sokféle megoldást kitaláltak már. Lehet azokat tartani titkosított pendrive-on, titkosított konténerben a fájlrendszeren belül, valamint igen elterjedt a “teljes” lemez titkosítás is. Idézőjelbe tettem a teljes szócskát, mert amint látni fogjuk, nem beszélhetünk valóban a teljes adatterületre vonatkozó titkosításról – és ez független az alkalmazott platformtól, a működési elv mindenhol ugyanaz. A Linux által használt LUKS-on keresztül fogom bemutatni a problémát, mert ez a legegyszerűbb, de PGP és TrueCrypt használata esetén is ugyanaz a móka.

Tegyük fel azt az alapvetést, hogy munkahelyünk előírja a kötelező titkosítást a teljes adatterületre vonatkozólag, amelynek a technikai lehetőségek szabta határokon belül eleget is teszünk. Ekkor a lemezen elhelyezkedő partícióink úgy néznek ki, hogy van egy aprócska /boot partíciónk és van egy baromi nagy, titkosított adattal ellátott / (az egyszerűség kedvéért tekintsünk most el a különböző fájlrendszerek szeparálásától). Amikor elindítjuk a számítógépet, betöltődik néhány apró kód a titkosítatlan /boot-ról, majd elkéri a titkosított terület olvashatóságához szükséges passphrase-t. Ha ezt nem, vagy rosszul adjuk meg, nem lehet feloldani a titkosítást, ergo nem jutunk előrébb a rendszerindítást illetően. Hogyan is oldódik a titkosítás? A titkosítatlan területen (/boot) van a programunk, ami tudja, hogy kell a titkosított területet unlockolni, a titkosított részen pedig ott kell lennie a kulcsnak, máshogy a módszer nem működhet és/vagy nem lenne elég biztonságos. Viszont ha a lemezen ott a kulcs, akkor az el is olvasható… Támadónknak semmi mást nem kell tennie, mint Linux esetén letöltenie a cryptsetup nevű program forrását, beletennie egy kódrészletet, amely egy általa hozzáférhető helyre kiírja a kulcsot – például egy pendrive-ra, sima text állományba.

PGP és Truecrypt esetén a forráskód-hozzáférés nem ennyire egyszerű, de nem is lehetetlen.

Mi lehet a megoldás?
Nos, többféle megoldás és félmegoldás is lehetséges. A félmegoldások közé tartozik az, hogy a /boot fájlrendszert pendrive-ra rakjuk, így tényleg a teljes lemez titkosítható. A probléma lényegét azonban nem oldja meg, mert a kulcs továbbra is kiolvasható a lemezről, ráadásul kernelfrissítéskor mindig bedugva kell lennie a pendrive-nak. Persze önmagában a számítógép nem indítható, de ez gondolom hamar leesik a támadónak és második alkalommal garantáltan felkészülten érkezik.
Teljes megoldást kínál a hardveres titkosítást biztosító merevlemez, de az ilyen egységek általában sokkal drágábbak mezei társaiknál. Aki ragaszkodik a szoftveres megoldáshoz, arra is van egy jónak tűnő problémaelhárítás.

A Kali Linuxot fejlesztő társaság az aktuális cryptsetuphoz fejlesztett egy patch-et, amellyel törölhetők a LUKS kulcsok. Működése a következő: meg kell adnunk a meglévő kulcsunkhoz egy nuke passphrase-t. Ha elindítjuk a rendszert és a nuke kulcsot adjuk meg, akkor az ÖSSZES kulcs törlődni fog a titkosított területről, olvashatatlanná téve az ott tárolt adatokat. Ennek következménye, hogy mi magunk sem fogjuk tudni olvasni azokat. E probléma áthidalására megoldható, hogy a kulcsunkat egy titkosított állományba tegyük pl. egy pendrive-ra, amit mindig magunknál tartunk. Szükség esetén a kulcsot visszaállíthatjuk a pendrive-ról és az adatok újra elérhetővé válnak.
Gyakorlati haszna lehet pl. hivatalos külföldi utaknál. Indulás előtt elmentjük a kulcsot, kinyírjuk, feladjuk a poggyászunkat. Ha útközben eltűnik a laptopunk, akkor csak az eszköz értéke veszteség, az adaté nem. Szerencsés célállomásra érkezés esetén visszaállítjuk a kulcsot és dolgozunk.

Felhasznált anyagok:
https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/http://www.kali.org/how-to/nuke-kali-linux-luks/

Szólj hozzá

Avatar
QR-kód
qrcode
Archívum
Kategória
+GER+ Warriors
+GER+ Clan Urban Terror Community