% -*- coding: utf-8 -*- \documentclass[12pt, a4paper, titlepage, pdftex, oneside, openany]{book} \usepackage[pdftex]{graphicx, color} \usepackage{url} \usepackage{fancyhdr} \usepackage{bytefield} \usepackage{amsmath} \def\magyarOptions{defaults=hu-min} \usepackage[magyar]{babel} \usepackage{times} \usepackage[T1]{fontenc} \usepackage[utf8]{inputenc} \usepackage[colorlinks=true, unicode, pdftex, linkcolor=blue, citecolor=blue, urlcolor=blue, breaklinks=true, pdfstartview=FitV, bookmarksnumbered=true, bookmarksopen=true]{hyperref} \frenchspacing \newcommand{\screenshot}[3]{% \begin{figure}[htp] \centering \includegraphics[#1]{#2} \caption{#3} \end{figure} } \renewcommand{\baselinestretch}{1.5} \pagestyle{fancy} \let\oldnewpage\newpage \let\oldpart\part \renewcommand{\part}[1]{ \clearpage \renewcommand{\newpage}{\vspace{1cm}} \oldpart{#1} \thispagestyle{empty} \renewcommand{\newpage}{\oldnewpage} } \begin{document} \sloppy \begin{titlepage} \begin{tabular}{lc} \includegraphics[scale=0.3]{cim.jpg} & \hspace{-1.5cm}\parbox{10cm}{\vspace{-2.5cm}\center Eötvös Loránd Tudományegyetem\\Informatikai Kar } \end{tabular} \begin{center} \vspace{4cm} {\LARGE A SecMS üzenetküldő fizetési rendszere} \vspace{4cm} \begin{tabular}{cc} \parbox{6cm}{\center Témavezető: Nagy Dániel\\ELTECrypt kutatócsoport\\vezető szakértő} & \parbox{6cm}{\center Készítette: Riskó Gergely\\ nappali tagozat\\programtervező matematikus szak} \end{tabular} \end{center} \vspace{6cm} \centering{\large Budapest, 2008.} \end{titlepage} \newpage \thispagestyle{empty} Ez itt a témabejelentő helye. \newpage \phantomsection \setcounter{page}{3} \addcontentsline{toc}{part}{Tartalomjegyzék} \tableofcontents \part{Bevezetés} \label{secreq} Dolgozatomban először rövid áttekintést adok a biztonságos üzenőrendszerekről. Olyan rendszereket vizsgálok, amelyben csak az üzenet küldője és címzettje ismerheti meg az üzenet tartalmát (konfidencialitás), illetve az is biztosított, hogy az üzenet címzettje biztos a feladó személyében (hitelesség) és abban, hogy az üzenetet az eredeti formájában, módosítások nélkül kapja meg (integritás). Fontos, hogy a követelmények teljesülését maga a protokoll kriptográfiai eszközökkel biztosítsa, az üzenet továbbításában szerepet játszó harmadik felek (internet szolgáltatók, szerverek és azok rendszergazdái) ne sérthessék ezeket. Nagyon gyakori félmegoldás, hogy a levelezőkliensek és kiszolgálók közti csatornákat rejtjelezik, nem törődve a szerveren megvalósítható támadásokkal. A már létező megoldások mellett bemutatok egy újat, amit az \hbox{ELTECrypt} kutatócsoport dolgozott ki és szakdolgozatként\cite{risko-bsc} egy korai verzióját már megvédtem. Ezzel új eredményeket értünk el: látni fogjuk, hogy a mi rendszerünk műveletigénye jóval kisebb, mint a versenytársaké, így pl. mobil környezetben is hatékonyan használható. Ezt demonstrálandó, a szakdolgozatom óta a kutatócsoportban a mobiltelefonokon (Java környezetben) futó kliensalkalmazást is elkészítettem és továbbfejlesztettük az üzenőrendszer szerverének szolgáltatásait is. Akár csak a szakdolgozatom tesztelésekor, ezeket az új komponenseket is bemutattuk egy szemináriumon, ahol a programmal először találkozó felhasználókat kértük meg, hogy próbálják meg használni a kezükbe adott mobiltelefonokon a SecMS-t. A SecMS így önmagában is fontos eredmény, azonban igazi szerepét egy fizetőrendszerrel együtt tudja betölteni. Ezért be fogom mutatni, hogy hogyan működik egy régóta ismert, David \hbox{Chaum} által kidolgozott, vak aláírásokon\cite{chaum82blind} alapuló fizetőrendszer\cite{chaum89untraceable}. Ez a javaslat 20 éves és azóta sem terjedt el. Ennek az okait vizsgálja Nagy\cite{nagy05} és egyben egy új javaslatot is ad a digitális készpénz megvalósítására, amit ePointnak hív. Az ePoint újdonsága a megbízható harmadik fél (kibocsátó) ellenőrizhetőségében, a tranzakciós díjaktól való mentességében rejlik. Megismétlem a Nagy által felhozott érveket és megvizsgálom az ePoint működését, megmutatva, hogy a \hbox{Chaum} javaslata óta kialakult új környezetben (sokkal olcsóbb és gyorsabb, mindenütt jelenlévő adathálózatok, kis kapacitású kliensek), az ePoint valóban életképesebb. Schuller \cite{epoint-prot} diplomamunkaként kidolgozott egy HTTP alapú protokollt az ePointok továbbítására, én ezt felhasználva megmutatom, hogy hogyan lehetne az ePoint rendszert integrálni a SecMS-sel. A fizetőrendszer és a SecMS integrálásával a külön-külön is érdekes alkalmazásokból egy sokkal hasznosabbat kapunk, hiszen minden pénzügyi tranzakciónk közben szükség van a fenti biztonsági követelményeket teljesítő üzenetváltásra is. Fordított irányban is szükséges az integráció: a SecMS fizetőrendszer nélküli elterjedése esetén az emailhez hasonlóan nagy problémákat okozna a levélszemét kezelése. Az integráció után azonban a probléma egyszerűen orvosolható, egy olyan rendszert kell felépíteni, amiben minden levél mellé pénzt kell csatolni, így biztosítva a fogadó oldalon a figyelem felkeltését. Természetesen amennyiben a levél legitim, arra válaszolva a pénzösszeg visszajuttatható a feladónak. Habár az azonnali felhasználása ezeknek az új technológiáknak a spam elleni védekezés, alkalmazási területe ennél sokkal szélesebb: zárásul leírom mikrofizetésekhez kapcsolódó, ma még megoldatlan problémák (pl. tartalom- és hírszolgáltatások, telekommunikációs szolgáltatások fizetésének) lehetséges megoldásait. \subsubsection{Egy korábbi fizikai megvalósítás} Bruce Schneier egyik internetes naplóbejegyzésében\cite{bruce-doorbell} megemlíti, hogy a vázolt megoldást 1933-ban már megvalósították. Igaz, akkor nem a kéretlen elektronikus levelek, hanem a jelentéktelen ügyekkel házalók ellen kívántak védekezni. A látogatónak be kellett helyeznie egy tízcentes érmét, ahhoz, hogy a csengő megszólaljon. Amennyiben a házigazda számára a vendég kívánatos volt, akkor ezt az érmét visszaadta. \begin{center} \includegraphics[scale=0.65]{doorbell.jpg} \end{center} Schneier megjegyzi, hogy a levélszemét esetében két szempontból még kedvezőbb is a helyzet, mint a csöngő esetében. Először is, a kéretlen levelek száma a valós levelek számához képest sokkal nagyobb, mint az indokolatlanul becsöngetők száma a valódi látogatók számához képest. A mértéktartóbb becslések szerint\cite{wiki-spam} az összes levél 80-85 százaléka kéretlen, de a bátrabb becslések 95 százalékot említenek. Ezért a rendszert megérheti felépíteni és működtetni. Másrészt, ha az informatikai megoldást szabványosítják és minden elterjedt levelezőprogramban megvalósítják, akkor az mindenki számára elérhető. Ellentétben a fizikai megvalósítással, ahol elképzelhető, hogy valakinél nincs megfelelő pénzérme. Aggodalmát fejti ki ugyanakkor amiatt, hogy ahogyan csöngetés helyett bekopoghatunk az ajtón vagy kiabálhatunk, az elektronikus megoldásban is meg fognak próbálni kiskapukat keresni. Sőt, azzal, hogy egy fizetőrendszer áll a szűrőrendszer mögött, nyilvánvaló, hogy a leveleket küldő és fogadó számítógépek feltöréséhez közvetlen anyagi érdek is fog fűződni. Hiszen ha rá tudunk venni jogosulatlanul egy kliensprogramot, hogy a saját címünkre minél több levelet továbbítson, akkor az azokhoz csatolt összegeket elvettük a gazdájától. Schneier úgy gondolja, hogy emiatt, egy biztonsági szempontból a mai asztali számítógépeknél sokkal megbízhatóbb platform nélkül az ötletet el is kell vetni. Egyetértünk vele, pontosan ezért készítettük el a mobiltelefonokon futó implementációját a SecMS-nek és ezért tervezzük úgy, hogy a mindennapi felhasználók esetében a konkrét pénzügyi tranzakciók csak a mobiltelefon segítségével történhessenek majd. A mobiltelefonokra írható programok egymástól jól szeparáltak, biztosított a mobiltelefon és a programok egymástól való védelme, ugyanakkor megoldott a kommunikáció (bluetooth technológiával, infravörös kapcsolaton vagy akár interneten) az asztali- és szerverszámítógépekkel. \part{Létező üzenetküldő- és fizetőrendszerek áttekintése} Ebben a részben először a biztonsági építőelemek (aszimmetrikus kriptográfia \cite{merkle78}; RSA rejtjelezés és digitális aláírás \cite{rivest77method}; DSA digitális aláírás \cite{dss}; ElGamal rejtjelezés és digitális aláírás \cite{elgamal}; Diffie-Hellman kulcsmegegyezés \cite{diffie76new}; RC4 folyamtitkosító \cite{wiki-rc4}; különböző hash függvények) célját és működését mutatom be. Ezek felhasználásával áttekintem a már kidolgozott üzenő- és fizetőrendszerek működését és specifikációik fontosabb részleteit. \chapter{Biztonsági építőelemek} Biztonsággal foglalkozó protokolljainkat és programjainkat olyan építőkockákból szeretnénk felépíteni, amik önmagukban is biztonságosak. Azt várjuk ettől, hogy a kész rendszerben is kisebb eséllyel marad hiányosság. Azt, hogy mit érthetünk egy építőelem biztonságosságán, tárgyalja \cite{pareto} és bevezeti (a közgazdaságtanból kölcsönözve) a Pareto-biztonságosság, illetve Pareto-teljesség fogalmát. Akkor mond egy eljárást \emph{Pareto-biztonságosnak}, ha a felhasználásakor tett feltételek teljesülése esetén, amellett, hogy minden felmerülő, praktikus támadásnak ellenáll, már nincsen olyan módosítás, ami a biztonságot jelentősen javítja egy területen, anélkül, hogy más területen érezhetően csökkentené. Egy komponens \emph{Pareto-teljes}, ha minden ésszerű feltételezés és biztonsági rendszerben való felhasználás mellett Pareto-biztonságos. Ez a fogalom abban több tehát, hogy nem szükséges pontosan specifikálnunk a támadóval szembeni feltételezéseinket, ezektől függetlenül használhatjuk a Pareto-teljes eljárásokat. Ezek a definíciók elég szubjektívek és egy-egy új eredmény hatására korábban Pareto-teljesnek hitt eljárások válhatnak feltörhetővé. A diplomamunkámban bemutatott építőelemek többé-kevésbé Pareto-teljesnek tekinthetőek, de a Pareto-biztonságosságot az ismertetett felhasználások során mindig megköveteljük. \section{Aszimmetrikus kriptográfia} \label{assym} Ezekkel az eljárásokkal el lehet kerülni, hogy a rejtjelezést vagy hitelesítést használni kívánó feleknek előzetesen valamilyen biztonságos csatornán meg kelljen egyezniük közös titkokban, eljárásokban. Ezekben az algoritmusokban az a közös, hogy minden résztvevőhöz tartozik egy nyilvános és egy titkos művelet. A rejtjelezést a nyilvános művelettel hajthatja végre bárki, amit megfejteni csak a titkos művelettel lehet; a digitális aláírást tetszőleges bájt sorozaton a titkos művelettel hajthatja végre a kulcs tulajdonosa, amit bárki leellenőrizhet a titkos kulcs nyilvános párjával. A digitális aláíráshoz és a rejtjelezéshez tartozó nyilvános és titkos művelet nem feltétlenül egyezik. Amennyiben igen (az RSA pl. ilyen), akkor nem tanácsos ugyanazt a kulcsot mindkét célra használni. Azt sejtjük minden ilyen eljárás esetében, hogy ahhoz, hogy a nyilvános műveletből előállítsuk a titkosat, valamilyen olyan problémát kell megoldanunk, aminek a megoldása nagyon költséges, így nem kivitelezhető. Ilyen problémák pl. a faktorizálás (az RSA épül erre), illetve egy csoport elemének egy generátorra nézve diszkrét logaritmusának a megállapítása (DSA). Elfogadva azt a sejtést, hogy ezeknek a problémáknak a megoldásával nem fogják a protokollunkat támadni, meg kell még oldani a nyilvános műveletek (kulcsok) minél megbízhatóbb terjesztését. Különben egy résztvevőt megtámadhatnak az ún. man-in-the-middle támadással (\refstruc{mitm}), aminek a lényege az, hogy elhitetik vele, hogy a partnerének más a nyilvános kulcsa, mint valójában. A kommunikációs csatornába beékelődve mindkét irányba újrakódolják az üzeneteket úgy, hogy a két fél számára ez a kezdeti kulcs letöltés után már nem észrevehető. \screenshot{scale=0.5}{mitm.png}{Man-in-the-middle támadás\label{mitm}} Ez ellen a támadás ellen két módon is lehet védekezni. Először: megegyeztek hash függvényekre épülő algoritmusokban, amik a nyilvános kulcsokhoz ujjlenyomatokat tudnak rendelni, amik már kellően rövidek ahhoz, hogy valamilyen megbízható csatornán (telefonon, faxon, postai levélben) közöljék egymással a kommunikáló felek. Letöltve a nyilvános kulcsot előállítják az algoritmussal az ujjlenyomatot és mielőtt üzeneteket váltanának, leellenőrzik, hogy pontosan ugyanazt az értéket kapták, mint amit a megbízható csatornán megbeszéltek. Másodszor: a nyilvános kulcsokat digitális aláírással látják el mások, akikkel a megbízható kulcscsere már megtörtént. Az így keletkező kulcshitelesítést közzéteszik a kulccsal együtt és így a kulcs automatikusan ellenőrizhető, a felhasználó és megbízható csatorna igénybevétele nélkül. Az, hogy kit hatalmazunk fel kulcshitelesítésre megszervezhető egy hierarchikus rendszerben (X.509) és ekkor arról kell csak gondoskodnunk, hogy a hierarchia fejének nyilvános kulcsa mindenkihez biztonságban eljusson. Így működik pl. a web biztonságát nyújtó HTTPS. Vagy felhatalmazhatunk mindenkit kulcshitelesítésre (OpenPGP\cite{rfc4880}) és ekkor egy irányított gráffal lehet jellemezni a kulcsok közötti viszonyokat. Az utóbbi rendszerben egy sokkal pontosabban mérő, szinte folytonos skálán tudjuk osztályozni egy kulcs megbízhatóságát, attól függően, hogy a gráfban a mi kulcsunktól az ellenőrizendő kulcsig milyen utak vezetnek. Ez a jobban elterjedt megoldás az email esetében, annak ellenére, hogy az S/MIME nevű, X.509 alapú megoldás minden levelezőkliensben alapértelmezés szerint megtalálható. Azonban az OpenPGP kulcskezelése olcsó és nem kötelező, míg az X.509 használata esetén a tanúsítás kötelező és a hierarchikus szervezet fenntartása miatt drága is. A nyilvános kulcsokra épülő rejtjelezés ún. kulcsmegegyezéssel is megoldható. Ha feltételezzük, hogy az üzenetet küldő és fogadó fél egyaránt rendelkezik regisztrált kulccsal, akkor lehetséges olyan művelet kidolgozása, ami ugyanazt a titkot állítja elő, ha az egyik fél titkos és a másik fél nyilvános kulcsára alkalmazzuk, mintha a másik fél titkos és az egyik fél nyilvános kulcsára alkalmaznánk. Így ezt a titkot rögtön használhatják egy szimmetrikusan rejtjelező algoritmus kulcsaként, a titok előállítása harmadik fél számára rendkívül drága. A nyilvános kulcsú kriptográfia és a nem biztonságos csatorna fölötti kulcsmegegyezés alapötletét Merkle\cite{merkle78} vetette fel először, azonban a gyakorlatban használható megoldást nem adott. A kulcsmegegyezésre az első, azóta is használt megoldást Diffie és Hellman dolgozta ki\cite{diffie76new}, ezt Diffie--Hellman kulcsmegegyezésnek hívják. A nyilvános kulcsú kriptográfiát pedig Rivest, Shamir és Adelman valósította meg elsőként. \subsection{Vak digitális aláírás} A gyakorlatban, mivel az aszimmetrikus műveletek rendkívül lassúak, a digitális aláírás készítésekor az aláíró fél nem magát az üzenetet, csupán annak egy hash értékét írja alá. A különböző hash függvényekről még lesz szó a \refstruc{hashes+ban}. Így az aláírás gyorsan elkészíthető, rövid és a digitális aláírásból (a tanúsított hash értékből) nem lehet következtetni az üzenet tartalmára. Azonban ez még nem jelenti azt, hogy amennyiben az aláírt adat tulajdonosa és az aláíró személy különbözik, akkor igaz lenne, hogy az aláíró semmit nem tud az üzenetről. Tudja a hash értékét! Tehát ha az aláíró megjegyzi minden aláírt hash értékhez az aláírást kérvényező azonosítóját az aláírás pillanatában, akkor ha később találkozik egy általa aláírt üzenettel, össze tudja kapcsolni azt az aláírást kérő személlyel. Az olyan digitális aláírási sémákat, ahol az aláíró entitás úgy tud aláírásokat kibocsátani, hogy az aláírt értékekről semmilyen információ nem jut a birtokába, \emph{vak digitális aláírásoknak} nevezzük. A vak digitális aláírás fizikai analógiája a szárazbélyegző. Szárazbélyegzővel (egy átlátszatlan boríték segítségével) úgy tudunk iratokat hitelesíteni, hogy az irat tartalmáról semmilyen információt nem kell felfednie a hitelesítést kérő személynek. \label{vakfizetes} A vak aláírások felhasználására az első javaslat\cite{chaum82blind} az elektronikus készpénz. Vak aláírások segítségével úgy tud egy bank anoniman használható, digitális pénzt kibocsátani, hogy vakon aláírja az ügyfél által elkészített egységnyi értékű bankjegyet. Ezzel egyidőben levonja az egységnyi összeget a számlatulajdonos számlájáról. Az ügyfél a keletkezett digitális bankót odaadhatja bárkinek, akinek fizetni akar, aki a banknál azt beválthatja. Mivel a bankjegy alá van írva, a bank tudja, hogy fizettek érte. Egy adatbázissal pedig garantálható, hogy minden bankjegyet csak egyszer használjanak fel. A beváltó és fizető fél ugyanakkor az aláírás vak tulajdonsága miatt biztos lehet benne, hogy a bank nem tudja őket összekapcsolni, legalábbis forgalomelemzés nélkül. Elektronikus szavazások esetén is megtartható a vak aláírások segítségével az anonimitás. A szavazásra jogosult authentikáció után aláíratja vakon a szavazatát a jegyzővel, aki kihúzza cserébe őt a szavazásra jogosultak listájáról. Ezután a szavazatát beküldheti (valamilyen anonim csatornán) a szavazatszámláló bizottságnak, ott le lehet majd ellenőrizni, hogy ez egy számlálandó szavazat (hiszen alá van írva). Ugyanakkor a szavazat tartalmát nem lehet a szavazó személyéhez kötni. Természetesen ezzel az ötlettel csak a vak aláírások fontosságát akartam bemutatni, maga a rendszer a gyakorlatban használhatatlan, mivel sok csalási lehetőséget ad a bizottságok számára. Azt, hogy az RSA aláírási séma hogy alakítható vak aláírási sémává, a \refstruc{rsavak+ban} bemutatom, a DSA digitális aláírás vakításáról pedig \cite{camenisch95blind} ír, szintén diszkrét logaritmuson alapuló aláírási sémát vakít Brands \cite{brands93efficient}-ban és ezzel ad egy teljes digitális fizetőrendszert is. \section{RSA nyilvános kulcsú kriptográfia} A Merkle által kidolgozott ötlethez az első megvalósítást, Rivest, Shamir és Adelman írta le\cite{rivest77method} 1977-ben. A szerzők nevének kezdőbetűiből adódik az RSA név, az eljárás megfelelően használva azóta is Pareto-teljes. A kulcsgeneráláshoz keresni kell két vagy több nagy prímet ($p_1, p_2, \dots, p_m$, ehhez eredetileg a Solovay-Strassen\cite{solovay:84} valószínűségi prímtesztet javasolták a szerzők, mostanra a Miller-Rabin\cite{Rabin80} teszt az elterjedtebb). A prímek szorzata a kulcs modulusa ($n:=\prod_{i=1}^m p_i$), annyi bitesnek hívják a kulcsot, amilyen hosszú a modulus. Választani kell még egy olyan $1i$) kihívást, amit Bobtól kapott. Az utasítás hatására a kibocsátó létrehoz egy új $S_j$-t, aminek az adatai megegyeznek a régi $S_i$-vel, csupán a kihívás más, illetve az indoklás részben feltünteti a kibocsátó az $R_i$-t. Mivel a nyilvántartás publikus, mindenki látja, hogy a $D_i$ titok (és a segítségével előállítható $R_i$ megfejtés) már nem képvisel értéket, így dupla költés nem lehetséges. Ugyanakkor az új rekordhoz már csak Bob tudja a $D_j$ titkot, így a pénz átruházása valóban megtörtént. Természetesen szükség van egyéb üzenettípusokra is, ezeket \az+\refstruc{epointdetails+ben} bemutatom. Tehát az ePoint rendszerben a pénztárca programban szereplő titkok felelnek meg a pénztárcánkban lévő bankjegyeknek. A bankjegyek azon tulajdonságát, hogy nem másolhatók, pedig a nyilvánosságra hozással lehet elektronikusan utánozni. Nyilvánosságra hozni egy adatot csak egyszer lehet és a nyilvánosságra került adatot már nem lehet visszavonni. A felvázolt rendszer így anonim és a tranzakciók visszafordíthatatlanok. Minden résztvevő lehet eladó és vevő is (\az+\refstruc{epointdetails+ben} látni fogjuk, hogy a szerver nem is tudja, hogy éppen kivel áll szemben), a rendszer peer--to--peer. Naiv tranzakciók bonyolítására lehetőség van, Alice egy bankjegyének a $D_i$ titkát egyszerűen odaadhatja Bobnak, aki akkor dolgoztatja fel a cserét a szerverrel, amikor kívánja. A nyilvános adatbázis végigjárásával bárki, aki internethozzáféréssel rendelkezik ellenőrizheti, hogy a kibocsátó minden kérést rendben hajt végre és meggyőződhet a kibocsátott pénz mennyiségéről, így az auditálás megoldott. \part{A SecMS és az ePoint részletes bemutatása} A SecMS az OpenPGP 4-es verziójú csomagjaira épül, bemutatom az OpenPGP 4-es verziójának szükséges részeit, majd azokat a kiegészítéseket, amikkel lehetővé tettük az OpenPGP számítástakarékos, illetve kliens--szerver környezetben való használatát. Az ePoint specifikációját is részletesebben bemutatom, mint az előző részben, megnézzük a konkrét tranzakciók lebonyolításának módját és a technikai, műszaki megvalósítás pár részletét. A pontos, apróságokat is leíró specifikációt \cite{secms-prot}, illetve \cite{epoint-prot} tartalmazza. A rész utolsó előtti fejezetében specifikálom a SecMS ePointra épülő levélszemét kezelő protokollját, illetve az ePoint SecMS-re épülő számlázási és fizetési protokollját. Az utolsó fejezetben olyan problémákat vizsgálok, amik jelenleg a mikrofizetések megoldatlansága miatt léteznek és így az ePointtal megszüntethetőek. \chapter{SecMS} A SecMS üzenetek az emailhez hasonlóan szervereken keresztül jutnak el a feladótól a címzetthez. Lényegi különbség a már leírt biztonsági követelményeken túl, hogy a protokollt a kezdetektől fogva úgy terveztük, hogy lehetőség legyen a kliens--szerver paradigmán túlmutató peer--to--peer üzenetküldésre is, pl. bluetooth vagy SMS használatával, esetleg valamilyen instant üzenőrendszerbe (XMPP, MSN, stb.) ágyazva. Az OpenPGP\cite{rfc4880} szabványra építve pontosan specifikáltuk az üzenetek rejtjelezését, integritás-védelmét, címzését, ezért válik lehetségessé a fent leírt csatornafüggetlenség, hiszen tetszőleges csatornán átvihetők a specifikált bájt sorozatok. Az sem okoz problémát, ha a csatorna nem 8 bites, ugyanis az OpenPGP-ben már erre is gondoltak, az ún. armoring technológiával megoldható tetszőleges OpenPGP csomag 7 bites sorozatként való ábrázolása. Természetesen a mindennapi felhasználás során túlnyomóan a szerveren keresztül váltanak üzeneteket a felhasználók, hiszen ez a módszer érhető el a legolcsóbban a lehető legtöbb platformról. Ezért az OpenPGP specifikációját nem csak a SecMS üzenetek kriptográfiájával kellett kibővítenünk, hanem lehetővé kellett tennünk az OpenPGP-ben kliens--szerver parancsok leírását is. Hasonlóan ahhoz, ahogy az email működéséhez is szükséges volt a pontos fejléc- és formátumleírásokon túl az SMTP, POP3 (vagy IMAP) protokollok specifikálása. \section{OpenPGP} Az OpenPGP specifikációja nagyon bonyolult. Implementációt csak az eredeti specifikáció alapján\cite{rfc4880} szabad készíteni, semmiképp nem az itt kiemelt részletek szerint. A szabvány vizsgálata közben nagy segítségére lehet a fejlesztőnek a \texttt{pgpdump} nevű segédprogram, amivel vizsgálhatja egy bájt sorozatnak a szabvány szerinti felépítését. \subsection{Alaptípusok ábrázolása az OpenPGP-ben} \begin{itemize} \item \emph{előjel nélküli számok}: a szükséges mérettől függően 2 vagy 4 bájton, mindig big-endian formátumban. \item \emph{előjel nélküli, nagy számok (MPI-k)}: a kriptográfiában sokszor szükséges különösen nagy természetes számok kezelése, ezek ábrázolása egy olyan bájt sorozatként történik, melynek első két bájtja mondja meg (előjel nélküli számként) az ábrázolt szám bitjeinek számát, majd maga a szám következik big-endian formátumban. Az ábrázolás mindig egész számú bájton történik, a fölösleges bitek értéke nulla kell, hogy legyen és azokat a bal oldalon kell szerepeltetni. Az említett bithosszleírás ettől függetlenül, csak az értékes bitek számát jelzi. \item \emph{kulcsazonosítók}: 64 bites számérték, ami egy nyilvános kulcsot azonosít (nem feltétlenül egyértelműen), ezt az értéket a nyilvános kulcsból és a létrehozási idejéből egy hash függvény segítségével számolják. \item \emph{szövegek}: Unicode karakterláncok az UTF-8 szabvány szerinti kódolással. \item \emph{másodperc felbontású dátum}: 4 bájtos számérték, ami az 1970. január 1-e éjfél óta eltelt másodpercek számával ábrázolja az időpontot. Ez ugyanaz az ábrázolás, mint a (32-bites) Unix alapú rendszerek esetében, azzal a különbséggel, hogy az OpenPGP szabvány előjel nélküli 4 bájtos egészt rögzít, nem pedig előjeleset, így későbbi időpontok ábrázolása is lehetséges.\footnote{Az előjeles egészek használatával 2038. januárjában, míg az előjel nélküliek használatával 2106. februárjában lesznek problémák.} \item \emph{adathossz leírás}: 1, 2 vagy 5 bájtos számérték, olyan kóddal, hogy a kisebb értékekhez rövidebb kód tartozik, egy hossz (pozitív egész) reprezentálása: \begin{itemize} \item 0 és 191 között 1 bájtként, \item 192 és 8383 között 2 bájtként, az 1. bájt kötelezően nagyobb, mint 191, a következő képlettel: $256 (\texttt{bájt1}-192) + \texttt{bájt2} + 192$, \item 8384 és 4294967295 között 5 bájtként, az 1. bájt kötelezően 255, a következő képlettel: $256(256(256(\texttt{bájt2})+\texttt{bájt3})+\texttt{bájt4})+\texttt{bájt5}$ történik. \item Lehetőség van hosszabb adat esetén az adat és hossz szinkronizált, folyamatos közlésére, azonban erre a SecMS esetében sosincs szükség. \end{itemize} \end{itemize} \subsection{Az OpenPGP csomagok szerkezete} \begin{figure}[htp] \centering \begin{bytefield}{24} \wordgroupl{1. csomag} \wordgroupr{Fejléc} \bitheader{0-2,7-8} \\ \bitbox{1}{1} & \bitbox{1}{1} & \bitbox{6}{típus} & \bitbox{16}{hossz (1, 2 vagy 5 bájt)} \endwordgroupr \\ \wordbox[lrb]{1}{adat} \endwordgroupl \\ \wordbox[]{1}{$\vdots$ \\[1ex]} \\ \wordgroupl{Utolsó csomag} \wordgroupr{Fejléc} \bitbox{1}{1} & \bitbox{1}{1} & \bitbox{6}{típus} & \bitbox{16}{hossz (1, 2 vagy 5 bájt)} \endwordgroupr \\ \wordbox[lrb]{1}{adat} \endwordgroupl \end{bytefield} \caption{OpenPGP csomagformátum} \end{figure} Minden OpenPGP csomag a fejlécében leírja a típusát 6 biten, valamint az adattartalom (csomagtörzs) hosszát. Mivel a csomag törzse előtt ismert a hossza, ezért több csomag egyszerű egymásután írással összefűzhető, egy érdektelen csomag a megadott hossz szerint átugorható. A diplomamunkában felhasznált OpenPGP csomagtípusok: \begin{center} \begin{tabular}{r|l} 1 & Titkos--nyilvános kulcsú rejtjelezés inicializációja \\ 2 & Titkos--nyilvános kulcsú digitális aláírás\\ 6 & Nyilvános kulcs \\ 11 & Egyszerű, nyílt szöveg \\ 13 & Felhasználói azonosító \\ 18 & Szimmetrikusan rejtjelezett, integritás védett adatcsomag \\ 19 & Integritás védelem a 18-as csomaghoz \\ 60 & SecMS utasítások \\ 61 & Új felhasználó regisztrációja a SecMS-be \\ 62 & Jelenlegi felhasználó ``bejelentkezése'' a SecMS-be \\ 63 & SecMS szerver nyilvános kulcsának letöltése \end{tabular} \end{center} Bemutatom, hogyan lehet ezekkel a csomagtípusokkal a szükséges adatokat, illetve (a hálózaton átküldendő) üzenetváltásokat reprezentálni. Az ábrákban a csomagok adat tartalmát szemléltetem, természetesen minden csomagot megelőz a fejléce. \subsection{DSA nyilvános kulcsok ábrázolása} \begin{figure}[htp] \centering \begin{bytefield}{24} \wordgroupr{6-os csomag} \bitbox[trl]{6}{4} \bitbox[trl]{12}{Generálás ideje} \bitbox[trl]{6}{17} \\ \wordbox{1}{$p$, $q$, $g$, $y$} \endwordgroupr \\ \wordgroupl{13-as csomag} \wordbox[lrb]{2}{\texttt{Teljes név }} \endwordgroupl \\ \wordgroupr{2-es csomag} \wordbox[lrb]{1}{Saját hitelesítő aláírás} \endwordgroupr \\ \wordgroupl{2-es csomagok} \wordbox[lrb]{1}{További hitelesítő aláírások} \endwordgroupl \end{bytefield} \caption{DSA kulcs leírása OpenPGP csomagokkal} \end{figure} A SecMS-ben minden felhasználó rendelkezik egy DSA kulccsal, amit titokban tart és segítségével tetszőleges bájt sorozatot hitelesíteni tud. A SecMS-ben kötelezően használt $p$, $q$, $g$ értékeket \cite{secms-prot} rögzíti, a Diffie-Hellman kulcsmegegyezés, amit felhasználunk, csak egyező értékek mellett működik. Bármilyen nyilvános kulcs, így a DSA kulcsok leírása is a 6-os azonosítójú csomaggal történik. Ebben a csomagban kell leírni a $p,q,g,y$ értékeket. Valamint itt meg kell adni a generálás idejét másodperc felbontású dátumként. A 4-es érték a kulcs verziószáma, minden új szoftvernek 4-es verziójú kulcsokat ajánlott létrehoznia, a 17-es érték pedig azt jelzi, hogy ez egy DSA kulcs. Pazarlásnak tűnhet az, hogy a sok különböző felhasználó mindegyikéhez közöljük a $p,q,g$ értékeket, pedig azok változatlanok és nyilvános szabványban, a SecMS részeként specifikáltak lesznek. Dönthetnénk úgy is, hogy bevezetünk egy új kulcstípust, amely esetében a $p,q,g$ értékek rögzítettek és csak az $y$ változhat. A 17-es érték helyett egy új értéket választanánk a 100-110-es tartományból, amely a kísérleti, illetve privát felhasználásra van fenntartva. Azonban ezzel a spórolással megakadályoznánk, hogy meglévő OpenPGP implementációk megértsék a felhasználóink kulcsait (és számukra például titkosított üzeneteket küldjünk, vagy az általunk kiállított digitális aláírásokat ők ellenőrizzék). A legtöbb jövőbeni SecMS felhasználónak jelenleg nincs PGP kulcsa, nem használ OpenPGP technológiát, a kompatibilitás megtartásával biztosítjuk, hogy a SecMS miatt létrehozott kulcsát később használhassa más célokra is. A 6-os csomag után a 13-as csomag tartalmazza a felhasználó nevét és email címét, majd ennek a névnek és címnek a kulcshoz való hozzárendelését hitelesítő aláírások következnek. Ezek között szerepelnie kell egy saját hitelesítő aláírásnak (ún. self signature-nek), az ezzel nem rendelkező kulcsokat az implementációk elutasítják. \subsection{Aláírások ábrázolása} Az OpenPGP 4-es verziójától kezdve a digitális aláírások formátuma megengedi, hogy azokhoz előre meghatározott típusú metaadatokat (pl. készítés időpontja, lejárat időpontja, aláírás visszavonásának az oka), illetve saját metaadatokat csatoljunk (név-érték párokként). Az aláírás ilyen metaadatokat kétféleképpen tartalmazhat. Amennyiben az aláíráshoz hashelt, akkor az aláírás sikeres ellenőrzése a metaadat hitelességét is jelenti, amennyiben ahhoz nem hashelt, akkor nem. Hash\-elt metaadat például az aláírás létrehozási ideje, míg nem hashelt az aláíró személy kulcsazonosítója. Minden metaadat egy külön alcsomagban foglal helyet. Az alcsomagok a csomagokhoz hasonlóan leírják a saját méretüket, így azokból több egyszerűen egymásután írható. Az alcsomagok pontos formátumát \az+\ref{subpackfigure}. ábra mutatja. Típusukat egy bájt határozza meg, az általunk felhasznált típusok: \begin{center} \begin{tabular}{r|l} 2 & az aláírás készítésének ideje másodperc felbontású dátumként \\ & (self signature esetén egyezik a kulcs készítésének idejével)\\ 3 & az aláírás lejárata, a létrehozástól számított másodpercekként 4 bájton, \\ & (ha ez a csomag hiányzik vagy az érték nulla, akkor sosem jár le) \\ 16 & az aláírás kibocsátójának 8 bájtos kulcsazonosítója \\ 20 & tetszőleges név--érték pár (notation data) (ld. \ref{notationfigure}. ábra) \end{tabular} \end{center} \begin{figure}[htp] \hspace{-1cm} \begin{bytefield}{32} \wordgroupr{Fejléc} \bitbox{24}{Hátralévő hossz (1, 2 vagy 5 bájt)} \bitbox{8}{típus} \endwordgroupr \\ \wordbox[lrb]{1}{adat} \end{bytefield} \caption{Aláírási alcsomagok formátuma} \label{subpackfigure} \end{figure} \begin{figure}[b] \makeFootnotable{} \footnotestyle{mpmark=stars} \centering \begin{bytefield}{40} \bitbox{10}{Jellemzők\footnote{1 bájt: 128, ha az érték UTF-8 kódolású szöveg, egyébként 0.}} \bitbox{10}{0} \bitbox{10}{0} \bitbox{10}{0} \\ \bitbox[lrb]{20}{Név hossza 2 bájton} \bitbox[lrb]{20}{Érték hossza 2 bájton} \\ \bitbox[lrb]{20}{Név\footnote{\texttt{valami@valahol.com} alakú UTF-8 kódolású szöveg az ütközések elkerülésére.}} \bitbox[lrb]{20}{Érték} \end{bytefield} \caption{Név--érték pár ábrázolása a 20-as alcsomagban} \label{notationfigure} \end{figure} A DSA digitális aláírást az aláírandó üzenet és a hashelt metaadatok SHA-1 értékére számoljuk. Amennyiben \az+\refstruc{keyhandling+ben} ismertetett kulcskezelő aláírásról van szó, akkor az üzenet az aláírandó kulcs és felhasználói név. Természetesen ennél sokkal precízebben specifikálni kell a hash függvény argumentumának a felépítését, hiszen a digitális aláírás ellenőrzése csak akkor lehet sikeres, ha ez a specifikáció félreérthetetlen. A szabvány pontosan specifikálja is a hash függvény bemenetét, a specifikációt később \az+\ref{sighashfigure}. ábra segítségével összefoglaljuk. \begin{figure}[t] \centering \begin{bytefield}{32} \wordgroupr{($\alpha$)} \bitbox[trl]{8}{4} & \bitbox[trl]{8}{$t$} & \bitbox[trl]{8}{17} & \bitbox[trl]{8}{2} \\ \bitbox[trl]{32}{Hashelt csomagok hossza (2 bájt)} \\ \bitbox[trl]{32}{Hashelt csomagok} \endwordgroupr \\ \bitbox[trl]{32}{Nem hashelt csomagok hossza (2 bájt)} \\ \bitbox[trl]{32}{Nem hashelt csomagok} \\ \bitbox[trl]{32}{Hash érték első két bájtja} \\ \bitbox{32}{$r, s$; mindkettő MPI-ként} \end{bytefield} \caption{DSA digitális aláírás az OpenPGP-ben (2-es csomag)} \label{sigfigure} \end{figure} A digitális aláírást és a hozzá tartozó metaadatokat egy 2-es azonosítójú csomag tartalmazza (ld. \ref{sigfigure}. ábra), szerepel benne az aláírás verziója (4), az aláírás típusa ($t$, 0 bináris üzenet, 1 CRLF sörvégű szöveges üzenet\footnote{Azaz olyan szöveges üzenet, amiben a sorvégeket az ASCII táblázat 10-es és 13-as karakterének egymásutánja jelzi.}, illetve 16 és 19 közötti érték kulcs-felhasználónév hozzárendelés esetén a megbízhatóság fokától függően), a használt digitális aláírás algoritmusának azonosítója (17 DSA esetén), a használt hash függvény azonosítója (2 SHA-1 esetén), a hash\-elt, majd a nem hashelt metaadatok hossza és tartalma, a kiszámolt hash érték első két bájtja, majd a hash érték digitális aláírása (DSA esetén $r, s$) előjel nélküli nagy számok sorozataként. A kétféle alcsomagok előtti méret megadása valóban szükséges, hiszen maguk a csomagok saját hosszukat leírják, de ebből nem lehet következtetni az összes csomag hosszára. Feleslegesnek tűnik a hash érték első két bájtjának közlése előre, hiszen a digitális aláírás úgyis pont az egész értéket (nem csak az első két bájtját) hitelesíti majd. Azért szól így a szabvány, mert az aszimmetrikus kriptográfiai műveletek (és így egy nyilvános kulcsú aláírás ellenőrzése is) drágák. Hálózati hiba, sérült adathordozó vagy bármilyen más adathiba esetén ez a két bájt már nagyon nagy valószínűséggel eltér és így az aláírás olcsón visszautasítható. Természetesen ennek az értéknek a helyes volta semmilyen biztonságot nem nyújt, hiszen ha egy támadó meg tudja változtatni az aláírt adatot, akkor nyilván ezt a hash értéket is újraszámolhatja és felülírhatja. \begin{figure}[b] \makeFootnotable{} \footnotestyle{mpmark=stars} \centering \begin{bytefield}{32} \wordbox{1}{Üzenet\footnote{Szöveges üzenet esetén ($t\mathop{=}1$) CRLF sorvéggel hashelendő az üzenet. Kulcshitelesítéskor ($t\mathop{\in}[16,19]$) üzenetként \az+\ref{sighashkeyfigure}. ábrán szemléltetett bájtok hash\-elendők.}} \\ \wordbox[rl]{1}{($\alpha$) \az+\ref{sigfigure}. ábrából} \\ \bitbox[blrt]{4}{4} \bitbox[bt]{4}{255} \bitbox[brlt]{24}{($\alpha$) hossza, 4 bájton} \end{bytefield} \caption{A SHA-1 hash függvény bemenete aláíráskor} \label{sighashfigure} \end{figure} \begin{figure}[t] \centering \begin{bytefield}{44} \bitbox{4}{153} \bitbox{20}{6-os csomag hossza 2 bájton} \bitbox{20}{6-os csomag törzse} \\ \bitbox[rlb]{4}{180} \bitbox[rlb]{20}{13-as csomag hossza 4 bájton} \bitbox[rlb]{20}{13-as csomag törzse} \end{bytefield} \caption{Kulcs és felhasználói név kanonikus ábrázolása} \label{sighashkeyfigure} \end{figure} \subsection{Rejtjelezett üzenet ábrázolása} Mind szimmetrikusan rejtjelezett, mind (akár több) nyilvános kulcs számára kódolt üzenetek ábrázolását támogatja az OpenPGP. A rejtjelzendő adathoz (ami tipikusan egy vagy több másik OpenPGP csomag, pl. tömörített vagy nyílt szöveg) először hozzá kell fűzni az integritás védelmet szolgáló 19-es csomagot, majd az egész struktúrát kell kódolni, így keletkezik a 18-as csomag. A kódolás mikéntjét címzettenként egy külön csomaggal kell jelezni a 18-as előtt. Nyilvános kulcsú kriptográfia esetén erre az 1-es csomag való, szimmetrikus esetben a 3-as. Ezek a csomagok tartalmaznak minden szükséges adatot (algoritmus azonosítók, kódolt session kulcs), ami a címzett titkos kulcsán, illetve szimmetrikus esetben a jelszón kívül szükséges az üzenet megfejtéséhez. Az OpenPGP szabványba a mi általunk használni kívánt RC4 kódolás jelenleg nincs beillesztve, a SecMS-ben nem használunk semmilyen jelenleg definiált rejtjelezést az OpenPGP-ből, ezért azoknak az egyébként is bonyolult részleteit nem ismertetem. Bemutatom viszont, hogy hogyan integrálta kutatócsoportunk az RC4-et a szabványba. Az itt bemutatott specifikációt (vagy ahhoz nagyon hasonló megoldást) fogunk javasolni az OpenPGP következő verziójába való elfogadásra a megfelelő fórumokon. Erre szükség van, ugyanis az OpenPGP jelenleg nem kínál alternatívát olyan kis számításkapacitású környezeteknek, mint a mobiltelefonok, annak ellenére, hogy a készülékek gyorsan terjednek, fejlődnek és a programozhatóságuk javul. \section{SecMS kiegészítések az OpenPGP-hez} A SecMS megvalósításához két szempontból kellett kiegészíteni az OpenPGP-t. Az üzenetek rejtjelezésére és integritás védelmére olcsóbb, minimalista eszközöket (RC4, RIPEMD-128) illesztettünk az OpenPGP-be, másrészt a kliens--szerver paradigma megvalósításához specifikáltunk egy kiegészítést. Ezenkívül a SecMS mostani megvalósításában lehetséges a szerverre kulcsokat feltölteni (új felhasználó regisztrálásához), illetve a szervertől le lehet kérdezni a saját nyilvános kulcsát. Ezeket a kiegészítéseket azonban nem ismertetem, mivel ezek átmenetiek, a későbbi verziók nem fogják támogatni. A szerver kulcsát ugyanis sokkal egyszerűbb és biztonságosabb a kliensprogramba ágyazni és így annak telepítése után már rendelkezésre áll, az új kulcsok szerverre való feltöltésére pedig már van kulcskezelő protokoll\cite{hkp-draft}, amit az interoperabilitás érdekében amúgy is támogatnunk kell. \subsection{Üzenetek rejtjelezése és integritás védelme} Az OpenPGP rejtjelezésére építve, minden titkosított üzenetet 3 csomag együttese reprezentál (ld. \refstruc{encryptionfigure}), a 18-as tartalmazza a rejtjelezett levelet, a beleágyazott 19-es az integritás védelmet biztosító hash értéket, a 18-ast megelőző egy vagy több 1-es (a címzettek számától függően) a rejtjelezés inicializáló adatait. Az alapján lehet felismerni a SecMS speciális, RC4-et használó titkosított csomagjait, hogy az 1-es csomagokban a privát felhasználásra fenntartott 100-as érték szerepel, mint algoritmusazonosító. Új levél küldése esetén az 1-es csomag közli az üzenet címzettjét is, a szerver a címzett levelesládájába lementi a titkosított üzenetet a feladó kulcsazonosítójával, illetve a feladó--szerver kommunikációjából kiszámítható $R$ értékkel együtt. A 18-as csomag rejtjelezett részének kódolása RC4-el történik, a RIPEMD-128$(g^{ab}|R)$ kulccsal (ahol $a$ és $b$ a kommunikáló felek titkos kulcsait jelölik, ld. \refstruc{diffie-hellman}), az integritás védelmet a szabványtól eltérően (hatékonysági megfontolásokból) a 19-es csomagban nem a SHA1, hanem szintén a RIPEMD-128 hash függvény biztosítja. Fontos megjegyezni, hogy ez a módszer valóban rendkívül takarékos. A $g^{ab}$ érték minden olyan üzenetben azonos, ahol ugyanaz a két személy kommunikál, így ez az érték a kliensprogram által megjegyezhető, nem szükséges mindig újra és újra kiszámolni. A hálózati forgalommal is takarékos ez a módszer, a feladó kulcsazonosítóján és az $R$ értéken kívül semmi más nem szükséges a címzettnél az üzenet megfejtéséhez. Ugyanakkor a kódoló kulcs minden üzenethez teljesen más, az $R$ (lényegében) véletlen érték és a RIPEMD függvény miatt. Az RC4 folyam első 256 bájtját nem használjuk. Mindezen megfontolásokkal elkerüljük, hogy protokollunk \az+\refstruc{rc4+ben} ismertetett biztonsági hiányosságok bármelyikével rendelkezzen. \begin{figure}[bt] \makeFootnotable{} \footnotestyle{mpmark=stars} \centering \begin{bytefield}{24} \wordgroupr{1-es csomagok, 100-as \\ algoritmus azonosítóval} \wordbox[rlbt]{1}{1. címzett} \\ \wordbox[]{1}{$\vdots$ \\[1ex]} \\ \wordbox[rlbt]{1}{Utolsó címzett} \endwordgroupr \\ \wordgroupr{18-as csomag, XOR-olva a \\ $(g^{ab}|R)$\footnote{Több címzett esetén a $(g^{ab}|R)$ értékkel csak egy sorsolt session kulcs van titkosítva az 1-es csomagokban és itt az a véletlen érték a rejtjelező kulcs.} kulcsú RC4 folyammal} \wordbox[rlb]{1}{Üzenet ($m$)} \\ \wordbox[rlb]{1}{RIPEMD-128($m$), 19-es csomagként} \endwordgroupr \end{bytefield} \caption{Üzenetek rejtjelezése} \label{encryptionfigure} \end{figure} \subsection{Kliens--szerver üzenetváltás} Rejtjelezve, authentikálva és az integritást védve kell, hogy a kliensprogramok és a SecMS szerver üzeneteket váltson. Ezt a három követelményt könnyedén meg lehet oldani az előbb ismertetett módon, csak most arról van szó, hogy az egyik szereplő ($a$) a kliensprogram, a másik ($i$) pedig a szerver. Így a Diffie-Hellman kulcsmegegyezésben RIPEMD-128($g^{ai}|R$) titkok alakulnak ki, amiket a szerver is ki tud számolni, ugyanis az $R$ értéket kapcsolatonként szekvenciálisan növeli a kliensprogram (a kezdőértékben együtt egyeznek meg), a $g^a$ nyilvános kulcshoz tartozó azonosítót ($K_{64}(a)$) pedig a levél címzettjének a helyén megadja a kapcsolatkezdeményező kliens. A rejtjelezett adattartalom kliens--szerver üzenet esetén nem levél, hanem levélkezelő parancsok\footnote{Fontos, hogy több parancs is küldhető egy csomagban, ugyanis így a forgalomanalizálás ellen is valamekkora védelmet nyújthat egy ügyes megvalósítás.} (postaláda listázása, letöltése, új üzenet küldése, levelek törlése, mappák közti mozgatása, stb.), amiknek a formátuma is specifikált, nem ismertetett kriptográfiai (vagy egyéb érdekes) problémát azonban ez a specifikáció nem tartalmaz, csupán olyan jellegű kérés--válasz párok formalizálása, mint ``14-es számú üzenet letöltése''--``14-es üzenet''. \section{Az üzenetek belső formátuma} \label{secms-mess-format} Nem esett még szó arról, hogy a mindenhol hivatkozott $m$ karaktersorozat formátuma milyen. Ennek specifikálása is fontos, hiszen különben a kliensprogramok nem tudnak együtt működni. A SecMS-ben az üzenetek nyílt tartalma egyszerű szöveges üzenet esetén UTF-8\cite{rfc3629} kódolású Unicode szöveg, bonyolultabb esetben egy tetszőleges MIME üzenet. Az üzenettől elválasztható, bizonyító erejű aláírások készítése így SecMS-ben is az S/MIME előírásai szerint működik a felhasználó DSA kulcsával. Habár ez drágább, mint a hamarosan bemutatott rejtjelezés és integritásvédelem, cserébe jóval ritkábban is van rá szükség. Akár MIME, akár szöveges üzenetről van szó, az üzenet törzsét megelőzhetik fejlécek, a \cite{rfc822}-ben látott módon: \begin{verbatim} Fejléc1: tartalom1 Fejléc2: tartalom2 Törzs (MIME vagy UTF-8) \end{verbatim} A mobil környezetben való takarékosság és egyszerűség érdekében a sorvégeket a SecMS üzeneteiben a 10-es ASCII kódú karakter egyedül jelzi, a fejlécekben tetszőleges UTF-8 karakterlánc megengedett. \chapter{ePoint} \label{epointdetails} \Az+\refstruc{epointoverview+ban} bemutattam nagy vonalakban az ePoint működését. Most áttekintem, hogy pontosan milyen tranzakciók is vonatkoznak az $S_i$ ígérvényekre, illetve a lehetséges kriptográfiai kihívások fajtáira, majd a kereskedés módjára és a technikai megvalósítás részleteire is kitérek. \section{Tranzakciótípusok} Az $N_i$ tranzakciós kérést sikeres feldolgozás esetén a szerver mindig elmenti a létrejövő nyilvános $S_i$ ígérvény részeként, mint indoklást. A kérés a következők valamelyike lehet: \begin{itemize} \item $\mathcal{E}$: kibocsátás kérvényezése. Ez az üzenettípus kötelezően tartalmazza az érték és kihívás digitális aláírását valamely kibocsátásra jogosult személytől; \item $\mathcal{X}$: csere. Az ilyen kérvény tartalmaz egy korábban már nyilvánosságra hozott $S_j$-hez ($j>>>>>> .r1627 $$ V = \sum_{i:N_i\in\mathcal{E}} V_i - \sum_{i:N_i\in\mathcal{I}} V_{N_i.j} $$ \section{Kriptográfiai kihívások} Az elmondottak működéséhez szükséges, hogy nagy mennyiségben tudjunk olyan matematikai feladatokat generálni, amelyeknek generálása és a megoldás ellenőrzése gyors, de csak a feladatból a megoldás előállítása reménytelenül lassú. Minden ilyen kihívás egy olyan $C$ feladat, amihez tartozó $R$ válasz bizonyítja, hogy a válaszadó birtokában van a $D$ titoknak, ami alapján a $C$ készült. Több lehetséges kihívást is támogat a rendszer, hogy a felhasználó a neki megfelelő (a védett érték és a számítási környezet szerinti) biztonságú megoldást választhassa. \subsection{Hash értékhez tartozó őskép} \emph{Kihívás: } $C=h(D)$. \noindent \emph{Titok: } $D$, véletlen bájt sorozat, a $C$ ősképe $h$ szerint. \noindent \emph{Megfejtésként adott válasz: } $R=D$, elfogadható, ha $h(R)=C$. A $h$ valamilyen hash függvény, pl. a SHA-1. Az előnye ennek az egyszerű kihívásnak, hogy nagyon gyorsan generálható, viszonylag kicsi titkokat eredményez (kb. akkorákat, mint a SHA-1 képe, azaz 160 bit), amik akár szűk csatornákon is átvihetők (beszéd, billentyűzet, vonalkód). Így az ilyen jellegű kihívásokkal könnyen megvalósíthatóak a naiv tranzakciók. Mivel a hash értéke a titoknak nagyon gyorsan kiszámolható, magát az ígérvényt nem is muszáj feltétlenül a titokkal együtt tárolnunk és átadnunk, az mindig lekérdezhető a nyilvános adatbázisból. Hátrány, hogy a válasz pontosan egyezik a titokkal, így nem megbízható csatornán nem használható, illetve a kibocsátó csalási kísérlete ellen sem véd. \subsection{Nyilvános kulcshoz tartozó digitális aláírás} \emph{Kihívás: } $C=K$, egy aszimmetrikus nyilvános kulcs. \noindent \emph{Titok: } $D=K'$, a $K$-hoz tartozó titkos kulcs. \noindent \emph{Megfejtésként adott válasz: } $R=\sigma_K(N')$, a végrehajtandó $N'$ tranzakciós üzenet $K$-val aláírt példánya. Bármilyen digitális aláírási séma megfelel (pl. a DSA vagy az RSA), a kulcsot minden kihíváshoz újonnan kell egy elegendően nagy halmazból véletlenszerűen választani, hogy egy támadó azt ne tudja kitalálni. A nyilvánvaló hátránya ennek a módszernek a rendkívül magas számítási és tárolási költsége. Egy nyilvános--titkos kulcspár generálása még számítógépen is lassú, a létrejövő kulcs mérete is jóval nagyobb, mint egy hash függvény ősképe. Előnye ezeknek a kihívástípusnak, hogy a válasz akár nem megbízható csatornán is továbbítható, valamint a kibocsátó ellen is véd, mivel a $D$ titok később (még a tranzakció feldolgozása után) sem kerül felfedésre, így az aláírt $N'$ üzenet módosítása senki számára nem lehetséges. \subsection{Adott hashű nyilvános kulcshoz tartozó aláírás} \emph{Kihívás: } $C=h(K)$, egy aszimmetrikus nyilvános kulcs hash értéke. \noindent \emph{Titok: } $D=(K,K')$, a titkos--nyilvános kulcspár. \noindent \emph{Megfejtésként adott válasz: } $R=(\sigma_K(N'), K)$, a végrehajtandó $N'$ tranzakciós üzenet $K$-val aláírt példánya és a $K$ kulcs. Ez a kihívás az előzőnek a módosítása annyival, hogy a szerveren tárolandó kihívás pontosan ugyanúgy néz ki, mint az első esetben. Ez azzal az előnnyel jár, hogy a nyilvános kulcs nem áll rendelkezésére az esetleges támadónak, így elég kisebb nyilvános kulcsokat is használni. Egyáltalán, az esetleges támadó (illetve a kibocsátó) azt sem tudhatja egészen a felhasználás pillanatáig, hogy az ilyen kihívású ePoint valóban ilyen, és nem egy egyszerű véletlen karakterlánc hash értéke, mint az első esetben. \subsection{Rejtjelezett nyilvános kulcshoz tartozó aláírás} \emph{Kihívás: } $C=(K, \rho_D(K'))$, egy aszimmetrikus nyilvános kulcs és a titkos kulcs $D$-vel rejtjelezve. \noindent \emph{Titok: } $D$, egy véletlenül választott rejtjelező kulcs. \noindent \emph{Megfejtésként adott válasz: } $R=\sigma_K(N')$, a végrehajtandó $N'$ tranzakciós üzenet $K$-val aláírt példánya. Ez egy másik módosítása a nyilvános kulcsos kihívásnak. Azt a problémát oldja meg, hogy a pénz birtokosának ne kelljen nagy titkokat tárolnia és küldenie. Ugyanis a titkos kulcsot maga a szerver tárolja, de rejtjelezett formában. Csak az fér hozzá a titkos kulcshoz és így az ePointhoz, aki a $D$ szimmetrikus kulccsal tisztában van. A $D$ már elegendő, ha kb. 100 bites. Ugyanakkor mivel a $D$-ből nem lehet következtetni az ePoint indexére, annak a tárolása is szükséges. A két érték együtt kb. akkora, mint az első kihívástípus esetében, így ez a megoldás is használható az ott felsorolt csatornákkal akár naivan is. \section{A kereskedés módjai} Az ePoint rendszerben nem csak a megfelelő kihívás megválasztása során vehetik figyelembe a felhasználók az aktuális biztonsági meggondolásaikat, illetve környezetüket. Ugyanis a kihívás megválasztásakor csak az ePoint értékét tudják, azonban egy tranzakció során legalább ilyen fontos a használt csatorna, a másik fél személye, korábbi ismeretségük, az üzlet tárgya. Ezektől is függővé tehetik, hogy miként is kereskednek. A két módszer közül az első a teljes bizalomra épít, hasonlatos egy üdítő automatához, ahol egyik fél sem tud reklamálni később, a második pedig a bolti vásárláshoz, ahol bizonyító erejű számla készül. \subsection{Előre fizetés} Tegyük fel, hogy Alice szeretne Bobnak 10 ePointot adni. Feltesszük azt is, hogy van köztük valami olyan biztonságú csatorna, amit az adott érték mellett elfogadhatónak tartanak. Alice keres a pénztárcájában egy vagy több olyan titkot, ami(k) legalább 10 ePointot ér(nek). Amennyiben csak csupa kisebbet talál, azokat össze tudja vonni a $\mathcal{M}$ használatával egy nagyobbá. Ezután, vagy ha csak nagyobb értékűt talál, akkor az $\mathcal{S}$ jelű üzenettípussal ki tud vágni pontosan 10 ePointot. A létrejött 10 ePoint értékű titkot ($D$) elküldi Bob részére, aki az $\mathcal{X}$ üzenettípussal becseréli egy saját maga által generált kihívású ePointra. A tranzakció anoniman zajlott le, Alice és Bob csak egymással kommunikált, a kibocsátónak egyiküknek sem kellett megmondania a másik kilétét. \subsection{Számlás fizetés} A szereplők és az összeg legyen változatlan, azonban most feltesszük, hogy Alice nem szeretné kitenni magát annak a veszélynek, hogy Bob az ePointok beváltása után letagadja az üzletet és ne teljesítse a vállalását. Ekkor először egyeztetik az árat és a terméket Bobbal és Bob erről kiállít egy digitálisan aláírt számlát, amibe beleír egy általa választott kihívást is (természetesen a kihívásnak csak a nyilvános részét, $C$-t). Alice a számla és a rajta lévő digitális aláírás ellenőrzése után bevált egy 10 ePointost az $\mathcal{X}$ típusú üzenettel olyanra, aminek a kihívása a Bob által adott $C$. Ebben a pillanatban Alice kezében nyilvánosan ellenőrizhető, akár bíróság által feldolgozható bizonyíték van arra, hogy Bobbal megegyezett és a saját vállalását, a fizetést teljesítette. Természetesen ezt a bizonyítékot harmadik fél előtt csak akkor kell felfednie, ha vita kerekedik. Az esetek túlnyomó többségében az üzlet rendben lezajlik és a tranzakció anonim marad. Fontos még észrevenni, hogy a kibocsátó által üzemeltetett ePoint szerver számára a két féle fizetés nem különböztethető meg, ő mindkét esetben egy $\mathcal{X}$ kéréssel találkozott, azonban egyik esetben a fizető fél küldte a kérést, másik esetben az eladó fél. \section{Technikai megvalósítás} Schuller elkészítette diplomamunkaként\cite{epoint-prot} egy egyszerű, HTTP(S) alapú megvalósítását a kibocsátó szerverein futó szoftvernek. A diplomamunkájában pontosan specifikálja, hogy ezzel a szerverrel miként kell a fent leírt tranzakciókat HTTP(S) felületen végrehajtatni, miként lehet a nyilvános adatbázist lekérdezni. A HTTP(S) alapú megvalósítás egyik nagy előnye, hogy egy egyszerű böngészővel meg lehet nézni egy-egy adott sorszámú ePointot. A SecMS-sel való integrálás során a SecMS kliensről feltételezzük, hogy rendelkezik egy ePoint pénztárcával és abba a Schuller által ismertetett módon pénzt tud elhelyezni a szerver segítségével, illetve abból pénzt tud költeni. \chapter{A SecMS és az ePoint integrációja} A két részletesen bemutatott rendszer integrációjától két problémára várunk megoldást: egyrészt szeretnénk, ha az említett ePoint kereskedési módok megvalósulhatnának a SecMS használatával, másrészt szeretnénk, ha az ePoint előre fizetési rendszerével meg lehetne védeni a SecMS üzenőrendszert még elterjedése közben a spam ellen, örökre kiküszöbölve ennek a problémának a jövőbeni felmerülését. \section{ePoint előre fizetése a SecMS-ben} Ezt a feladatot a lehető legegyszerűbben szeretnénk megoldani, mivel minden egyes SecMS üzenetnek tartalmaznia kell majd egy minimális előre fizetést, ami a levél fogadó oldali elolvasásának a ráfordításait (idő, fáradság) fedezi. \Az+\refstruc{secms-mess-format+ban} látott módon lehetséges tetszőlegesen sok fejlécet csatolni egy üzenethez. Minden egyes átküldendő ePoint bankjegyet egy ilyen fejlécben küldünk el, több is lehet egy levélben. Schuller munkájában csak a hash függvény ősképére vonatkozó kriptográfiai kihívás van megvalósítva, így ebben a specifikációban is elegendő lehetőséget biztosítani az őskép átküldésére. Tehát minden egyes átutalandó ePointhoz a fejléc formája legyen a következő: \texttt{EPoint-Forward-Payment:} \texttt{\textit{}} Itt a \texttt{RAND} egy véletlen érték, a korábban $D$-nek hívott titoknak felel meg, \texttt{B64} pedig a Base64 függvény. A fejlécek a rejtjelezett üzenet részei, tehát a fizetéseket senki más nem tudja beváltani, csak a címzett. \section{Számlák formátuma, csatolása üzenetekhez} Számlák küldésére már jóval ritkábban van szükség, így azt egy új MIME típusként specifikálom. Ezzel az az előny is jár, hogy az itt leírt specifikáció később tetszőleges más MIME környezetben (web, email) is használható lesz számlák továbbításához. A számla kötelezően a \texttt{vnd.epointsystem.invoice} MIME típussal rendelkezik. A \texttt{vnd} névtér használata természetesen átmeneti megoldás, a rendszer széles elterjedése esetén kutatócsoportunknak célja elkészíteni és beadni a szükséges specifikációkat ahhoz, hogy szabványos \texttt{text/plain+epinvoice} jellegű típussal rendelkezhessünk. A számla csak akkor érvényes, ha hozzá egy S/MIME aláírás is tartozik. A számla kibocsátója az aláírókulcs tulajdonosa, így azt a számlában külön nem kell specifikálni. Minden számlának van egy kötelező sorszáma, ami a kibocsátóra vonatkozóan egyedi és folyamatosan, egyesével növekvő kell, hogy legyen. A számla tartalmazza a kibocsátó által generált új kihívást is, amire a fizetés elvégezhető. Amennyiben valakinek sok számlát kell kiállítania, hasznos lehet, ha a kihívásokhoz tartozó titkokat nem véletlenszerűen választja, hanem valamilyen titokból, a sorszámból és a dátumból generálja hash függvénnyel. Ezzel elérhető, hogy a még nem fizetett számlák után nem kell titkokat tárolni. Természetesen a beérkezett fizetések titkait azonnal teljesen véletlenszerűen generált titkokra kell cserélni a $\mathcal{X}$ üzenettípussal, hogy ne egy jelszó védjen folyamatosan növekvő értéket. A számla egy egyszerű szövegfájl, melyben minden sor végét az ASCII tábla 10-es karaktere jelzi. A számla végét egyetlen olyan sor mutatja, amiben csak a \texttt{\~} karakter szerepel (ASCII 126). A számlában szereplő kötelező mezők: \begin{verbatim} Serial: Challenge: Value: <érték ePoint egységben> Due: YYYY-MM-DD HH:MM:SS Expiry: YYYY-MM-DD HH:MM:SS Subject: . . . ~ \end{verbatim} Itt a \texttt{MD} (a korábban $C$-nek hívott érték) egy \texttt{RAND}-hoz tartozó hash érték. A számla \texttt{Due} mezője az esedékességet, a \texttt{Expiry} a lejáratot határozza meg. A \texttt{Subject} mezőben írható le akár több sorban is a termék, amelyről a számla szól. Valamely implementáció a saját mezőit (ami például utal a számlázószoftver készítőjére, elérhetőségeire) a \texttt{Subject} elé szúrhatja be, tetszőleges név--érték párokat rendelhetnek össze ezek a privát mezők is, azonban mindegyik nevének az \texttt{X-} prefixszel kell kezdődnie. Semelyik implementáció nem építhet ilyen mezők meglétére, minden olyan számla kezelése kötelező, ami a fent említett állandó mezők mindegyikét tartalmazza. \section{Levélszemét elleni védekezés} Beérkezett levél további feldolgozását, listázását csak akkor tegye bármilyen SecMS implementáció, ha legalább annyi előre fizetett ePoint beváltása sikerült a levél fejléceiből, amennyi a küldőhöz a felhasználó által beállított díj. Olyan küldő esetén, amelyhez nincs díj beállítva az alapértelmezett díjnak megfelelő ePointok beváltása szükséges. Az üzenet megmutatásakor a felhasználó számára jelezni kell, ha a beállított díjnál többet küldött a feladó. \subsection{Az alapértelmezett díj beállítása} Ez az érték szabályozza, hogy egy adott kulcsazonosítójú SecMS felhasználó mennyi ePoint csatolását követeli meg egy levél elolvasásához. Ez az alapértelmezett díj a SecMS szerveren bárki számára lekérdezhető, az adott felhasználó számára pedig írható is. A SecMS rendszer üzemeltetője határozza meg és állítja be azt az alapértelmezett értéket, ami az újonnan létrehozott felhasználókra vonatkozik. \subsection{Kivételek kezelése} Amennyiben sokat levelezünk valakivel, kényelmesebb lehet az állandó ePoint küldés helyett beállítani, hogy tőle nem vagy csak kevesebb ePointot kérünk levelekért. Akkor is szükséges lehet ez, ha feliratkozunk pl. egy levelezőlistára, hiszen a SecMS-en belül az ilyen szolgáltatások nyújtói nyilván nem fognak még fizetni is azért, hogy azokat igénybe vegyük. Amikor a felhasználó beállít egy valaki másra vonatkozó kivételt a saját SecMS felületén, akkor ezt a partnerével az implementációnak egy külön speciális üzenetben kell közölnie. A kivételt közlő üzenet egyetlen fejlécet tartalmaz: \texttt{EPoint-Required-Payment: \textit{v, YYYY-MM-DD HH:MM:SS}} A lejárati dátummal az implementációnak óvatosan kell bánnia. A jövőben távol lévő dátumot csak olyan környezetek állítsanak be, ahol garantálható, hogy az üzenet elküldéséről nem feledkeznek el. Pl. elveszthető mobiltelefon esetén, ha a felhasználónak van mentése a SecMS titkos kulcsából, de a leveleiből, illetve a beállításokból már nincs, akkor az új telefon megvásárlása és beállítása után a korábban engedélyezett baráti körétől a leveleket nem fogja megkapni, ha túl hosszú lejárati időt állít be. Hiszen azok a telefonok továbbra is csökkentett ePoint értékkel (vagy $v=0$ esetén ePoint nélkül) fogják küldeni a SecMS üzeneteiket, ami az új telefonon már kéretlen levélnek számít. Éppen ezért kötelező az implementációnak titkos kulcs mentésből való visszaállítása után a szerveren a küldött leveleket végig néznie, ilyen speciális kivétel közlő üzeneteket keresve és azokat feldolgozni. A lejárati dátum egy ``biztonsági öv'' arra az esetre, amikor ez az eljárás valamilyen hiba miatt nem talál meg beállításokat. \chapter{Az ePoint egyéb felhasználási területei} Az itt leírt problémák megoldása nem csak azért fontos, mert önmagukban is érdekesek és megoldatlanságuk jelentős hátránnyal jár napjainkban, hanem azért is, mert mindegyik égető annyira, hogy ePoint alapú megoldásukkal az ePoint elterjedése segíthető. \section{Telekommunikációs szolgáltatások} Számos IP alapú új kommunikációs megoldás versenyzik. Ezek többnyire jóval fejlettebbek, mint a hagyományos vonalas-, illetve mobiltelefonok. Például többségükben megoldott a videótelefonálás, szöveges üzenetek gyors váltása. Ezek használata a rendszeren belül jellemzően díjmentes, mivel ilyen felhasználáskor az amúgy már kifizetett internetszolgáltatáson kívül alig használnak más erőforrást. Ilyen telefonszolgáltatás pl. a Skype. Ugyanakkor természetes igény, hogy ezekből a rendszerekből is el kívánunk érni hagyományos telefonszámokat. Ez nem valósulhat meg díjfizetés nélkül, hiszen a felhasznált csatornák (frekvenciák, telefonállomások) fenntartása és létesítése költségekkel jár. Ezek a költségek nagyon aprók, nem mérhetőek egy bankkártyás fizetés vagy átutalás költségeihez. Ezért jelenleg csak úgy érhetőek el a modern IP alapú megoldásokból a régi hálózatok, ha a felhasználók jelentős mértékű (több száz órányi beszélgetésre elegendő) befizetést eszközölnek egyszerre. Ezzel elkötelezik magukat hosszú távra egy szolgáltató mellett. Az ePointtal az ilyen szolgáltatások úgy biztosíthatóak, hogy csak a telefonálás pillanatában kell kifizetni a díját. Ezzel a szereplők közti verseny jelentősen nőhet és az IP alapú megoldások piaca jelentősen kiszélesedhet, hiszen olyan felhasználók is kipróbálhatják, akiknek eddig nem volt bizalmuk a több száz órás költség előre utalásához. Ugyanez a probléma tapasztalható az internetet lokálisan (egy-egy háztömbben vagy utcában), nagyon olcsón szolgáltatni tudó, jellemzően vezeték nélküli megoldásokat alkalmazó kis szolgáltatók esetén. Őket az ePoint a számlázás jelentős adminisztrációs költségeitől is megszabadíthatja. \section{Tartalomszolgáltatás} Jelenleg az elektronikus tartalomszolgáltatás nagy részét reklámok bevételéből fedezik. Ez több szempontból is szuboptimális, jelentősen rontja a web használatának élményét, a reklámok általában technikailag a legszörnyűbb, a hordozó weblaptól elütő megoldásokat használnak. A tartalomszolgáltatóknak pedig jóval kisebb bevételt biztosítanak, mint amennyiért a tartalmat a piacon eladhatnák a felhasználóik számára. Ráadásul a felhasználók egy nem elhanyagolható (és egyre növekvő) része megpróbálja elkerülni a reklámokat. Különböző szoftverek segítik őket ebben, a reklámozók pedig válaszul ezen szoftverek hibáit keresik. Egyre sűrűbben jelenik meg olyan nyilvános felhívás is, ami azokat a programozókat tünteti fel rossz színben, akik ebben a versenyben kényszerűségből (és/vagy megbízásra) részt vesznek. Természetes folyamat ez, hiszen az internet egy interaktív médium. Minden résztvevő definíció szerint saját maga döntheti el, hogy melyik tartalomra és annak melyik részére kíváncsi és melyikre nem. Hasonlóan ahhoz, ahogy egy újságban a reklám átlapozható. Éppen ezért a nívós folyóiratok előállítása reklámbevételekből nem fedezhető, azokért az olvasóknak fizetnie kell. Az ePoint által szolgáltatott mikrofizetésekkel könnyen kidolgozható a webhez egy olyan kiterjesztés, amivel a fizetést igénylő weblapok biztonságosan és egyszerűen megvalósíthatóak és használhatóak lesznek. \section{Adományok, támogatások kezelése} Sok interneten elérhető szolgáltatásért jelenleg nem kötelező (sőt sok esetben nem is lehetséges) fizetni. Ilyenek például a levelezőlistákon és más fórumokon elérhető segítségek, a szabadszoftverekkel kapcsolatos egy felhasználóra jutó fejlesztések. Általában a szolgáltatás nyújtója reklámmal nem kívánja rondítani a terméket, így (néha elég sikeresen) az adományokra hagyatkozik. Mivel ezeknek a mértéke kicsi, ezek célba juttatásában is jelentős szerepe lehet az ePointnak. \part{Elért eredmények} Diplomamunkámban \begin{itemize} \item áttekintettem ismert üzenetküldő- és fizetőrendszerek biztonsági megoldásait; \item ismertettem az ehhez szükséges kriptográfiai hátteret; \item részletesen bemutattam mindkét problémára egy-egy újszerű, a kutatócsoportunkban kidolgozott megoldást, \item amelyek integrálásával megoldási javaslatot adtam a levélszemét problémájának újszerű, gazdasági alapokon nyugvó megoldására; \item végül vázlatosan felsoroltam három érdekes probléma ePoint alapú megoldását. \end{itemize} \cleardoublepage \pagestyle{empty} \phantomsection \addcontentsline{toc}{part}{Köszönetnyilvánítás} \hbox{} \vspace{3cm} \begin{center} {\Huge Köszönetnyilvánítás} \end{center} \vspace{1cm} Köszönetet mondok témavezetőmnek, Nagy Dánielnek, aki bármikor rendelkezésemre állt a diplomamunka készítése során, bizalommal fordulhattam hozzá kérdésekkel. Köszönettel tartozom még Sziklai Péternek, az ELTECrypt kutatócsoport vezetőjének, Bárász Mihálynak és Ligeti Péternek, a kutatócsoport két kutatójának. Rengeteget segítettek ők technikai és adminisztrációs problémák megoldásában, illetve az általuk tartott szemináriumok jelentősen szélesítették látókörömet a témában. \cleardoublepage \phantomsection \addcontentsline{toc}{part}{Irodalomjegyzék} \bibliographystyle{huplain} \bibliography{secms-pay} \end{document} %;;; Local Variables: *** %;;; latex-compile-func: compile *** %;;; TeX-output-extension: "pdf" *** %;;; End: ***