Kétkulcsos rendszerek és a digitális aláírás

A kétkulcsos titkosítási rendszerek a modern kriptográfia alapját képezik, szinte mindenhol megtalálhatóak és a mai írásból ki is derül, hogy hogyan működnek és mi közük a digitális aláírásokhoz.

Tételezzük fel az alábbi egyszerű problémát: titkosítottan szeretne kommunikálni egymással Sanyi és Vilmos. Mivel a távolság nagy közöttük, ezért nem jöhet szóba az, hogy személyesen, négyszemközt megbeszéljék a titkosító kulcsot, amit használnának.

A Posta és egyéb kommunikációs formák szintén nem jöhetnek szóba, mivel ezek a módszerek kompromittálódhatnak, illetve itt már egy hatalmas rekurzióba/végtelen ciklusba kerülnénk, mert titkosított kommunikációnk beindításához titkosított átvitelre lenne szükségünk, mikor az nem létezik a jelen kontextusban.

Itt jönnek szóba a kétkulcsos rendszerek. Ezeket azért nevezzük két kucsosnak, mert két különböző, de matematikailag mégis összefüggő kulcsot alkalmaznak. Az egyik kulcs segítségével titkosítani lehet, míg a másik kulcs segítségével vissza lehet fejteni a titkosított üzenetet.

Ez megoldja az egykulcsos rendszerek esetén jelentkező kulcs csere problémáját. Az egy kulcsos rendszerek nevükből adódóan ugyanazt a kulcsot alkalmazzák titkosításra, mint annak a visszafejtésére. Ezeket is széles körben használjuk, részletesebben majd máskor lesz róluk szó.

A két kulcs megnevezése: titkos kulcs és publikus kulcs. A publikus kulcs felel a titkosításért. Nevét onnan kapta, hogy ez szabadon megosztható, mivel csak ennek az ismeretében nem fejthető vissza az üzenet. A másik, titkos kulcs felel a titkosított üzenetek visszafejtéséért. Ezt titokban kell tartani és nem szabad publikálni.

Az egyik legismertebb és legrégebbi ilyen algoritmus az RSA, ami a három fejlesztő kezdőbetűi után kapta a nevét (Ron Rivest, Adi Shamir és Len Adleman). Az eljárás prím számokat használ a titkosítás alapjául. A módszer dióhéjban abból áll, hogy választunk két nagy prím számot, amit p-vel és q-val jelölünk. Ezek szorzata, N lesz az összefüggés a két kulcs között. P, Q és N felhasználásával további műveletekkel képzünk két kitevőt. A kitevők egyike lesz a privát kulcs, a másik pedig a publikus kulcs. Innentől kezdve pedig az üzenetek kódolása egyszerű matematikai műveletek sorozata. A teljes leírás itt olvasható.

Az algoritmus kellően biztonságos, ha jól van kivitelezve, mivel egy kellően nagy számnak (N) több időbe telik megállapítani a prím tényezőit, minthogy megérje megpróbálni. Ez azonban nem azt jelenti, hogy nem lehetséges feltörni! Feltörhető abban az esetben, ha N nem elég nagy szám, illetve akkor is ha kulcs generálásnál hiba csúszik a rendszerbe és több kulcsnak is azonos a P vagy Q értéke és a támadó több publikus kulcsot is ismer.

Gyakorlatban a kellően nagy szám problémát úgy szokták kivitelezni, hogy N egy olyan szám szokott lenni, ami 2048 vagy 4096 bittel ábrázolható. Ez alatti bitszám esetén a gépek teljesítményének növekedése miatt simán Brute Force módszerrel visszafejthető lenne a titkosítás.

Az RSA algoritmus a 2000-es évek elejéig nem igen terjedt el, mivel fizetős szabadalom volt. Pontosabban az eljárás, amivel a betűkből álló sorozatot (szöveget) számmá lehetett konvertálni, az algoritmus használatához volt szabadalmaztatva. Viszont a szabadalom lejárta után rohamosan elterjedt. Manapság a legismertebb alkalmazása a HTTPS és a Digitális aláírások. Továbbá használhatóak még memória titkosításra és kód aláírásra is.

HTTPS

A HTTPS a HTTP titkosított változata, ami lényegében a webes adatátviteli protokollok közül a legnépszerűbb manapság. A sima HTTP szöveges adatokat visz át, legtöbbször ez HTML adat, de manapság HTTP felett továbbítunk zenét és hangot is képek mellett. De kezdjük az elején. Miért kell HTTPS?

A válasz abban keresendő, hogy a web térhódításával igen elterjedté váltak a webes alkalmazások. Ezekre számos példa hozható lenne, többségükre jellemző, hogy ha adatot kezelnek, akkor bizony bejelentkezés szükséges az oldalra. És itt a probléma. Ugyanis HTTP esetén ezek az adatok a nagyvilágban titkosítás nélkül utaznak tovább. Így a hálózat lehallgatásával könnyen lehet felhasználónevekhez és jelszavakhoz jutni nem titkosított adatforgalom esetén. Mondhatnánk, hogy ez különösebb szakértelmet igényel, de nem sajnos. Ha érdeklődés mutatkozik rá, akkor a jövőben lehet lesz erről is írás 🙂

Szóval a HTTPS ez ellen véd. A weboldal rendelkezik egy RSA kulcspárral és a böngésző is. A kapcsolódási folyamat esetén kicserélik egymással a publikus kulcsokat és már mehet is a titkosított kommunikáció, amit egy 3. személy nem tud visszafejteni, mivel nem fog rendelkezni egyik fél privát kulcsával sem.

Itt azonban felmerül egy probléma, méghozzá az, hogy honnan tudjuk, hogy az xy.com mögött valójában az xy.com szerver áll és nem valami eltérített jelszó lopó oldal? A megoldás egyszerű. A weboldal identitását ellenőrizni kell egy digitális aláírással, amit a böngésző a kapcsolódási folyamat elején tesztel. Ha az aláírás stimmel, akkor a weboldallal nincs semmi gond. Ellenkező esetben viszont probléma van, amit a böngésző jelez.

Hibából két fajta szokott felmerülni. Vagy az van, hogy a tanúsítványt ugyanaz írta alá, mint aki generálta (vagyis nem tekinthető megbízhatónak) vagy pedig a tanúsítványban beállított cím nem azonos a weblap címével (nagy valószínűséggel adathalászati kísérlet).

Kérdés az, hogy ki tanúsítja hogy a szerver megbízható és milyen módon ? Itt jön szóba a digitális aláírás.

Digitális aláírás

A digitális aláírások szintén kétkulcsos technológiát alkalmaznak, méghozzá a következő módon: tételezzük fel, hogy adott Sanyi és Kata. Sándor levelet küld Katusnak, és hogy Kata biztos lehessen afelől, hogy ő küldte a levelet, Sándor az üzenetéből képez egy hash összeget, majd a saját kulcspárjának a privát kulcsával kódolja ezt és ezt teszi hozzá az üzenethez. Itt azért a privát kulcs van használva az aláíráshoz, mert ezzel ideális esetben csak Sándor rendelkezik.

Kata a kapott levél identitásáról úgy tud megbizonyosodni, hogy a levélből dekódolja Sándor publikus kulcsával a Hash értéket, majd szintén kiszámolja az üzenet Hash értékét. Amennyiben a kettő egyezik, akkor az üzenetet valóban Sándor küldte.

A weblapok tanúsítványai szintén ilyen digitális aláírással készülnek. A tanúsítvány kibocsájtó a weblap domain címéből képez egy hash összeget, amit a böngésző dekódolni tud a kibocsájtó publikus kulcsának ismeretében. Ugyanez a módszer alkalmazható programok ellenőrzésére is, ott a fájl kód tartalmából képzünk hash értéket, amit hasonló módon titkosítunk. Ha menet közben módosul a kód (crack vagy valamilyen vírus miatt), akkor a számított ellenőrző összeg nem fog stimmelni a tárolt értékkel és ekkor megtagadhatja az operációs rendszer a program végrehajtását.

A privát kulcs tárolása lehet a problémás, sarkalatos pont minden rendszer esetében. A személyi igazolványok esetén a tárolás NFC chip segítségével (megjegyzem: itt nem olyan NFC van alkalmazva, ami egyszerűen leolvasható kommersz eszközökkel) van megoldva. Ez a közhiedelemmel és az összeesküvési elméletekkel szemben nem olvasható akármekkora távolságból. De mivel ez rádió jeleket használ, ezért fenn áll a veszélye annak, hogy valaki lemásolhatja a tudtunk nélkül, amivel nem tudna elméletben semmit se kezdeni, mert az adatok egy szimmetrikus kulcsos módszerrel titkosítva vannak, aminek a feloldásához PIN kód kell.

Viszont az élet bebizonyította már számtalanszor, hogy az elmélet nem azonos a gyakorlattal. Éppen ezért extra védelemként érdemes olyan pénztárcát vagy táskát venni, ami ilyesmi ellen védett és soha, de soha ne tároljuk a PIN kódot a személyi igazolványunk mellett.

Memória titkosítás

A titkosítás ilyen célú alkalmazására jó példa a Microsoft Xbox 360 rendszere, amiben a rendszer memória védelmének érdekében van alkalmazva. Minden indításkor a rendszer generál egy kulcspárt, aminek segítségével a rendszer memóriába kerülő adatokat titkosítja. Erre azért van szükség, mert ha nem így lenne, akkor relatíve egyszerűen lehetne a másolásvédelmet kijátszani. Csupán a rendszer memória buszra kellene ültetni egy áramkört, ami a RAM tartalmát a processzor és az operációs rendszer tudta nélkül módosítja és átírja a szükséges biteket a védelem kijátszására. Ezeket a megoldásokat nevezzük MOD chipeknek, viszont ezzel a megoldással ez kiiktatható.

Az Xbox azért jó példa, mert hiába gondoltak a gondos védelemre, nem számoltak azzal, hogy a hardver áttervezése problémákat okozhat. Az RGH hack lényegében azért lehetséges, mert az indítás után a HDMI audio illesztőre várva a processzor olyan állapotba hozható, hogy kinyerhető a titkosító kulcs, ami a rendszer védelmének összeomlásához vezet. A “vas” áttervezése/módosítása azért volt szükséges, mert mikor az Xbox megjelent, még nem létezett a HDMI szabvány, így a rendszer hang illesztője natívan nem tud HDMI számára audio jelet generálni. Ehhez egy külső áramkört építettek be, ami a “problémát” okozza.

A tanúsítvány aláírók

Tanúsítvány aláíró elméletben lehet akárki, ha a publikus kulcsát kellő mennyiségű szoftverbe be tudja juttatni 🙂 Ez azt jelenti, hogy ha én egy vállalkozást indítanék ilyen célokra, akkor a tanúsítványom nem lenne megbízható és nem érne semmit, egészen addig, amíg egy kritikus tömeget el nem tudnék vele érni. Ahhoz, hogy ez megtörténjen, a kibocsájtónak átláthatóvá kell tennie a működését, mert az aláírása csak addig jó, amíg azt ki nem tiltják szoftverekből. Továbbá a termékek forgalmazói pénzösszegeket is kérhetnek a tanúsítvány kibocsájtó publikus kulcsának telepítéséért/beépítéséért a rendszerbe. Szóval gyakorlatban nem is olyan egyszerű kibocsájtónak lenni.

Éppen ezért, mert ez anyagi javakat igénylő folyamat volt sokáig, nem volt mindenki számára hozzáférhető a HTTPS. Azonban ez változott a Let’s Encrypt mozgalom létrejöttével, ami HTTPS tanúsítványokat biztosít mindenki számára ingyenesen korlátlan mennyiségben. A tanúsítványok hátulütője, hogy nem annyira ellenőrzöttek, mint egy fizetős tanúsítvány, éppen ezért három havonta ezeket meg kell újítani, de ez egyáltalán nem bonyolult folyamat.

A weboldalam korábban Chrome alatt azért nem volt elérhető, mert a cég, akitől igényeltem a tanúsítványt, visszaélt a bizalommal, amit adtak neki és nem átlátható módon állított ki tanúsítványokat kétes célokra. Ezért a Google megvonta tőle a bizalmat és kitiltotta az általa aláírt tanúsítványokat a böngészőből.