Vissza
Bola Online
[
jhonthor683@gmail.com
|
http://dewabet.com
]
|
2016.09.24. 07:22:07
|
| Great website! It looks really professional! Sustain the great job! bandar bola | |
Alkalmazott kriptográfia – TrueCrypt
|
|
2009.02.07. 08:15:24
Földes Ádám Máté
Ez a bejegyzés egy hosszabbra tervezett, kriptográfiai témájú sorozat ötödik darabja. A bejegyzésekben nem bocsátkozom komoly elméleti fejtegetésekbe – csak a privátszféra védelme iránt érdeklődő laikus vagy szakmabeli számára potenciálisan érdekes dolgokat szeretném kifejteni. A sorozat előző darabja itt olvasható: http://pet-portal.eu//blog/read/84/2008-07-21-Aszimmetrikus-kriptografia.php/
Az eddigiekben a kriptográfiában használt algoritmusokról írtam, de kevés szó esett arról, hogy a gyakorlatban hogy néz ki a kényes természetű adatok védelme. A TrueCrypt nevű, népszerű rejtjelezőprogram bemutatásával szeretném ezt a hiányt pótolni.
A TrueCrypt (TC) egy nyílt forráskódú szoftver, melyet a TrueCrypt Foundation fejleszt 2004 óta. A program jelenleg a Windowst (egészen a Vistáig), a MacOS X Tigert és Leopardot, illetve a Linux platformot támogatja. A TC egy ún. „on-the-fly” vagy „on-line” rejtjelező, ami azt jelenti, hogy a szimpla fájlműveletekkel (pl. másolás vagy áthelyezés) egyidőben megy végbe az érintett állományok titkosítása.
Az alapkoncepció a virtuális meghajtókra épül. A véletlenszerű adathalmaznak tűnő rejtjelezett tartalom visszafejtéséhez megadjuk a kulcsot (ennek természetéről majd később), és kiválasztjuk a csatolási pontot (mount point). Ez utóbbi Windows alatt egy meghajtóbetűjel, míg Linux alatt egy könyvtár lehet. Ha a megfelelő kulcsot adtuk meg, a csatolási pont alatt egy teljesen hétköznapi fájlrendszert lát az operációs rendszer, vagyis minden fájlművelet illetve egyéb beavatkozás – mint például a töredezettségmentesítés – pontosan úgy megy végbe, mint egy nem rejtjelezett fájlrendszeren, épp csak a TC is beékelődik a rendszerhívások láncolatába a titkosított fájlokhoz való hozzáféréskor. A virtuális meghajtó leválasztása (dismount) után a rejtjelezett fájlrendszer teljes egésze újra biztonságban van.
A meghajtók kezelése ebben az ablakban történik
Háromféle adategységen lehetséges rejtjelezés: ún. konténerfájlon, partíción vagy rendszermeghajtón (vagyis olyan fizikai meghajtón, melynek egyik partícióján helyezkedik el a betöltendő operációs rendszer). Az első esetben a TC egy hétköznapi fájlt hoz létre az általunk kiválasztott helyen. Ez az állomány fogja tartalmazni a rejtjelezett fájlrendszert. A módszer előnye, hogy a fájlt könnyűszerrel másolhatjuk illetve mozgathatjuk. A második esetben egy partíciót „helyben” rejtjelezünk. Ez azt jelezti, hogy a partíció bármilyen jellemzője – mint amilyen a tartalmazott fájlrendszer típusa – a továbbiakban csak a TC-tel való visszafejtés után válik ismertté az operációs rendszer számára. Ez a koncepció kiküszöböli a konténer töredezettségéből adódó teljesítménydegradációt. A harmadik módszer talán a legérdekesebb: ilyenkor az egész meghajtó tartalmára kihat a rejtjelezés, beleértve például a partíciós táblát is. A meghajtó egyetlen titkosítatlanul maradó területe az első 512 bájt, ide kerül a TC saját betöltőprogramja (boot loader): ez felel a betöltés előtti hitelesítésért (pre-boot authentication), és az operációs rendszer betöltésének megkezdéséért. Érdekesség, hogy a TC rendszertöltő által kiírt szöveget testreszabhatjuk. Kiírhatunk olyan üzeneteket, mint például „Sérült/hiányzó rendszertöltő”, vagy teljes egészében le is tilthatunk bármilyen kimenetet. Ezzel a felületes támadókban eloszlathatjuk azt a gyanút, hogy a rendszermeghajtó rejtjelezve van, mert arra fognak gyanakodni, hogy a számítógép működésképtelen állapotban van.
Érdekesek továbbá a TC-ben használható kulcsok. Alapvetően jelszót és kulcsállományokat használhatunk a rejtjelezési mesterkulcs származtatásához. Utóbbi kategóriát általunk választott, szimpla, mezei állományok – például képek, szövegek – alkothatják. A kulcsfájlok méretére nincsen maximumkorlát, bár teljesítménnyel kapcsolatos okokból csak az első 1 megabájtjuk kerül felhasználásra a kulcsszármaztatáshoz. Ha több, a legkülönfélébb helyeken található kulcsállományt adunk meg a konténer létrehozásakor, sokat nyerhetünk a biztonság terén.
Hadd tegyek a kulcsfájlokkal kapcsolatban néhány megjegyzést. Egyrészt vigyázni kell, nehogy töröljük vagy módosítsuk a kulcsállományokat, különben minden valószínűség szerint könnyes búcsút vehetünk rejtjelezett adatainktól. Másrészt a kulcsfájl akkor igazán jó, ha annak hasznos részének nagy a „véletlenszerűsége” (pontosabban az entrópiája). Ezért hasznos a TC „véletlenfájl-generátora”, mellyel ideális kulcsállományt készíthetünk magunknak. Viszont a közel tökéletes véletlenszerűség felkeltheti egy támadó figyelmét – hol helyezzük hát el ezt a fájlt? Több jó válasz is lehetséges – az egyikről, valamint a TC technikaibb aspektusairól majd egy hét múlva írok.
Hozzászólások
Összesen 4 hozzászólás látható.
2016.09.24.
2009.02.15.
Földes Ádám Máté
|
2009.02.15. 15:07:52
|
|
Azt hiszem, mindkét kérdés nagymértékben releváns a téma szempontjából. A válaszaim: 1. Ahogy Gábor mondta, fontos különválasztani a felhasználási területeket. Nagyobb szervernél mindenképp érdemes beruházni valamilyen hardveres kriptográfiai gyorsítóba, így a titkosítással eltöltött processzoridő minimális. (Egyébként nemcsak szerverekben találkozni ilyen eszközökkel. Emlékeim szerint a VIA Epia alaplapokból is van olyan, amelyre integrálva van ún. Padlock Suite lapka, amely a kriptográfiai műveletek gyorsítására való.) Ha szoftverből oldjuk meg a rejtjelezést, az mindenképp plusz terhelést ró a CPU-ra. Hogy pontosan mekkorát, az sokmindentől függ, például a titkosítási algoritmusról. (Például ismereteim szerint a DES-be az első és az utolsó menetet azért rakták be, hogy szoftverből lassú legyen.) A TrueCryptben van egy benchmark eszköz, amely meg tudja mutatni, hogy adott algoritmussal mekkora adatsebesség érhető el maximum, csak és kizárólag a titkosításra vonatkozóan, nem számítva például a merevlemez sebességét. 2. Ha jól értem, akkor itt az a baj, hogy a szomszéd kulcsát a zárunkba belepróbálva nem nyílik az ajtónk.  A rejtjelezés "veszélyes üzem": ha elveszítjük a kulcsot, búcsúzhatunk az adatoktól. Ha a kulcs egy olyan TPM lapkában volt, amely már nincs a birtokunkban, hát... sajnos akkor úgy jártunk... A TrueCrypt dokumentációjában van egy Beginner Tutorial, mely pont az ilyen balesetek lehetőségére figyelmeztet, és útmutatást ad a program biztonságos használatához. Mindemellett persze nagyon fontos a gyakori adatmentés. (Nota bene, sokszor az is elegendő biztonság, ha az adatok a laptop utaztatása során biztonságban vannak - lehet, hogy otthon, esetleg lakásunk széfjében titkosítatlanul is tárolhatjuk a backupot.)Amit Gábor írt a TPM-ek hátsó ajtós problémájáról, egyáltalán nem alaptalan szerintem sem. Néha a felhasznált kriptográfiai algoritmus tartalmaz ilyet (például ettől féltek anno a DES esetében), néha az implementáció (lásd még például subliminal channel, key escrow, stb. problémakör). A nyílt forráskódú szoftverek azért jók, mert a másodikként említett rizikófaktort teljesen kizárhatjuk a forráskódba belekukkantva. Nyilvánvaló, hogy hardveres implementáció esetén nagyon problémás az ilyen jellegű ellenőrzés. Emlékszem például, hogy még egy hete sem dolgoztam jelenlegi munkahelyemen, amikor mondták a kollégák, hogy ne nagyon ájuljak el a laptopokon használt pre-boot hitelesítőtől - az ebédlőben erősen fülelve még a hozzá tartozó mesterkulcsot is meghallhatom... A notebookvedelem.hu ígéretesnek tűnik, még nem ismertem. Köszönöm a tippet! (Úgy látom viszont, hogy nem kell nekik az ember pénze: még szerdán megkerestem őket az egyik termékükkel kapcsolatban, de még nem válaszoltak...) |
|
2009.02.12.
Gulyás Gábor
|
2009.02.12. 10:40:40
|
|
Jó kérdések, talán Ádám ír majd ezekről a következő bejegyzés(ek)ben. Addig is leírom a véleményem. 1. Szerver környezetben szerintem célhardvert alkalmaznak (kriptokártyát, például), és nem szoftveres megoldásokat; ezért első sorban asztali környezetbe szánt megoldás. 2. A hardverekkel egy probléma van: nem open source. Márpedig így bármiféle kiskapu lehet bennük, vagy engedelmeskedhetnek a gyártó szuperkulcsának. Amerikában gyártott termékekben pedig van kiskapu (Bruce Schneier ír erről az Applied cryptography-ban), köszönhetően az NSA-nak. Különben nem engedik az exportot. Az open source termékekben pedig ez ellenőrizhető, bár ott is előfordulhat, hogy elég jól el tudnak rejteni egyes kiskapukat, amelyet csak később találnak meg. Kiskapu például. |
|
2009.02.09.
|
Tóth Tamás
|
2009.02.09. 16:07:01
|
|
A cikk olvasása során két dolog jutott eszembe: 1. Az ilyen titkosító technológiák milyen mértékben fogják vissza egy gép teljesítményét? Ez a kérdés nem feltétlen a személyi számítógépeknél jelentkezhet problémaként, hanem inkább a különböző szolgáltatások készítésénél. Teszem azt van egy szolgáltatásunk, amit másodpercenként 1000 felhasználó használ, így alapvetően nagy a szerver terheltsége; ha ehhez hozzátennénk még egy titkosítást is, hogy a felhasználók adatait védve tartsuk, akkor hány felhasználónyi teljesítményt vesztenénk? 2. Jó magam is kipróbáltam egy éve az új notebookomban lévő TPM chip-et, a cikkben is említett első módszert használva. Vagyis létrehoztam egy 20GB-os titkosított fájlt, melyet a Windows titkosított meghajtóként kezelt. Havonta jelszót kellett változtatnom ennek eléréséhez, illetve minden gépindításkor meg is kellett adnom a meghajtó betöltéséhez. Ezzel kapcsolatban két problémám is akadt: - ha sokáig nincs kikapcsolva a gép és havonta váltani kell, akkor idő közben elfelejthetem a jelszavam és oda minden adat, - ha a chip-et kicserélik, akkor szintén oda az egész védett adat. Ez utóbbi konkrétan megtörtént, mivel alaplapcserére szorult a gépem, viszont mint informatikusnak nyilván alapvető volt, hogy szerviz előtt lementsem az adatokat a védett részről - erről egyébként a szervizesek egy szót sem ejtettek, csak mikor rákérdeztem, hogy mi lesz, ha az cserélődik, és akkor mondták, hogy hát akkor előfordulhat, hogy elbukom az összes adatot. Véleményem szerint jók ezek a technológiák, viszont sajnos még mindig nagy körültekintéssel ajánlott kezelni őket. A megoldást pedig abban látom, hogy ezeket integrálni kellene már hardver szinten (HDD, RAM), de minimum operációs rendszernek kell hogy része legyen, ezek a 3rd party alkalmazások nem is feltétlenül megbízhatóak - mint egy nagyobb cég megoldása lenne (IBM, MS, stb.). Várjuk a fejleményeket Ui.: notebook fronton egy másik lehetőség: http://www.notebookvedelem.hu/?page=25 |
|
Új hozzászólás beküldése
Bárki hozzászólhat, nem regisztrált beküldő esetén egyik adat megadása sem kötelező - a hozzászólás akár névtelen is lehet.
Regisztráció 
