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...) |