Privátszféra-barát identitásmenedzsment alkalmazása anonim böngészőkben. Dargó Sándor, Gulyás Gábor György

TECHNIKAI RIPORT, 2010.

Privátszféra-barát identitásmenedzsment alkalmazása anonim böngészőkben Dargó Sándor, Gulyás Gábor György Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Híradástechnikai Tanszék 1117 Budapest, Magyar tudósok körútja 2., I ép. IB 113. Telefon: +36 1 463–3227, Fax: +36 1 463–3263 e-mail: [email protected] Absztrakt A privátszféra-barát identitásmenedzsment egy általános privátszféra-védelmi eszköz, amelynek alkalmazása számtalan szolgáltatásban lehetséges. Jelen tanulmányban bemutatjuk az ezzel ekvivalens ún. részleges identitás technika modellt, és néhány javaslatot is kiemelünk, amelyek a kapcsolódó elveket részeiben átvették, bár a modell kialakítása előtt publikálták őket. A vizsgálatunk középpontjában azonban olyan konkrét privátszférát erősítő alkalmazások részletes elemzése áll, mint a szerepalapú identitásmenedzsment nyújtotta lehetőségek kiaknázása anonim böngészőkben. Részletesen megvizsgáljuk a területre jellemző támadó modellt és kritériumrendszert. Ezen túl további alkalmazásokra is kitérünk röviden, utalva a módszer általános alkalmazhatóságára. Kulcsszavak: profil, részleges identitás, privátszféra védelem, szerepalapú identitásmenedzsment 1. Bevezető A webes szolgáltatók alapvető célja, hogy mérni tudják a weboldalaik látogatottságát, és hogy minél pontosabban ismerjék a látogatók ízlésvilágát. E célból sokszor nem csupán oldalaikon belül készítenek statisztikákat, hanem más szolgáltatókkal (például auditszolgáltatók) is együttműködnek, amelynek következményeképpen a felhasználók egyedi azonosításra kerülnek, és a tevékenységük több munkameneten keresztül átívelő módon rögzítésre is kerül. Az azonosításra több technika is létezik, ezek jellemzően vagy a weblaphoz való hozzáférésnél felhasznált technikai jellemzők alapján próbálják azonosítani a felhasználót (pl. IP cím), vagy valamilyen azonosítóval próbálják meg ellátni a böngészőprogramot (pl. süti alapú azonosítás) [1].

1

DARGÓ SÁNDOR — GULYÁS GÁBOR GYÖRGY

A felhasználók azonosítását megakadályozó komplex megoldások az ún. anonim böngészők [2], amelyek segítségével az egyedi azonosításra alkalmas leírók eltüntethetőek. Lehetővé teszik a felhasználó számára az ún. teljes anonimitást: sem egy böngészési munkameneten belül, sem több munkamenet között nem lesznek összeköthetőek a felhasználó által meglátogatott lapok. Azonban ez a magas szintű azonosítottság (állandó azonosítókkal) és a teljes anonimitás által létrehozott kétértékű skála sokszor nem elegendő, és szükség lehet köztes szintekre is. Ilyen helyzet, amikor valaki csak az e-mail címét akarja felfedni, amellett, hogy ha a későbbiekben egy másik címet szeretne használni, akkor ne legyen a két cím ne legyen összeköthető. Az ilyen jellegű problémákra a jelenlegi anonim böngészők nem nyújtanak megoldást, és szükséges működésük kibővítése, átgondolása. E jelen tanulmányban a privátszféra-barát identitásmenedzsment (Privacyenhancing Identity Management, PIDM) alkalmazási lehetőségét mutatjuk be, mintegy lehetséges megoldásként erre a problémára. 2. Privátszféra-barát identitásmenedzsment Az identitásmenedzsment olyan rendszerek és folyamatok összessége, melyek segítségével szabályozható és irányítható, hogy a különböző felhasználók milyen körülmények között milyen erőforrásokhoz férhetnek hozzá, illetve róluk bizonyos helyzetekben milyen információt érhetőek el [3]. Többféle identitásmenedzsment rendszert különböztethetünk meg. A vállalati identitásmenedzsment rendszerekkel elsősorban a vállalati igényeket elégítik ki, és nem az egyén, hanem a vállalat gyakorolja az irányítást. Ezzel szemben léteznek felhasználó-központú identitásmenedzsment rendszerek, ebben az esetében olyan rendszerről beszélhetünk melynek keretien belül az egyén kezébe helyezik saját maga, saját adatinak sorsát. A továbbiakban felhasználó-központú identitásmenedzsment rendszerek állnak vizsgálódásunk középpontjában. Az identitásmenedzsment egyik típusa a szerepalapú privátszféra-védelem (Role Based Privacy, RBP) [4]. Az RBP nem új keletű dolog, már régóta és számos helyen alkalmazzák, az alapelvével pedig a hétköznapi életben is gyakorta találkozhatunk, hiszen a mindennapok során többféle szerepet is felvehetünk: vagyunk családtagok, munkatársak, fogyasztók (ezen belül is további szerepeket nevezhetünk meg), és ezeken kívül számos más szerepet is betölthetünk. A különböző szerepekben különböző információkat osztunk meg magunkról, ami a PIDM esetén úgy is megfogalmazhatunk, hogy különböző identitásokat rendelünk az egyes szerepekhez. Így például külön-külön beállíthatjuk internetes vásárlás esetén, hogy az eladó csak a vásárlási preferenciáinkat, a fizetést felügyelő fél csak a banki adatainkat, a szállító csak a címünket ismeri [5]. A szerepalapú privátszféra-védelem célja, hogy a felhasználó a PIDM által nyújtott több profil használata révén védhesse meg személyes adatait az illetéktelenektől. Ugyanis 2

PRIVÁTSZFÉRA-BARÁT IDENTITÁSMENEDZSMENT ALKALMAZÁSA ANONIM BÖNGÉSZŐKBEN

használatával több profilt hozhat létre saját maga számára a különböző szerepkörökhöz, és ő maga eldöntheti, hogy adott helyzetben melyik szerepkörének megfelelő profilját mutatja más felhasználók, szolgáltatók felé. A technika további kiemelt jellemzője, hogy lehetőséget nyújt a különböző szerepkörök függetlenítésére, ami jelentheti bizonyos információk fel nem fedését, illetve azt is, hogy a különböző profilokba ellentmondó információk kerülnek. Így elérhető, hogy a profilok nem lesznek összeköthetőek, és ez által megvalósítható az anonimitás több szintje is. A következő fejezetben a PIDM egyik lehetséges megvalósításaként ismertetjük a részleges identitás technika modelljét (angolul az ún. partial identities), majd bemutatjuk a PRIME [6], valamint az annak utódjaként elindított PRIMELife projekteket [7], melyek keretein belül az Európai Unió megcélozta a privátszféra-barát identitásmenedzsment kutatását és terjesztését. Ezek után további példák segítségével bemutatjuk a PIDM különböző felhasználási területeit, végül pedig a Nymity Slider koncepciót [8] ismertetjük, amelynek segítségével könnyebb értelmezni a PIDM-et alkalmazó rendszerekben megjelenő anonimitási szintek lényegét és szükségességét. 2.1. Felhasználói profilok particionálása A PRIME projekt keretein belül kidolgoztak egy olyan részleges identitás technikának elnevezett koncepciót, amelynek elsősorban az volt a célja, hogy a szolgáltató-felhasználó interakció során védelmet nyújtson a felhasználóknak Azonban a részleges identitások technika koncepció az alkalmazásokon belüli és alkalmazások közötti profil particionálást is lehetővé teszi, aminek a segítségével fel lehet oldani a felhasználó-barátságra és a privátszféra védelmére vonatkozó követelmények közötti ellentmondást. Ez az ellentmondás abban áll, hogy míg a testreszabhatóság a lehető legtöbb információt igényli a felhasználóról, addig ez a privátszféra védelmére vonatkozóan kifejezetten hátrányos tud lenni. 2.1.1. Részleges identitás technika A testreszabhatóság miatti problémának a megoldására dolgozták ki az úgynevezett részleges identitás technikát [9]. Ennek a lényege, hogy a felhasználó adatai különböző részleges identitásokba kerülnek szétválasztva, amelyek csak a tulajdonosuk által összeköthetőek. Ezek a részleges identitások úgy kerülnek kialakításra, hogy az adott környezetekben csak a szükséges adatok kerüljenek egy részidentitásba, így mindig csak a legszükségesebb információk kerülnek megosztásra garantálva a minimális mértékű adatszolgáltatást (ez az ún. data minimization).

3


A részleges identitás technika koncepcióján belül megkülönböztetünk alkalmazások közötti és alkalmazásokon belüli particionálást [10]. Előbbi esetében arról van szó, hogy az egyes alkalmazásokhoz külön identitások tartozhatnak, míg az utóbbi esetben egy alkalmazáson belül a felhasználó több identitással is rendelkezhet és emellett feltételezzük, hogy az alkalmazás képes a profilok logikai összekapcsolására (például automatikus profilváltás képében). Amennyiben az alkalmazáson belüli particionálás kerül implementálásra, úgy az alkalmazást ennek a döntésnek a fényében kell megtervezni és megvalósítani, egy utólagos modulként nem lehet hozzá illeszteni. Ennek a tervezési és megvalósítási elvnek az illusztrálására az 2.2. fejezetben bemutatjuk a BluES eLeraning alkalmazást, amely megvalósítja a részleges identitás technika koncepcióját [10]. 2.1.2. PRIME A PRIME (Privacy and Identity Management for Europe) egy olyan az Európai Unió által életre hívott komplex kutatási projekt volt, amely az internet felhasználók számára egy privátszféra-barát identitás menedzsment rendszer alapjainak meghatározását tűzte ki célul [6, 11]. A PRIME egy olyan rendszer létrehozását célozta meg, melyet az informatikában kevésbé jártas emberek is egyszerűen bizalommal használhatnak. Ennek a bizalomnak alapja az egységes és egyszerű kezelőfelület, valamint az, hogy senkibe se kelljen bizalmat helyeznünk ahhoz, hogy igénybe vehessünk egy szolgáltatást. Célja, egy olyan keretrendszer létrehozása volt, amely integrálja az összes technikai, illetve nem technikai aspektusát az IDM alapú privátszféra-védelemnek, tehát nem csak infokommunikációs, hanem jogi, szabályozási, szervezéstechnikai szempontokból is vizsgálta a privacy kérdését. A PRIME pontosan lehatárolta, hogy milyen interakciók mehetnek végbe a kommunikációs felek között, illetve meghatározta a lehetséges kommunikációs felek körét is. Emellett bemutatott egy a lehetséges interakciók és a privátszféra védelme által támasztott követelményeknek megfelelő szoftver-architektúrát és példát adott számos lehetséges felhasználási területre, úgy mint személyi tudakozó használata, kapcsolati hálózat kezelés, vagy éppen szolgáltatók helyzetalapú lekérdezése. A PRIME lehetővé teszi az általa meghatározott architektúra (PRIME Toolkit) segítségével, hogy a felhasználók interakciókat kezdeményezhessenek a PRIME rendszerében regisztrált szolgáltatók felé. A szolgáltató viszont a PRIME Toolkit egy implementációjának köszönhetően csak egy megszűrt adathalmazt kap meg, mivel a felhasználó szabályozhatja az általa felfedni kívánt információk körét.

4


A PRIME Toolkit további előnyei között tarthatjuk számon, hogy széles körű elterjesztése esetén megteremtheti azt a bizalmat, ami az elektronikus kereskedelemből mind a mai napig sok esetben hiányzik, valamint kiküszöbölheti, hogy jelenleg az egyes alkalmazások eltérő interfészekkel rendelkeznek, és ezáltal csak nehézkesen vagy egyáltalán nem automatizálhatóak az adatbeviteli folyamatok. Ezeken túlmenően pedig még meg kell említeni, hogy a PRIME Toolkit az egyes munkaállomások rendszere felé épül, azaz alatta lévő felfedezett biztonsági réseket és hibákat ki lehet küszöbölni a Toolkit módosítása nélkül is, illetve lehet frissíteni az alsóbb rétegeket. 2.1.3. PRIMELife A PRIMELife, ami a PRIME projekt folytatása, céljául tűzte ki, hogy fenntartható privacyés identitásmenedzsmentet biztosítson a jövő hálózatainak és webes szolgáltatásainak [7]. A két fő terület, amire választ kíván adni: • egyrészt az, hogy hogyan oldható meg a privátszféra védelme, amikor egyre jobban terjednek az egymással együttműködő webes szolgáltatások és a virtuális társadalmak, • másrészt pedig, hogy hosszútávon hogy lehet fenntartani a privátszféra épségét. A PRIMELife igyekszik választ adni ezekre a kulcskérdésekre, amik a privátszférát és a bizalmat érintik. Ahhoz, hogy ezeket a problémákat meg lehessen oldani, kezelni lehessen, a PRIMELife fejleszteni kívánja az ember-számítógép közötti kapcsolatot biztosító felületeket, az automatizmusok személyre szabhatóságát, a különböző webes szolgáltatók együttműködését és a privátszféra-védelmet növelő kriptográfiai eljárásokat. Másrészről a PRIMELife projekt céljául ki lett tűzve ezeknek a technológiáknak széles társadalmi körökben való elterjesztése. Ebből a célból a projekt részvevői együttműködnek a legjelentősebb nyílt forráskódú projektekkel, fejlesztőkkel. 2.2. BluES Az alábbi alfejezetben bemutatjuk a BluES eLearning alkalmazást az adatvédelem szempontjából támasztott elvárások szerint megközelítve azt [12]. Azért választottunk egy eLearning alkalmazást az identitásmenedzsmentet használatát illusztrálandó további példaként, mivel az általa kezelt probléma elég komplex ahhoz, hogy számos aspektust vizsgálhassunk. A leglényegesebb ok azonban az volt, hogy a BluES a gyakorlatban alkalmazza az alkalmazáson belüli részleges identitások technikát.

5


2.2.1. A BluES funkciói Egy eLearning környezetben a felhasználók számos use case-en belül rendelkezhetnek 1 különböző szerepekkel, a BluES kapcsán ezek a use case-ek : a tanulás, az oktatás és a publikálás. Ezen területeken belül négy különböző szerepet különbözetünk meg, úgy mint az adminisztráció, tartalom-menedzsment, közös munka és anonim böngészés az oldalon. A BluES több különböző tanulási módot támogat, lehetővé teszi az osztályokban való, illetve az egyéni tanulást, valamint a dinamikusan változó csoportok segítségével zajló oktatást. Mivel a csoportos tanulás lehetőséget biztosít többek között kommunikációra, ezért lehetővé kell tenni a felhasználók számára, hogy szabályozhassák milyen mennyiségű és minőségű személyes adatot kívánnak felfedni magukról. 2.2.2. A privátszféra és a megvalósított funkciók ellentéte Ha jobban szemügyre vesszük a felsorolt szerepeket és felhasználási lehetőségeket, szembe tűnik, hogy a privátszféra és az alkalmazás személyre szabhatósága szöges ellentétben áll egymással. Vegyük példaként a dinamikusan változó tanulói csoportok esetét. Amikor egy ilyen csoport megalakul, előnyös volna, ha potenciálisan érdeklődő felhasználók értesítést kapnának róla. Ehhez azonban elengedhetetlen, hogy a rendszer adatokkal rendelkezzen az egyes felhasználók preferenciáiról. Továbbá nem csak a rendszerről magáról, de az oktatókról is elmondható, hogy abban az esetben nyújthatják a legjobb teljesítményt, ha minél nagyobb mértékben ismerik a felhasználókat (tanulókat). Ennek az ellentmondásnak a kiküszöbölésére a BluES a személyes adatok particionálását alkalmazza. 2.2.3. Az adatok particionálása kontextusok révén Erre a bizonyos particionálásra a BluES az úgynevezett kontextusokat vezette be. A kontextusok olyan helyzeteket, szituációkat jelölnek, amelyekben a felhasználók végrehajtanak egy-egy feladatot. Az alkalmazásnak meg kell tudnia határozni mind az aktuális kontextust, mind pedig a felhasználó várható cselekedetét. Amikor a felhasználó új tevékenységen kezd el dolgozni, akkor kontextus-váltásról is beszélünk. A kontextusok meghatározása különböző az egyes felhasználókra nézve, mivel gyakorlatilag a különböző tevékenységek elkülönítését értjük alatta. Ugyanakkor az is igaz,

1

A use case a szoftver- és rendszertervezésben használt fogalom annak a leírására, hogy hogyan

viselkedik a rendszer egy azon kivülről származó kérésre. Később az Unified Modeling Language-ben bevezették a use case diagrammok használatát, amelyek célja, hogy grafikus áttekintést adjon arról, hogy mit kell tudnia a rendszernek, milyen elvárt viselkedési mintákkal bírjon.

6


hogy az alkalmazás felépítése is előre meghatározza, hogy egyáltalán milyen kontextusváltások lehetségesek. A kontextus-váltások magukban hordozzák az azonosító-váltások lehetőségét, azonban egy váltás esetén jól meg kell gondolni, hogy mennyire lesz összeköthető a korábbi és az új használt azonosító, mivel egy man in the middle jellegű támadó könnyen meghatározhat anonimitási halmazokat, amelyek által le tudja szűkíteni, hogy kihez is tartozhat egy-egy pszeudonim. Ha valamire más névvel hivatkozunk, mint a valódi neve, tehát a valóstól eltérő azonosítót használunk, akkor azt pszeudonim azonosítónak nevezzük. A BluES egy négyváltozós modellt használ a kontextusok leírására, ahhoz pedig hogy két kontextust meg tudjunk különböztetni, legalább egy változó értékében el kell térniük. A változók egyrészt a különböző use-case-ek leírására, valamint az előzmények és a kommunikációban részt vevő partnerek tárolására vonatkoznak. Amikor egy felhasználó egy tranzakció során kommunikál a szerverrel, az alkalmazás értékeli, hogy szükséges-e kontextus váltás. Ennek három különböző eredménye lehet, aszerint, hogy a kontextus-váltás csak lehetőség-e vagy kötelezően végre kell hajtani, utóbbi esetnél pedig azt is figyelembe kell venni a kiértékelés során, hogy a váltás azonnal megtörténik-e, vagy csak később. A kontextus-váltások szükségességéről, illetve megtörténtéről a BluES értesíti a felhasználót a beállításoknak megfelelően. Ezen beállítások meghatározására több különböző megközelítés áll a felhasználó rendelkezésére: meghatározhatjuk előre, a várakozásaink alapján, ebben az esetben a felhasználó még azelőtt meghatározza a kontextusokat, és azokat a pontokat, amikor a váltások szükségesek. Ebben az esetben a meghatározott kontextusok és beállítások az egész munkamenet során érvényben maradnak, az alkalmazás pedig a felhasználó értesítése nélkül elvégzi a váltásokat. Ezzel szemben a második esetben a beállítások elvégzése a használattal párhuzamosan történik meg, minden egyes tranzakció során a felhasználónak egy döntést kell meghoznia arról, hogy kíván-e kontextust, illetve részleges identitást váltani. A harmadik esetben minden egyes tranzakció kontextus- és részleges identitásváltással jár, a felhasználó visszamenőleg kötheti össze az egyes kontextusokat és részleges identitásokat. Ezen módszerek az általunk bemutatandó alkalmazás kialakítása során is felhasználhatóak, például a profil-hierarchia felépítése, kezdeti kialakítása során. Alaposan szemügyre véve a három különböző megközelítést, belátható, hogy mindegyik rendelkezik előnyökkel és hátrányokkal, azonban önmagában csak az egyik stratégiát alkalmazva nem lehet hosszú távú sikert elérni, javallott egyfajta hibrid modell használata. Erre egy alkalmas megközelítés miszerint a felhasználók letölthetnek előre meghatározott

7


konfigurációs csomagokat, majd ahogyan jobban megismerkednek az alkalmazásokkal, lehetőségük nyílik tetszésük szerint megszabni a beállításokat. 2.3. Privátszféra-barát identitásmenedzsment más alkalmazásokban Több, saját korát megelőző alkalmazásban is találkozhatunk a szerepalapú privátszféravédelemhez, valamint a részleges identitás technikához hasonló technológiával. Az egyik legkorábbi, a privátszféra-barát identitásmenedzsment alapkoncepcióját is érintő próbálkozás a Reachability Management System (RMS) volt, amely a mobiltelefonokról indított hívásokhoz kapcsolódó információk kezelését szabályozta [13]. Az RMS rendszer bevezette a profil fogalmát, és lehetővé tette, hogy a hívásindítás előtt a felhasználó beállítsa azt. A profil olyan információkat foglalhatott magában, mint a hívó állapota (státusz), és a hívás tárgya, illetve ezek mellett kiválaszthatta, hogy milyen identitásként jelenjen meg a hívott fél felé. A környezet jellegéből fakadóan azonban erős korlátok között mozgott a javasolt rendszer, például a profilinformációk csak híváskor kerültek megosztásra, valamint a rendszerre az alacsony felhasználók közötti aktivitás volt a jellemző. További hátrány, hogy az RMS rendszer ugyan támogatta a hívó anonimitását, de az identitások összekapcsolhatóságával nem foglalkozott. Az iManager hasonlóan korai koncepciója [14] már közelebb visz a privátszféra-barát identitásmenedzsmentet alkalmazó internetes szolgáltatások felé. Ez esetben egy URL alapú tűzfal-szerű alkalmazásról van szó, amely megfigyelve a hálózati forgalmat képes közbeavatkozni, és csak a kiválasztott identitásnak megfelelő információt átengedni (vagy arra lecserélni), így megvalósítva az identitásmenedzsmentet a szolgáltató irányába. A szűrési és csere mechanizmus leginkább a webes forgalom kezeléséhez alkalmas, de a koncepció más szolgáltatás típusokra is kiterjeszthető, habár a modell sok esetben tovább finomítást igényel, mivel az URL alapú vezérlés nem a legfinomabb granularitást biztosítja. A Privacy Studio első sorban a felhasználók közötti privátszféra-barát identitásmenedzsmentre javasol egy modellt, méghozzá környezet-érzékeny mobiltelefon alkalmazásokhoz [4]. Az identitásmenedzsment szoftver több szinten kezeli a megosztott profilinformációkat: az ismerős felhasználókat csoportokba lehet sorolni, és minden csoportnak is más profilt lehet beállítani. A profilokat manuálisan, vagy akár eseményvezérelten is lehet aktiváltatni, és ez utóbbinál például időzítők (naptár), vagy helyfüggő szolgáltatások is kiválthatnak profilváltást. A tárgyalt identitásmenedzsment technika alkalmazását csevegő szolgáltatásokba függetlenül munkálkodó kutatók szinte egyszerre javasolták [12, 15]. A [12] cikkben elsősorban a részleges identitás technikának a szerepalapú hozzáférés-szabályozással való kiegészítését tárgyalják, amelyben kitérnek arra is, hogy hogyan lenne megvalósítható ez 8


egy csevegő szolgáltatásban, amelyet a szerzők Privacy-Enhanced Adaptive Communicator (PEAC) néven kereszteltek el. Cikkükben azt tárgyalják, hogy az egy részleges identitás kiválasztása, és a hozzáférés-szabályozás hogyan lenne megvalósítható egy ilyen rendszerben. Ezzel szemben a [15] cikkben egy olyan általános csevegő szolgáltatás modellje kerül ismertetésre, amely a létező csevegő szolgáltatások modelljét egészíti ki a privátszféra-barát identitásmenedzsment lehetőségével, hogy lehetővé tegye az anonimitást és az összeköthetetlenséget a felhasználók számára. 2.4. Nymity Slider koncepció A PIDM lehetőséget ad, hogy szabályozzuk az egyes felek számára megosztott információkat. A Nymity Slider [8] egy csúszkán értelmezett koncepciója megmutatja, hogy miért van szükség erre a szabályozásra egy egyszerűen elven keresztül: jellemzően csak több információ felfedésére van lehetőség, visszavonásra nem. Ez azt jelenti, hogy az egyre inkább azonosított állapot felé tudunk csak haladni, a másik irányba nem. A kapcsolódó anonimitási, azaz azonosítottsági szinteket mutatja a csúszka négy fokozata.

1. ábra. A Nymity Slider csúszka koncepciója.

A csúszka egyik szélén található a teljes anonimitás, és a másikon az egyértelmű személyazonosság. Teljes anonimitás alatt azt értjük, hogy a felhasználó minden cselekedete, megjelenése azonosítóhoz nem köthető, és ezek semmilyen módon sem összekapcsolhatóak – tehát semmilyen személyes adat nem kerülhet megadásra. Egyértelmű személyazonosság esetén pedig olyan adat kerül megosztásra, ami kizárólag az adott személyre vonatkozik, és pontosan azonosítást is lehetővé tesz. Összeköthetetlen azonosítás esetén már ugyan rendelkezik a felhasználó valamiféle azonosítóval, de azt az egyes tranzakciók között lecserélheti. Amíg viszont nem változtatja meg, a különböző akciók, megosztott információk az adott azonosítóhoz kapcsolódnak majd. Az állandó azonosítás esetén ez az azonosító egyedi, azaz nem lehet csak úgy lecserélni – a felhasználó kénytelen bizonyos esetekben azt használni, mindamellett, hogy az globálisan azonosítja őt. 9


Az összeköthetetlen azonosítás jellemző például az előre feltöltendő (pre-paid), bárki által megvásárolható SIM kártyákra, amelyeknek a telefonszámra bármikor lecserélhető. Ezzel szemben az állandó azonosítás esetét ahhoz hasonlíthatjuk, amikor valaki rendszeresen egy adott álnéven publikál (amelyet más nem tud megszemélyesíteni), és mindenki tudja, hogy az adott álnéven milyen cikkek kerültek megírásra, de azt senki sem tudja a szerzőn kívül, hogy az álnév mögött a valóságban ki bújik meg. Goldberg alapvetése, hogy ha valaki több információt oszt meg, akkor egyre jobban azonosíthatóvá válik, és onnan már csak nagyon nehezen lehet az előző szintre visszatérni. Tehát a csúszka egyirányú. Ebből kiindulva a cél a lehető legkevesebb információ felfedése, a lehető legmagasabb anonimitási szint megőrzése, hogy innen a felhasználó dönthesse el, milyen adatokat fed fel, hogy ő határozhassa meg a kívánt anonimitási szintet a későbbiekben is. Az identitásmenedzsment alkalmazása során is szükséges erre figyelni, és a felhasználó számára lehetővé kell tenni, hogy amikor elkezd böngészni, akkor garantált legyen számára a teljes anonimitás, majd innen kiindulva ő dönthesse el, hogy mennyi adatot kíván felfedni magáról a szolgáltató felé, illetve mekkora mértékben szeretne anonim maradni. 3. Anonim böngészés az interneten Az internet böngészése során megosztott számos információ kiszűrésére anonim böngészést támogató szolgáltatásokra van szükség [2]. Ezek a szolgáltatások többféle osztályba sorolhatóak működésük elve szerint, illetve jelentősen eltérnek attól függően, hogy milyen funkciókat nyújtanak, és milyen információkat szűrnek meg, amelyek a webet böngésző felhasználóról kerülnének közlésre, illetve annak a számítógépére kerülnének letöltésre [1]. A legegyszerűbb ilyen szolgáltatások az anonim proxy-k, amelyek jellemzően egyszerű szűrést megvalósító proxy kiszolgálók. Működésük lényege, hogy a kiszolgáló és a böngésző fél közötti kommunikációba harmadik félként beépül. Mivel így a kiszolgáló közvetlenül a proxy szerverrel áll kapcsolatban, a tényleges böngésző IP címe a szerver elől rejtve maradhat. Bizonyos esetekben egyszerű szűrési funkciókat is nyújtanak, mint például bizonyos HTML elemek szűrése. Ennél összetettebb anonim böngészést biztosító szolgáltatások az anonim böngészők, amelyeknek két fő típusa van: web és kliens alapú. A web alapú anonim böngészők egy bizonyos URL-re ellátogatva érhetőek el, és ezek esetén a privátszféra védelmet megvalósító funkciók általában a kiszolgáló oldalán vannak megvalósítva. A kliens alapú anonim böngészők privátszféra-védelmi kiegészítőkkel felvértezett web böngésző 10


alkalmazások, amelyekben valamennyi funkció kliens oldalon található meg, és általában nem igényelnek egy központi kiszolgálót a szolgáltatás működéséhez. Mivel például a felhasználót jól azonosíthatja az IP címe, vagy akár a böngészőjét, rendszerét leíró információk halmaza [21], ezért a kliens alapú anonim böngészők – szemben a hagyományos böngészőkkel – ezeket az információkat nem teszik közzé. Az IP címet például anonimizáló hálózattal [16], a böngésző- és rendszerleíró információkat pedig a böngésző beállításainak módosításával rejtik el. Ezekre a szolgáltatás típusokra taxonómiát és összehasonlítást ad az [1]. A taxonómiát kibővíthetjük a privátszféra-barát identitásmenedzsmentet is alkalmazó anonim böngészőkkel is, amelyet a könnyű bővíthetőség miatt a kliensoldali böngészőkben lehet elhelyezni, és az így kapott taxonómiát adja a 2. ábra.

2. ábra. Szolgáltatás típusok taxonómiája.

A PIDM-et is megvalósító anonim böngészők legtöbb tulajdonsága a hagyományos kliensoldali anonim böngészőkével egyezik, és a legfőbb eltérés a nyújtott anonimitási szintben tapasztalható meg (ami egyben a szolgáltatás típus fő funkciója is). Ezzel, illetve az anonimitás erősségével kibővített összehasonlító táblázat mutatja a taxonómia szolgáltatás típusainak összehasonlítását a [1] alapján.

11

DARGÓ SÁNDOR — GULYÁS GÁBOR GYÖRGY 1. táblázat. Szolgáltatás típusok összehasonlítása.

Anonim proxy-k

Web alapú anonim böngészők

Kliens alapú anonim böngészők

Anonim böngészők PIDM-mel

Hálózati anonimitás

IP és Port maszkolás

Szűrő funkciók

(Szerver oldali)

Szerver oldali

Kliens oldali

Süti kezelés

-

Szerver oldali tárolás, szűrés, blokkolás

Szűrés, blokkolás

Gyorsítótár, előzmények, stb. védelme

-

Szerver oldali védelem

Kliens oldali kezelés

Cenzúra védelme

-

Dedikált belépési pontok

Dedikált és kliensoldali alternatív belépési pontok

Beállítás nehézsége

Böngésző beállítása

Web proxy

Lokális proxy

Hordozhatóság

Teljes (független)

Böngészőfüggő

OS függő

Anonimitás szintje Anonimitás védelme

Biztonságos csatorna, MIX szolgáltatás

Teljes anonimitás, PIDM is

Csak teljes anonimitás

Gyenge

Közepes

Erős

A PIDM-et nyújtó anonim böngészők alapelve a Nymity Slider koncepción alapszik. Teljes anonimitást nyújtó kliensalapú anonim böngésző ezeknek az alapja, ezért lehetőség van a felfedett információk aprólékos szabályozására, amit az identitásmenedzsment valósít meg. 4. Követelmények Egy identitásmenedzsment rendszert támadó személy legfőbb célja az lehet, hogy minél több eredetileg privátnak szánt információt ismerjen meg a felhasználókról. A következő fejezetben összefoglaljuk, hogy milyen eredménnyel zárulhat egy támadás, majd a fejezet 12


második részében bemutatjuk azokat a követelményeket, amelyeknek meg kell felelnie a böngészőnek, hogy a támadások védhetőek legyenek. 4.1. Támadó modell A támadó modell szereplői ez esetben is megegyeznek a hagyományos támadó modell szereplőivel [2]. A legfontosabb szereplő a felhasználó, akinek jelen esetben kiemelt célja, hogy szabályozhassa, hogy mely felek milyen információt érnek el róla, és célja lehet akár az is, hogy az egyes felekkel ellentmondó információkat osszon meg. Valamennyi többi szereplő (hirdetők, webes üzletek, adatgyűjtők, szolgáltatók és cenzúrázó szervek) a felhasználó privátszféráját sértő célja vagy az információk gyűjtése, azok korlátozása, vagy a gyűjtött információkkal való visszaélés lehet. Ha identitásmenedzsment rendszert vizsgálunk, a támadó legfőbb célja az lehet, hogy a jelenlévő identitások vizsgálata által új, eredetileg privátnak szánt információt ismerjen meg a felhasználókról, amelyből később üzleti haszna származhat. A különböző szokások feltérképezése által jobban személyre lehet szabni az egyes alkalmazásokat, de ugyanakkor, ha sikerül kideríteni, hogy ki van több különböző identitás mögött, a megszerzett információ alkalmas lehet zsarolásra, vagy lejáratásra is. Egy támadás többféle eredménnyel zárulhat. Teljes siker esetén a támadó nem csupán azonosítani tud egy felhasználót, hanem kiterjedt információkra is szert tesz róla. Ezzel szemben, amennyiben csak egyszerű sikert ér el a támadó, akkor nem rendelkezik az azonosított áldozatról széleskörű információkkal, csupán egy hiányos profilt tud róla felépíteni. Az, hogy egy támadást legalább részben sikeresnek nyilváníthassunk, nem követeli meg, hogy a támadó egyértelműen azonosítani tudja áldozatát. Részleges sikernek tekinthetőek azok az esetek is, amikor a támadó össze tud kötni két megszerzett profil információt, egy személyhez tudja kötni őket, anélkül, hogy tudná, hogy ki is az a személy. Emellett ugyanilyen módon részleges siker az is, ha a támadó le tudja csökkenteni azon lehetséges személyek számát, akik közül kikerülhet az általa támadott profil tulajdonosa. A támadások kivitelezésére több módszer létezik. Egyrészt feltételezheti a támadó az alkalmazott anonim böngésző gyengeségét, és megpróbálhatja valahogy megjelölni, azonosítani a felhasználót. Ha ez sikerrel jár, akkor az nem az identitásmenedzsment, hanem az anonim böngésző gyengesége. Azonban ez előbbi is támadható: lehetőség van hasonlóság keresésére az egyes azonosítók között, illetve a profilinformációk összehasonlítása alapján is lehetőség van a profilok közötti kapcsolatok felfedezésére

13


(például ha két profilban egyezik az email cím, akkor egyértelműen egy tulajdonosé a kettő). Ezen kívül ügyelni kell a meta-információkra is. Gyanús lehet, ha például egy webes üzletbe két azonosítóval mindig ugyanabban a sorrendben, egymás után lépnek be – ez szintén a közös tulajdonosra utalhat. 4.2. Követelményrendszer Ahhoz, hogy sikeresen implementálni lehessen egy felhasználó-központú identitásmenedzsment rendszert, elengedhetetlen, hogy a böngésző garantálja az anonimitást, lehetővé tegye a felhasználó számára azt, hogy ne kelljen felfednie magáról semmilyen adatot, ha az nem áll szándékában. Azonban egy ideális rendszer megvalósításához számos egyéb követelményt is figyelembe kell venni a tervezés során, például, hogy nem hagyhat a felhasználó nyomot maga után a számítógépen, amin futtatja az alkalmazást, vagy hogy az általa használt azonosítók egyszerre biztonságosak és felhasználóbarátok is legyenek. Az alábbi fejezetben az alkalmazással szemben támasztott követelmények részletesen bemutatásra kerülnek. 4.2.1. Anonimitás A rendszer egyik kiemelkedő fontosságú alapkövetelménye, hogy képes legyen a teljes anonimitás biztosítására, hiszen ezen alapvető feltétel nélkül értelmét vesztené az identitásmenedzsment rendszer. A „képes legyen” megfogalmazás használatát azért tartjuk fontosnak, mivel nem elengedhetetlen feltétel, hogy a felhasználó minden esetben teljesen anonim maradjon. Az alkalmazásnak a felhasználóra kell bíznia az anonimitás szükségességéről szóló döntést, azonban, ahol és amikor a felhasználó szeretne anonim maradni, az alkalmazásnak ezt a lehetőséget garantálnia kell. Az általunk használt megközelítésben [1] a teljes anonimitás egy összetett fogalom, több egymásra épülő elemből áll össze. Egyrészt fontos hangsúlyozni, hogy a kommunikáció tartalmát csak a részvevők ismerhetik, más fél nem férhet hozzá ezekhez a tartalmakhoz, azaz a kommunikációs csatorna megfigyelhetetlen. Ezen túlmenően teljesülnie kell az összeköthetetlenség kritériumának is, azaz egy külső figyelő nem lehet képes annak a megállapítására, hogy két üzenet egy felhasználótól származik-e. Azonban, ha egy felhasználó különböző tevékenységei össze is köthetőek, legfeljebb egy fedőnévhez, vagy egyéb azonosítóhoz kapcsolódhatnak, ami alapján a valódi személyazonosság nem deríthető ki, tehát az azonosításnak pszeudonimnek kell lennie. Végül pedig szükséges, hogy a felhasználó cselekedetei még viszony szinten se lehessenek összeköthetőek. Ez a

14


úgy teljesülhet, hogy a felhasználó tranzakciónként független pszeudonim azonosítóval rendelkezik, ami által teljesül a teljes körű anonimitás. Azonban egy PIDM nyújtását célul kitűző alkalmazás esetén nem elegendő a teljes anonimitás nyújtása, meg kell tudni valósítani azt az átmenetet, amiről a Nimity Slider kapcsán már említést tettünk. Ezt a bizonyos átmenetet a teljes azonosíthatóság és a teljes anonimitás között pedig a részleges identitás technika alkalmazásával kívánjuk megvalósítani, amit 2.1. fejezetben már részletesen ismertettünk. Az anonimitási szinteket kiegészítendő, ahhoz kapcsolódó böngészővel szembeni további kritériumok segítenek, hogy a böngésző a valóságban is anonim lehessen. 4.2.2. További kritériumok Hordozhatóság. A használt böngésző hordozhatóságán azt értjük, hogy futtatható legyen egy hordozható tárolóegységről, anélkül, hogy az éppen használt gépre telepíteni kelljen. Ezáltal nem hagyunk nyomot a böngészőt futtató gépen. Kliensoldaliság. Ellentétben egy webes alkalmazás esetével, nem okoz problémát az alkalmazás elérhetősége, ráadásul több beállítást egyszerűbben kezelhet a felhasználó. Hátránya, hogy az alkalmazás operációs rendszer függő lesz. Alkalmazási rétegen belüli szűrés. Kliensoldalon az alkalmazási rétegen belül szűrhetők legyenek bizonyos tartalmi elemek, például JavaScript, Java alkalmazások, Flash és Silverlight elemek, web poloskák. Sütikezelés. Fontos, hogy ne csak a blokkolás legyen beállítható, hanem emellett széles körű paraméterezhetőség is profilonként biztosított legyen. Amellett, hogy a felhasználó szűrhessen oldalakra, lejárati dátumokra, lehetővé kell tenni az egy munkamenetre való engedélyezést is. Cenzúra elleni védelem: A böngészőnek védelmet kell biztosítania a cenzúrázó szervek ellen, amelyek bármely információáramlással kapcsolatos szolgáltatók közül kikerülhetnek, de lehet akár szó a munkáltatóról, vagy állami felügyeleti szervekről is. A cenzúrás sok esetben megkerülhető anonim böngészők használatával [2], azonban bizonyos esetekben a munkáltató kizárása nem lehetséges, például tartalom alapján szűrő proxy alkalmazása során.

15


Hálózati anonimitás: Elvárás a böngésző felé, hogy hálózati szinten biztosítsa az anonimitást a felhasználók felé, azaz az IP címét elrejthesse a partnerei elől. Erre egy lehetséges mód az úgynevezett mix-hálózatok használata [16]. 4.2.3. Identitásmenedzsment A böngészőnek lehetővé kell tennie, hogy definiálhassunk identitásokat és meghatározhassuk, hogy az egyes identitások mely oldalhoz, oldalakhoz tartozzanak. A létrehozott identitásokhoz pedig tudnunk kell hozzárendelni adatokat, melyeket felfedhetünk magunkról, melyeket használni kívánunk a böngészés során. Emellett a különböző biztonsági beállításokat is profilonként külön-külön kell tudnunk tárolni. Fontos, hogy az identitások generálása, azok karbantartása egyszerű módon történjék, hogy a felhasználó ne tehernek érezze az identitásmenedzsment használatát, hanem segítségére lévő lehetőségként. Lényeges az is, hogy kiterjedt paraméterezhetőséggel rendelkezzünk az identitásváltásokat illetően, biztosítani kell a manuális és automatikus váltások lehetőségét is a felhasználó számára. Az identitásmenedzsment kapcsán mindenképpen meg kell említeni az egyes identitásokhoz tartozó azonosítókat. A pszeudonimekhez kapcsolódóan a két legfontosabb követelmény, hogy lehetővé tegyék a tulajdonosuk valódi identitásának elrejtését, valamint, hogy a felhasználók számára is egyszerű legyen a használhatóságuk [17]. Sajnos ezek a követelmények ellentétesek lehetnek egymással. A legnagyobb biztonságot a teljesen véletlenszerűen generált azonosítók jelentik, azonban ezeket nehéz használni. Ezzel szemben, ha a felhasználók saját maguk számára választanak pszeudonimeket (pl: dsanyi85), azok önmagukban alkalmasak lehetnek arra, hogy a támadó jelentősen leszűkítse az anonimitási halmazt. Ezért célszerű egy olyan hibrid megvalósításra törekedni, amely alkalmas egyesíteni a két módszer előnyeit és kizárni az ismertetett hátrányokat. Erre egy olyan javaslatot találunk a [17]-ben, amely alkalmazza a véletlenszerű pszeudonimeket, ugyanakkor lokálisan lehetséges könnyen megjegyezhető azonosítókat rendelni ezekhez a véletlenszerű pszeudonimekhez, ami jelentősen növeli a használhatóságot, de mégsem jár az azonosítók kompromittációjával. Fontos szempont az identitásmenedzsment funkciók tervezése során a megfelelő profilhierarchia meghatározása. Kialakításakor törekedni kell arra, hogy annak struktúrája alkalmas legyen a többi követelmény megvalósítására, így például arra, hogy oldalanként külön identitásokat hozhasson létre a felhasználó, vagy hogy minden egyes profilhoz önálló biztonsági beállítások tartozhassanak. A modellnek hozzá kell járulnia ahhoz, hogy a felhasználó a számára kívánatos anonimitási szintet elérhesse és megőrizhesse a használat során. Az egyes azonosítók használata eltérhet a megosztott információk azonosítási 16


képessége (pl. a felhasználó városának felfedése kevésbé azonosít, mint a teljes neve), a használat hossza (rövid vagy hosszútávú), illetve a viszony jellege szerint. Ezek alapján a szakirodalom megkülönböztet személyes azonosítókat (ún. person pseudonym), szerephez kötött azonosítókat (ún. role pseudonym), kapcsolathoz kötött azonosítókat (ún. relationship pseudonym), szerephez és kapcsolathoz is kötött azonosítókat (ún. rolerelationship pseudonym), valamint egyszer használatos tranzakciós azonosítókat is (ún. transaction pseudonym) [3]. Ahogy haladunk az egyszer használatos felé a személyestől, úgy egyre kevesebb információt fedünk fel a felhasználó valódi személyéről, és ezzel is az összeköthetetlenséget garantáljuk. Egy erre alkalmas profilhierarchiára találhatunk javaslatot a [3]-ban. Amint azt a 3. ábrán láthatjuk, a modell 5 különböző profil típust különböztet meg attól függően, hogy az mennyire kontextus-specifikus.

3. ábra. Egy lehetséges profilhierarchia struktúra.

A legáltalánosabbak a személyes azonosítók, amikor közvetlenül a személyhez kötjük a profilt, de szerephez, tranzakcióhoz nem. Ezzel szemben a másik végén a tranzakciós azonosítók találhatók, amikor – mint azt a neve is sugallja – minden egyes tranzakcióhoz külön identitás tartozik. Így ezeknél a legerősebb a kontextus függőség. A két véglet között helyezkednek el azok az esetek, amikor az azonosítók szerephez, kapcsolathoz, vagy egyszerre mindkettőhöz köthetők. 17


5. Identitásmenedzsment alkalmazás anonim böngészőkben Az irodalomkutatás eredményeit, illetve a megfogalmazott követelményeket figyelembe véve elkészítettük egy privátszféra-barát identitásmenedzsmentet nyújtó anonim böngésző modelljét, illetve implementációját is [18], és ezt mutatjuk be a következő fejezetben. A fejezet végén röviden bemutatjuk a tesztalkalmazás elemzését is, hogy a tapasztalatok alapján mennyiben tesz eleget a követelményeknek és milyen területeken lehet szükséges továbbfejleszteni. 5.1. Javasolt modell A modellünk központjában első sorban az identitások kezelése áll, és ennek megfelelően részletesebben tárgyaljuk a profilhierarchiára javasolt struktúrát, majd vizsgáljuk az identitásváltást, a pszeudonim azonosítók generálását. Ezen kívül azokkal a modell azon részleteivel is foglalkozunk, amelyek egy hagyományos kliens alapú anonim böngésző részét is képezik. 5.1.1. Profilhierarchia Ahogy korábban rámutattunk, az azonosítók általánosságának figyelembe vételével megállapíthatjuk, hogy a PIDM-et nyújtó alkalmazásban kulcsszerepe van annak, hogy a különböző profilok megfelelő szerkezetbe, megfelelő hierarchiába legyenek szervezve. Ez elősegíti, hogy mindig csak a megfelelő információk kerüljenek megosztásra, valamint megkönnyíti a felhasználó számára az identitások kezelését. Jelen tanulmányban az implementált verziót ismertetjük [18]. A profilhierarchia legfelső szintjén áll a fő profil, ami gyakorlatilag az alapbeállításokat tartalmazó identitásnak tekinthető, amelyből az összes többi felhasználó által definiált profil származtatható. Az ebből az identitásból származtatható első szinten található profilok között találhatjuk a szerephez kötött, valamint a személyes profilokat.

18


4. ábra. Profil hierarchia.

A személyes profilok esetében meghatározhatunk különböző identitásokat, amelyeket bárhol, bármilyen szolgáltatás igénybevételére lehet használni egy bizonyos a felhasználó által meghatározott név alatt. Megfelelő biztonsági beállítások esetén ez a gyakorlatilag a 2.4. fejezetben megismertetett Nymity Slider csúszka állandó azonosításának feleltethető meg. Ezzel szemben a szerephez kötött profilokat a felhasználási területre specifikusan hozzuk létre, például: külön identitást a fórumozáshoz, vásárláshoz, levelezéshez, stb. A szerephez kötött profilokból lehet származtatni a szerephez és kapcsolathoz kötött profilokat. Ezek abban különböznek az előbbiektől, hogy esetükben megadásra kerül, hogy például egy fórumozásra használt profilt melyik fórumban lehet használni, tehát nem csak az kerül szabályozásra, hogy milyen típusú alkalmazások esetén lehet használni egy profilt, hanem az is, mely oldalakon lehet igénybe venni azt a szolgáltatást. A hierarchia legalján a tranzakciós profilok találhatók táblákba szervezve, melyek szerepe, hogy egy azonosítót csak egy tranzakcióhoz lehessen használni. Ezeket azért kell eltárolni, hogy véletlenül se lehessen ugyanolyan azonosítóval még egy identitást létrehozni. A tranzakciós profilok és megfelelő biztonsági beállítások használatával – amelynek része az IP cím rejtése is – megvalósítható a teljes anonimitás, hiszen a felhasználó egy időben párhuzamosan történő, vagy egymás utáni tevékenységei sem lesznek összeköthetőek egymással, vagy a felhasználó személyével.

19


5.1.2. Öröklődés A profilhierarchia további fontos tulajdonsága, hogy az identitások között nem csak egy vélt viszony van, hanem az a profilokhoz tartozó adatok alapján látszódik, és használatbeli előny mutatkozik a hierarchikus viszonyokból. Egy ilyen plusz szolgáltatás a profilok között megvalósuló öröklődés. Az öröklődés során lehetőséget kell adni a felhasználónak, hogy a hierarchiában lejjebb található profilokba tudja örökíteni mind a szülő identitáshoz tartozó adatokat, mind a biztonsági beállításokat amennyiben kívánja. Ezalatt ügyelni kell arra, hogy a teljes körű öröklődés ne legyen alapértelmezett, ugyanis az bizonyos esetekben csökkentheti az anonimitást, ráadásul néhol nem öröklött, hanem ellentmondó információk megadása lehet szükséges. Például kifejezetten hátrányos, hogy ha egy profilhoz tartozó e-mail címet egy anonim használatra szánt profilhoz örökít a felhasználó. A javasolt modellben öröklődés során mindig csak a közvetlen szülő adatait lehessen örökíteni, aminek a révén nem fordulhat elő az, hogy a nagyszülőtől és a szülőtől öröklött adatok alapértelmezés szerint „ütik” egymást. 5.1.3. Identitásváltások Fontos kérdés, hogy az egyes profilok közötti váltások milyen módon mennek végbe. Az identitások váltásának automatizálhatósága szükséges, és az elengedhetetlen szempont, hogy a felhasználó bármikor identitást változtathasson manuálisan. Ez előbbi például az URL-ek vizsgálatával valósítható meg: ha a felhasználó másik URL-re navigál, akkor automatikus profilváltást hajt végre az identitásmenedzsment alkalmazás. Ha több identitásnál is megtalálható ez az URL, akkor fel kell ajánlania a választási lehetőségeket. Arra az esetre, ha átnavigál egy olyan oldalra, amelyikhez nincs külön identitás hozzárendelve, a böngészőnek több lehetőséggel kell rendelkeznie: • egyrészt alkalmazható legyen a régi profil egészen addig, amíg nem jut egy olyan oldalra a felhasználó, amelyhez van saját profil definiálva • másrészt pedig választhasson, hogy kívánja-e az adott identitáshoz kapcsolódó biztonsági (és egyéb) beállításokat használni a továbbiakban, vagy pedig valamelyik másik profilt kívánja-e alkalmazni. Hasznos lenne egy olyan funkció is, amelyik figyeli, hogy amennyiben az adott oldalhoz nincs profil, de az URL-ben, vagy a honlap fejlécében, metaadatai között megtalál bizonyos kulcsszavakat (mail, forum, shop, stb), akkor az adott kulcsszóhoz tartozó szerep identitást ajánlja fel, ha az rendelkezésre áll.

20


5.1.4. Pszeudonim azonosítók generálása Amint az korábban említettük, a pszeudonim azonosítók generálása során két különböző érdeket kell figyelembe venni. Egyrészt fontos, hogy az azonosítók ne okozhassanak információszivárgást, ne lehessen beazonosítani a felhasználót ezek alapján, illetve ne szűkítsék jelentősen az anonimitási halmazt, másrészt pedig az is elvárás, hogy a generált azonosítók a felhasználó számára könnyen használhatóak legyenek [17]. Az előbbi igényeknek egyértelműem a véletlenszerűen generált azonosítók felelnek meg a leginkább, tehát a cél, hogy azokat lehessen valamilyen módon felhasználóbarát módon használni, hiszen a felhasználótól nem várható el, hogy egy véletlenszerűen generált azonosítót (például: „ed093cb22bb8f5”) megjegyezzen és szükség esetén emlékezetből írjon be a megfelelő mezőbe. Az alkalmazásnak elő kell tudnia hívni egyszerűen bármikor az éppen aktuális profilhoz tartozó azonosítót, illetve minden egyéb hozzá tartozó adatot. Ez a megoldás azonban még fórumok, vagy más olyan szolgáltatások esetében, ahol a felhasználók egymással kommunikálnak, nem oldja meg a használhatóság problémáját. Nem reális feltevés, hogy egy véletlenszerű azonosítót a kommunikációs partner meg tud jegyezni. Ebben az esetben azt kell meggondolni, hogy egyáltalán akarjuk-e, hogy bárki is meg tudja jegyezni az azonosítónkat? Tranzakciós profilok esetében ennek természetesen nem is lenne értelme, hiszen minden azonosító mindösszesen egyszer használatos, utána eldobja a felhasználó. Ennek ellenére véleményünk szerint van jogosultsága a „többször használatos” véletlenszerű azonosítóknak, hiszen ekkor maga a generált név nem csökkenti a privátszféra védettségét, illetőleg lehetőséget nyújthat arra is, hogy csak a felhasználók egy szűkebb köre tudja összekötni a véletlenszerű azonosítókat használó kommunikációs fél üzeneteit. Az azonosítók megjegyezhetőségének érdekében két lehetőség közül érdemes választani [19]. Az első esetben az identitás létrehozásakor az alkalmazás hívja fel a felhasználó figyelmét arra, hogy válassza meg biztonságosan az azonosítóját. Nem ideális megvalósítás, de sok előnnyel bír, ha felhívják az emberek figyelmét a biztonságos használati formára, illetve ha ajánlásokat fogalmaznak meg a számukra. Különösen igaz lehet ez egy olyan területre, mint a webes privátszféra védelem, ami még nem ivódott be kellőképpen a köztudatba. A másik lehetőség ennél jóval bonyolultabb, és az identitásmenedzsmentet megvalósító anonim böngészőkhöz a pontos specifikáció elkészítése, valamint az implementálás további vizsgálatokat igényel. A megoldás lényege, hogy a többi felhasználó, akik az implementált 21


alkalmazást futtatják, hozzá tudnának rendelni a véletlen azonosítókhoz egy könnyen megjegyezhető lokális emlékeztetőt, amit csak ők ismernek, és amik csak az általuk használt gépeken tárolódnának. Az alkalmazás figyelné, hogy a betöltött oldalakon megjelenik-e a figyelt pszeudonim, és amennyiben igen, azt kicseréli a felhasználó által megadott emlékeztetőre. A megoldás több kérdést is felvet, például előfordulhat, hogy a felhasználó nyilvános hozzászólásban az általa használt lokális emlékeztetővel szólítja meg a partnerét, ami információszivárgáshoz, a privátszféra sérüléséhez vezethet a választott lokális emlékeztetőtől függően. Az is fontos kérdés, hogy milyen eszközzel oldható meg a véletlen azonosítók kicserélése a megjelenítendő honlapon. 5.1.5. Biztonsági beállítások, szűrők és blokkolók alkalmazása A biztonsági elemek, szűrők implementálása során elengedhetetlen a moduláris jelleg, ugyanis az egyrészt könnyebbséget jelent a felhasználók számára az egységes felületek révén, másrészt a fejlesztők munkáját is megkönnyíti az újrahasznosítható elemek által. A blokkolni kívánt elemeket két csoportba oszthatjuk a rajtuk végrehajtandó műveletek és a modularitás szempontjából. Az első csoportba tartoznak azok a veszélyforrások, melyeket nem lehet sablon szerint kezelni, mivel többféle végrehajtható műveletet párosítunk hozzájuk: ilyen az URL Referer manipulálhatósága, illetve az LSO-k kezelése. A második csoportba azok az elemek kerülnek melyek esetén kizárólag a blokkolás szükségességét kell eldönteni: ilyen elemek a Java alkalmazások, JavaScript kódok, a Flash és Silverlight, valamint az ActiveX elemek. Ez a lista nem kimerítő jellegű, de a két típus szerint további elemek is találhatóak. Bármely csoportba is tartozzék egy szűrő, fontos, hogy magát a szűrést ne csak ki- és bekapcsolni lehessen, hanem hogy identitásonként külön meg lehessen határozni például olyan honlapok listáját, amire a szűrést soha, még bekapcsolt állapot esetén sem kell alkalmazni, ezeket a kivételeket tartalmazott listákat úgynevezett whitelisteknek hívják. Ezen túlmenően érdemes a rendszert úgy kialakítani, hogy profilonként lehessen szabályozni az egyes modulok beállításait és bekapcsoltságát is. 5.2. Implementáció ismertetése Az alábbiakban röviden bemutatjuk a [18] diplomatervben kidolgozott és implementált identitásmenedzsment rendszerrel ellátott anonim böngészőt. Az ismertetés során kitérünk a választott környezetre, a kezelőfelületre, illetve a különböző főbb funkciók megvalósítására. 22


5.2.1. Választott környezet Az első fontos döntés annak a meghatározása volt, hogy milyen környezetben kerüljön megvalósításra az alkalmazás. Végül a Firefox böngésző2 mellett szólt, hogy az azokhoz készített kiterjesztések – megfelelő fájlkezelési struktúrát választva – platform-független működést garantálnak, valamint a fejlesztésre használt – XML-en és JavaScripten alapuló – nyelv egyszerűsége is előnyt jelentett. Mivel lehetséges egy hordozható Firefox böngésző kialakítása, előre telepített kiterjesztésekkel, ezért egy önálló alkalmazás implementálása reális alternatívaként fel sem vetődött. 5.2.2. Kezelőfelület A tervezés során több lehetőség is mérlegelésre került a kezelőfelület megvalósítását illetően, végül a statusbaron és a context menün keresztül került implementálására. A böngésző jobb alsó sarkában – a status-bar jobb szélén – folyamatosan elérhető az alkalmazás ikonja, melyre kattintva választhatok a jelenleg elérhető funkciók közül: • Anonim mód • Flash Blokkoló beálltásai • Profilbeállítások

5. ábra. Funkcióválasztó az implementációban.

Az IDM ikonjától balra található címke pedig az aktuális állapot visszajelzésére szolgál, itt látható, hogy aktuálisan mely profil használjuk. A context menüből pedig az éppen érvényben lévő profilhoz tartozó adatokat lehet könnyedén előhívni. Az 5.1.1 fejezetben leírt javasolt modellhez képest a [18]-ben implementált profilhierarchia abban különbözik, hogy a tranzakciós profilok még nem kerültek megvalósításra. A profilkezelésre szolgáló ablak bal oldalán látható az identitások fastruktúrája, itt lehet felvenni új profilokat, illetve meglévőket törölni. Itt került elhelyezésre a manuális profilváltáshoz szükséges gomb is.

2

Weboldalának címe: http://firefox.hu 23


6. ábra. Profilmenedzser kezelőfelület.

Az ablak jobb oldalán találhatók az aktuálisan érvényben lévő profilhoz tartozó adatok, itt lehet új profiladatokat felvenni, meglévőket törölni, illetve szerkeszteni. Minden egyes profilhoz bármennyi mezőt fel lehet venni. Szintén a jobboldalon találhatók azoknak a honlapoknak a listája, amelyek az érvényben lévő profilhoz tartoznak. Ha egy profilhoz tartozó honlapra navigálunk, akkor automatikusan arra a profilra vált az alkalmazás. 5.2.3. Blokkoló Az implementált tesztrendszerben a Flash blokkoló került megvalósításra. A blokkoló úgy lett kialakítva, hogy minden egyes profilhoz külön be lehet állítani és ezek a beállítások elmentésre kerülnek.

24


7. ábra. Flash blokkoló és működése.

Alapvetően két beállítási lehetőséggel bír a blokkoló. Egyrészt ki/be lehet kapcsolni, másrészt pedig létre lehet hozni egy úgynevezett whitelistet minden profilhoz a testreszabhatóság érdekében. A whitelistek segítségével lehet azt beállítani, hogy bár a Flash blokkoló aktív, bizonyos oldalakról bekapcsolt állapot esetén is automatikusan letöltődjenek a Flash animációk. A Flash blokkoló „proof-of-concept” jelleggel került implementálásra, a további blokkolókról az 5.3.2. fejezetben fog szó esni, mint továbbfejlesztési javaslatokról. 5.2.4. Fájlkezelés Az implementálás során két lehetőség került megvizsgálásra. Egyrészt lehetőség van saját fájlok létrehozására, melyeknek mi határozhatjuk meg a nevét, kiterjesztését, helyét, másrészt pedig lehetőség nyílik a Firefoxhoz tartozó úgynevezett preferences (a továbbiakban PREF) fájlok létrehozására, melyeket a Firefox a különböző felhasználói beállítások mentésére használ, és mint ilyen, rendelkezésére áll a kiterjesztések fejlesztői részére is. Mivel egyszerű szöveges fájlokra van szükségünk, amelyekben egymástól elválasztva lehet eltárolni a kivételekhez tartozó címeket, ezért mindkét lehetőség megfelelő alternatívaként tűnt fel. Ami miatt végül a PREF fájlok használata mellett döntöttünk, az volt, hogy az egyszerűsége mellett ez a módszer biztosítja a platform-függetlenséget, mivel a Firefox maga is platform-független és így az ő saját fájljait használjuk fel.

25


5.2.5. Anonimitás Az alkalmazás tartalmaz egy kísérleti, úgynevezett „Anonim módot”. Azért nevezzük kísérletinek, mert más Firefox kiegészítések felhasználásával működik, és egyelőre nem lehet személyre szabni a különböző beállításokat, de a tesztek azt bizonyították, hogy az opció bekapcsolása garantálja az anonimitást a felhasználó számára. Az anonim mód tartalmaz egy JavaScript blokkolót, egy URL Referrer manipulátort, valamint egy a TOR [20] használatát lehetővé tevő kiterjesztést. 5.3. Implementáció tanulságai Az alábbi fejezetben bemutatjuk azokat a teszteket, melyek bizonyították a tesztrendszer helyes működését, majd felsoroljuk a tervezett, de egyelőre nem implementált elemeket, valamint kitérünk az esetleges jövőbeni fejlesztésekre, melyek egyike a fájlkezelést adatbázis alapúra cserélné. 5.3.1. A tesztrendszer működése Az alkalmazás helyes működését egyrészt a proof-of-concept célból elkészített Flash blokkoló, másrészt pedig az anonim mód reprezentálja. A flash blokkoló tesztelésekor először kipróbáltuk, hogy whitelist alkalmazása nélkül ki-, illetve bekapcsolt állapotban is az elvárt eredmények születnek-e, majd whitelist alkalmazásával is megvizsgáltuk ezt a kérdést. A blokkoló az elvártaknak megfelelően működött minden esetben, erre egy példát láthatunk a 7. ábrán. Amint azt említettük, az alkalmazásban található anonim mód még közel sem végleges, és jelenleg csupán annak az illusztrálására szolgál, hogy az alkalmazás képes a felhasználó számára az anonimitást garantálni, ezt bizonyítandó, tesztelésnek vetettük alá az alkalmazás „anonim módját”. A tesztelés során arra voltunk kíváncsiak, hogy az anonim mód garantálja a felhasználó számára az anonimitást. Első esetben csak azt kívántuk ellenőrizni, hogy a böngésző blokkolja-e az URL Referert. Azt tapasztaltuk, hogy valóban a statusbaron megjelent az URL Referer blokkolását mutató ikon, valamint a meglátogatott oldal felhívta a figyelmünket arra, hogy nem működik az oldal minden eleme megfelelően a JavaScriptek engedélyezése nélkül, ami egyben igazolta a JavaScript blokkoló működését is. Azonban ezen elemek blokkolása nem elegendő cél – az anonimitás – eléréséhez, ezért következő lépésben megvizsgáltuk közelebbről, hogy milyen adatokat is fed fel magáról a 26


böngésző. Amint azt már korábban említettük, már önmagában az IP cím alkalmas arra, hogy segítségével rengeteg információt ki lehessen deríteni a felhasználóról, ezért felkerestem egy olyan honlapot, ami megosztja az érdeklődő felhasználóval, hogy milyen adatokat fed fel róla az IP címe, illetve a böngészője.

8. ábra. Az anonim mód által elfedett adatok.

Az 8. ábra jobb oldalán láthatók a felfedett információk anonim mód esetén, a bal oldalon pedig a normál mód esetén megosztott adatok. Amint az leolvasható, anonim mód esetén ténylegesen sikerült blokkolni eredeti IP címünket, illetve minden lényeges adatunkat, amely az ellenőrző honlap alapján kideríthető volt rólunk.

5.3.2. Tervezett, de meg nem valósított elemek implementálása Úgy gondoljuk, hogy az alkalmazással kapcsolatosan a legfontosabb teendő, hogy a tervezett, de a tesztrendszer keretein belül meg nem valósított elemek kerüljenek implementálásra. Így szükséges, hogy: • a Flash blokkoló mellett legyen lehetőség a Java alkalmazások, JavaScriptek, SilverLight valamint ActiveX elemek blokkolására • legyen lehetőség az URL Referrer manipulálására • legyen lehetőség a HTML tagek szűrésére Ezeken túlmenően úgy látjuk, hogy az örökítés lehetőségein érdemes finomítani. Jelenleg a gyermekprofil a közvetlen szülőprofil összes adatát automatikusan megörökli. Amint azt az 5.1.2. fejezetben írtuk, ez bizonyos esetekben veszélyeztetheti a felhasználó privátszféráját, így érdemes úgy megvalósítani az öröklődést, hogy a felhasználó dönthesse el, milyen

27


adatokat kíván átadni az új profil számára. Bár a probléma ideiglenesen áthidalható a gyermek profilok szerkesztésével, azonban ez hosszútávon nem jó megoldás. 5.3.3. Jövőbeli fejlesztések További kutatásokat kíván, de meglátásunk szerint érdemes újragondolni a fájlkezelés kérdéskörét. Amint azt korábban bemutattuk, jelenleg a felhasználók által megadott adatok, a felhasználói beállítások a Firefox PREF fájljaiba kerülnek elmentésre. Ez egy tesztrendszer esetén elegendő, azonban ha később – például a tranzakciós profilok révén – sok adattal kell dolgozni, elégtelen lehet ez a megoldás. Javasoljuk, hogy az adatok relációs adatbázisban kerüljenek tárolásra, adatbázis-kezelő motornak az az SQLite-ot ajánljuk. A fájlkezeléshez kapcsolódó szintén fontos kérdéskör a tárolt adatok védelme. A jelenlegi tesztrendszerben az szolgál az adatok illetéktelen kezekbe kerülése ellen, hogy nem a használt számítógép merevlevezén, hanem a használó hordozható memóriaegységén kerülnek tárolásra. A relációs adatbázisra történő átállással egyidőben javasoljuk, hogy kerüljön bevezetésre az adatok kriptográfiai eljárással történő védelme. A használadó eljárás meghatározása további kutatások feladata. Ezen túlmenően javasoljuk, hogy a pszeudonimek létrehozásánál, vagy generálásánál figyelembe vételre kerüljenek azok a szempontok, melyeket a 5.1.4 fejezetben bemutatott modellben megfogalmaztunk. Azonban ez a téma implementálás előtt még mindenképpen további kutatásokat igényel 6. Konklúzió Megmutattuk, hogy az információs társadalomnak egyre nagyobb szüksége van a privátszférát védő technológiák, eszközök alkalmazására, melyek közül mi a privátszférabarát identitásmenedzsment gyakorlati használatával foglalkoztunk. Bemutattunk több példát az alkalmazására, a PRIME és a PRIMELIFE európai uniós projektek legfőbb céljukként tűzék ki a PIDM lehetős legszélesebb körben történő elterjesztését, valamint továbbfejlesztését mind technikai, mint társadalmi aspektusokból. Emellett bemutattuk a BluES eLearning alkalmazást, ami a PRIME keretein belül kidolgozott úgynevezett részleges identitás technikát valósítja meg a gyakorlatban. Ismertettük az interneten való anonim böngészésre létező különböző technológiákat, és különböző szempontok szerint összehasonlítottuk ezen lehetőségeket, melyek közül a továbbiakban mi az „anonim böngészők PIDM-mel” kategóriára összpontosítottunk.

28


A saját modellünket az összehasonlítás meghatározó szempontjai mentén alkottuk meg. Egyik legfontosabb tapasztalatunk, hogy a legnehezebb feladat a felhasználóbarát működés és az anonimitás ellentétes igényeinek való egyidejű megfelelés. Jó példa erre a pszeudonimek megfelelő kiválasztása, vagy az egyes profilokon keresztül felfedendő adatok körének meghatározása. Mindkét problémára ismertettünk lehetséges megoldás előbbi esetben a véletlenszerű pszeudonimek kombinálása lokális emlékeztetőkkel, utóbbi esetben pedig a részleges identitás technika alkalmazása bizonyult életképes lehetőségnek. Jövőben munkán során két irányba igyekszünk haladni. Egyrészt fontos szerepet szánunk a további elméleti kutatásnak, mélyebben kívánjuk tanulmányozni a részleges identitás technikát, illetve nagy hangsúlyt szánunk a megfelelő pszeudonim választás kérdéskörének. Olyan megoldással kívánjuk bővíteni a modellünket, ami nem csak a PIDM támasztotta követelményeknek felel meg, de számos felhasználóbarát jeggyel is bír, ugyanis csak ezek révén implementálhatunk egy népszerű alkalmazást. Emellett az eddiginél sokkal hangsúlyosabb szerepet fog kapni az elkövetkezőkben a fejlesztői munka. Az 5.2 fejezetben bemutatott alkalmazást kívánjunk továbbfejleszteni, egyrészt azon tervek alapján, melyek már elkészültek, azonban implementálásukra nem volt idő, másrészt figyelembe véve az eddig csak ötletként megfogalmazott lehetőségeket, végül de nem utolsó sorban pedig a jövőbeni kutatásaink eredményeit. Irodalomjegyzék [1]

[2]

[3] [4] [5]

[6]

Gulyás G., Schulcz R., Imre S. - Comprehensive Analysis of Web Privacy and Anonymous Web Browsers: Are Next Generation Services Based on Collaborative Filtering?, Proceedings of the Joint SPACE (Sustaining Privacy in Autonomous Collaborative Environments, TIME (Trust in Mobile Enviroments) Workshops, Trondheim, Norvégia, 2008. június 17. Gulyás G.: Anonim-e az anonim böngésző? Technológiák és szolgáltatások elemzése. In: Tanulmányok az információ- és tudásfolyamatokról 10. Alma Mater sorozat, BME GTK ITM, Budapest, 2006. március. M. Hansen, A. Schwartz, A. Cooper, - "Privacy and Identity Management", IEEE Security and Privacy, VI. évfolyam, 2. szám, 2008 márc./ápr. J. Hakkila, and I. Kansala. Role based privacy applied to context-aware mobile applications. In Proc. of IEEE Conference of System, Man and Cybernetics, 2004. R. Leenes, J. Schallaböck, M. Hansen, PRIME White Paper v3, 2008. május 15. https://www.prime-project.eu/prime_products/whitepaper/PRIME-WhitepaperV3.pdf PRIME – Privacy and Identity Management for Europe, https://www.primeproject.eu/ 29


[7] [8] [9] [10]

[11] [12] [13]

[14]

[15]

[16] [17] [18] [19] [20]

[21]

30

PRIMELife – Privacy and Identity Management in Europe for Life, http://www.PRIMELife.eu/ I. A. Goldberg – A Pseudonymos Communications Infrastructure for the Internet, 2000, II.4. fejezet E. Franz, B. Engel, A Realization of Context Management Facilitating the Usage of Partial Identities, CHI Workshop, 2006. K. Borcea, H. Donker, E. Franz, K. Liesebach, A. Pfitzmann, and H. Wahrig, IntraApplication Partitioning of Personal Data, Dresden University of Technology, Dresden, Germany, 2005. Hasznics M., Globális perszonalizáció – kapcsolati hálózatkezelés PRIME környezetben, Alma Mater, 2006/1. E. Franz, C. Groba, T. Springer, M. Bergmann. A Comprehensive Approach for Context-dependent Privacy Management. ARES 2008, Barcelone, Spain, 2008. M. Reichenbach, H. Damker, H. Federrath and K. Rannenberg. Individual Management of Personal Reachability in Mobile Communication. In IFIP/SEC'97 13th International Information Security Conference, Copenhagen, Denmark, May 1997. U. Jendricke and D. Gerd tom Markotten. Usability meets security - The IdentityManager as your Personal Security Assistant for the Internet. In Proc. of the 16th Annual Computer Security Applications Conference, New Orleans, USA, 2000. Gulyás G.: Privátszféra-védelem szerepalapú identitásmenedzsment alkalmazásával csevegő szolgáltatásokban. In.: Szabad adatok, védett adatok 2, Alma Mater Sorozat, Információs Társadalomért Alapítvány, 2008. szeptember. Szili Dávid – Anonimizáló rendszerek elméletben és gyakorlatban, Hacktivity 2008, 2008.09.21, http://pet-portal.eu/files/blogs/pet/2008/09/hacktivity/4_szili.pdf K. Borcea, E. Franz, A. Pfitzmann - Usable Presentation of Secure Pseudonyms, Dresden University of Technology, Dresden, Germany, 2005. Dargó S., Webes anonimitást és privátszféra-barát identitásmenedzsmentet nyújtó alkalmazás tervezése, Diplomaterv, 2010. E. Franz, K. Liesebach. Supporting Local Aliases as Usable Presentation of Secure Pseudonyms. TrustBus 2009, Linz, Austria, 2009. Gyöngyösi László – Tor és Torpark: az új generációs anonim böngészők funkcionális és teljesítményelemzése, Tanulmányok az információ- és tudásfolyamatokról 11., BME GTK ITM, Budapest, 2006. Október P. Eckersley. How Unique Is Your Web Browser?, 2010. január, http://panopticlick.eff.org/browser-uniqueness.pdf0

Privátszféra-barát identitásmenedzsment alkalmazása anonim böngészőkben. Dargó Sándor, Gulyás Gábor György

Recommend Documents