% -*- coding: iso-8859-2 -*- \documentclass[12pt, a4paper, titlepage, pdftex, oneside]{book} \usepackage[latin2]{inputenc} \usepackage[pdftex]{graphicx, color} \usepackage{pdfdraftcopy} \draftstring{ELTECRYPT} \usepackage{lmodern} \usepackage{fancyhdr} \usepackage[magyar]{babel} \usepackage[T1]{fontenc} \usepackage[colorlinks=true, backref=section, unicode, pdftex, linkcolor=blue, citecolor=blue, urlcolor=blue, breaklinks=true, pdfstartview=FitV, bookmarksnumbered=true, bookmarksopen=true]{hyperref} \title{SecMS üzenetküldő kliensprogram \\ \vspace{1cm} Szakdolgozat} \author{Készítette: Riskó Gergely\\Programtervező matematikus szak, nappali tagozat \\ \ \\ Témavezető: Nagy Dániel, ELTECRYPT kutatócsoport} \date{\vspace{10cm}Eötvös Loránd Tudományegyetem, Informatikai Kar, 2007.} \frenchspacing \pagestyle{fancy} \rhead{} \lhead{} \newcommand{\screenshot}[3]{% \begin{figure}[htp] \centering \includegraphics[#1]{#2} \caption{#3} \end{figure} } \begin{document} \maketitle \phantomsection \setcounter{page}{3} \addcontentsline{toc}{chapter}{Tartalomjegyzék} \tableofcontents \chapter{A SecMS bemutatása} A SecMS használatával lehetőség nyílik, mint annyi más informatikai rendszerrel, üzenetek váltására. A lényegi különbség az eddig elkészített üzenetküldő rendszerek és a SecMS között, hogy a SecMS esetében az ELTECRYPT kutatócsoport előre meghatározta a --- feltételezett felhasználási területnek megfelelő --- biztonsági követelményeket, amiket a rendszer algoritmusainak kidolgozása során kriptográfiai eszközök felhasználásával el is ért. A szakdolgozat a már kidolgozott matematikai algoritmus ``feldolgozásáról'' és megvalósításáról szól. Azért van szó feldolgozásról is, mert a cikk, amiből a szakdolgozat építkezik --- mint semmilyen ilyen jellegű cikk --- nem tárgyalta a számítástechnikai megvalósítás részleteit, meglévő (és felhasználható) megoldások ajánlását, értékelését. Ebben a fejezetben ismertetésre kerül a rendszer felépítése és az általa biztosított funkcionalitás, a biztonsági követelmények és az azokat megvalósító kriptográfiai eljárások. Ez utóbbi rész megértése nem feltétlenül szükséges a program használatához, ugyanakkor a felhasználó olyan ismereteket szerezhet, ha feldolgozza, amelyek segítenek abban, hogy miközben a \hbox{SecMS-t} használja, biztonságban érezze magát és a saját biztonságáról gondoskodni tudjon. Ezért nem lett volna helyes ezt teljes egészében a fejlesztői dokumentációt tartalmazó fejezetben leírni. Természetesen az algoritmusok megértése a programkód megértéséhez és módosításához elengedhetetlen. A fejezet zárásaként összehasonlítjuk a SecMS funkcióit és biztonsági követelményeit más --- elterjedt --- üzenetküldő megoldásokéval. \section{Komponensek} A levelek feladásához és fogadásához szükség van a számítógépen futó programon túl egy központi számítógépre (szerverre) is, ami az üzeneteket tárolja. Mint később látni fogjuk, ebben a szerverben (más rendszerektől eltérő módon) nem kell nagyon erősen bíznunk, az ő csalási lehetőségei nem igazán fenyegetőek. A demonstrációk kedvéért a kutatócsoport egy referencia szerverimplementációt is csinált, de a jövőben a SecMS elterjedése esetén harmadik fél által készített szerver és kliens implementációk megjelenése is várható, ezek kompatibilitását a közös hálózati protokoll biztosítja. Természetesen szükséges, hogy a kliensszámítógép és a szerverszámítógép között legyen hálózati kapcsolat. A szerver használatához a kliensnek el kell tudnia érni a szerver TCP portját (alapértelmezés szerint: 8080). A kliens és a szerver közötti minden párbeszéd a hálózat szempontjából HTTP (web) forgalomnak tűnik, ilyen módon van csomagolva. Ez pazarlásnak tűnhet, azonban így az elérhető hálózati kapcsolatok köre (a proxyszámítógépeknek köszönhetően) sokkal nagyobb. A kliens nem csak számítógép lehet, hanem pl. programozható mobiltelefon is. Az ELTECRYPT kutatócsoport későbbi munkájának fontos eleme is lesz, hogy ezzel a rendszerrel számítógép és mobiltelefon felhasználók problémamentesen és platformfüggetlenül kommunikálhatnak. A szakdolgozatomban megvalósított kliens implementációjakor ügyeltem arra, hogy az elkészülő program egyaránt futtatható legyen Java alkalmazásként és böngészőbe ágyazódó Java Appletként is. Az utóbbi lehetőség felhasználásával olyan felhasználók is tudják használni a rendszert, akik programok telepítésével nem kívánnak foglalkozni vagy arra nem jogosultak; a Java Appletet bárki elérheti egy korszerű böngészővel. \section{Funkciók a jelenlegi változatban} \subsection{A szerver nyilvános kulcsának letöltése} A program a bejelentkezés vagy regisztráció elején --- tehát a rendszer minden egyes indításakor --- automatikusan letölti és feldolgozza a szerver nyilvános kulcsát, ami szükséges a további kommunikációhoz. \subsection{Regisztráció} Amennyiben új felhasználó kívánja igénybe venni a SecMS rendszer szolgáltatásait, szüksége van egy (bizonyos szabályoknak megfelelő) titkos--nyilvános kulcspárra. A regisztráció folyamata ezen kulcspár nyilvános részének feltöltése a szerverre, amelynek során egy tetszőleges ún. megjelenítési név is megadható, hogy mások könnyebben összeköthessék ezt a kulcsot a tulajdonos személyével. A kulcspárt az ismertetett SecMS kliens egy a felhasználó által adott felhasználónév--jelszó párból állítja elő. Az előállítás algoritmusa determinisztikus és dokumentált, tehát ugyanaz a név és jelszó hordozható különböző számítógépek, illetve implementációk között. Cserébe a felhasználónév és jelszó illetéktelen kezekbe kerülése vagy elvesztése esetén nincs lehetőség azok megváltoztatására, hanem a kulcs visszavonása szükséges. További hátrány, hogy fel kell hívni a felhasználók figyelmét (és a felhasználók tudomásul kell, hogy vegyék), hogy más rendszerektől eltérően, már a regisztráció pillanatában kellően erős jelszót kell választaniuk, mert annak későbbi megváltoztatása nem lehetséges, más kulcs használatára való áttérés pedig legalábbis nehézkes. A nyilvános kulcsból a jelenleg elérhető számítási kapacitásokkal nincs lehetőség a titkos kulcs előállítására, illetve mindkét kulcs ismerete sem elegendő a kiindulási felhasználónév és jelszó meghatározásához. Ezért a rendszerben azonos felhasználónevű felhasználók előfordulhatnak, azonban az, hogy vannak-e ilyenek sosem válik ismertté (a rendszer üzemeltetője számára sem): a felhasználókat a kulcsuk nyilvános része, illetve annak lenyomata és a saját maguk által megadott megjelenítési név azonosítja. Természetesen a szerver sem tudja eldönteni, hogy egy kliens nyilvános kulcsát felhasználónév--jelszó párból (és ha igen, milyenből) generálták-e vagy valamilyen más algoritmussal jött létre. Ezért teljesen legitim a SecMS rendszer egy későbbi, pl. mobiltelefonokon használt kliensprogramjában a kulcsot máshogy létrehozni (mondjuk a felhasználó által generált véletlen események alapján) és tárolni (pl. PIN kóddal védve). Azonban a fokozott biztonságnak (nevezetesen annak, hogy a kulcs a telefonból nem távolítható el) ára van: a felhasználó telefoncsere során vagy nem tudja megtartani a kulcsát vagy külön eljárásokra, esetleg szakember segítségére szorul. Ha a szerveren már regisztrálva van a felhasználó, akkor a kliens hibaüzenetet jelenít meg. \subsection{Bejelentkezés} A ``bejelentkezés'' funkció lényegében nem lenne szükséges a SecMS-ben, mivel a megfelelő kulcs használatával a szerverrel való kommunikáció azonnal elkezdhető. Azért vezettük be mégis ezt a fogalmat, hogy az esetlegesen megadott rossz felhasználónév--jelszó pár ne gyűrűzzön tovább és ne akkor okozzon hibaüzenetet, amikor a felhasználó már megírt pl. egy 5 oldalas levelet. Továbbá a Java Appletként megjelenített webfelületen elérhető kliensprogram így egy szokásos üzenetküldő rendszer benyomását kelti, ezek mind a bejelentkezőképernyőn figyelmeztetnek hibás felhasználónév--jelszó pár megadása esetén. Az érdekesség kedvéért jegyzem meg, hogy nem lenne szokatlan az informatika világában, ha a hálózattal (és tranzakciókkal) való takarékoskodás végett ezt a kényelmet nem nyújtanánk a felhasználónak, pl. a Magyarországon is elterjedt bankautomaták szinte mindegyike a megadott PIN kódot csak az első tranzakció feldolgozása közben ellenőrzi, a felhasználó csak jóval a PIN kód megadása után (pl. amikor már kétszer megadta a feltöltendő mobiltelefon számát és a feltöltés összegét vagy begépelte a felveendő készpénz összegét) tudja meg, hogy a párbeszéd legelején megadott kód hibás volt. A mi esetünkben és a rendszer készítésekor már nem volt indokolt az ilyen mértékű takarékoskodás, így tehát a kliensprogram minden belépéskor ellenőrízteti a szerverrel a kulcsot és a regisztráció ellentéteként pont akkor ad hibaüzenetet, ha a kulcs nem létezik a szerver adatbázisában. \subsection{Üzenetek listázása és olvasása} A kliensprogram belépéskor letölti a szerverről az összes, a postafiókjában lévő üzenetet és ezeket a felhasználónak listában megjeleníti, amely listában a feladóra vagy a dátumra kattintva láthatóvá válik a megfejtett üzenet. Az üzenetre erről a képernyőről válaszolni is lehet. A program az üzenetek listáját csak kérésre (vagy újra belépés esetén) bővíti a szerverre újonnan érkezettekkel. \subsection{Új üzenet írása} Tetszőleges felhasználónak, akitől már kaptunk üzenetet vagy akinek tudjuk a kulcsazonosítóját, írhatunk új levelet. \subsection{Nyomkövetés --- kulcsok kezelése} A rendszer könnyebb demonstrációjáért és a nyomkövetés egyszerűsítésére a program egy menüpontjában lehetőség van az összes kezelt partnerkulcs listázására, illetve új kulcsok letöltésére, a nyilvános kulcslenyomatuk alapján. \section{Funkciók a jövőben} Számos funkció nem --- sőt pár alapfunkció sem --- került megvalósításra ebben a demonstrációs verzióban. Ezeket áttekintjük, hogy egyértelmű legyen, hogy ezek megvalósítása nem ütközik a SecMS működési elveivel, csupán időráfordítás kérdése a kidolgozásuk. \subsection{Üzenetek továbbítása} Szokásos funkció az üzenőrendszerekben, hogy lehetőség van levelek továbbítására, a jelenlegi kliensverzióban erre nincs külön felhasználói felület, a funkció a válaszadás gombbal, majd a címzett megváltoztatásával helyettesíthető. A továbbítás funkció implementációja a későbbi verziókban azért is fontos, mert amikor már lehetőség lesz olyan üzenet küldésére, ami a hitelességet és integritást (digitális aláírással) harmadik fél számára is bizonyítja, akkor a kliens programnak ügyelnie kell arra, hogy a továbbítás után az aláírás ellenőrízhető maradjon. \subsection{Üzenetküldés több címzett számára} Az ELTECRYPT kutatócsoport kidolgozott egy külön üzenettípust arra az esetre, ha ugyanazt az üzenetet (pl. meghívó egy megbeszélésre) több, mint egy címzettnek kívánjuk egyszerre elküldeni. Ez az új üzenettípus hatékonyabb, mintha az összes címzettet külön-külön üzenettel értesítjük, kevesebb sávszélességre van szükség. \subsection{Üzenetek osztályozása} A következő verziókban lehetőség lesz a szerveren tárolt üzeneteink osztályozására is; az, hogy ez milyen biztonsági követelmények mellett valósítható meg (pl. ha a szerver sem látja a tulajdonságokat, akkor nem biztos, hogy tud indexelni) még kidolgozás alatt áll. \subsection{Üzenetek törlése} Amikor az üzenetek osztályozása funkció elkészül, természetesen egyik osztály lehet a törölt üzenetek osztálya, amiből való törlés után az adott felhasználó már valóban nem tudja majd elérni a szóban forgó üzenetet. Ha mind a címzett(ek), mind a feladó kitöröl egy levelet véglegesen, a rejtjelezett üzenet a szerverről is törölhető lesz. \subsection{Küldött üzenetek tárolása} A küldött üzenetek osztályának (a felhasználó szempontjából: mappájának) létrehozása szintén az osztályozáshoz kötődik. \subsection{Kézbesítési, olvasási visszaigazolások kezelése} Tekintve, hogy a SecMS majd fontos szerepet fog játszani elektronikus fizetések lebonyolításában, kiemelkedő fontosságú, hogy az üzenetek átvétele, illetve elolvasása a feladó számára követhető és ellenőrízhető legyen. A későbbi verziókban többféle visszaigazolás kérésére is lesz lehetőség (ld. később a biztonsági követelményeknél). \subsection{Különböző szerverek használata} Mivel lehetőséget szeretnénk biztosítani sokféle SecMS szerver- és kliensprogram létrehozására, szükséges megoldani, hogy a különböző kiszolgáló-számítógépeken regisztrált felhasználók is küldhessenek üzeneteket egymásnak. Az az információ, hogy egy felhasználó melyik szervert használja a levelei fogadásához, megadható (és változtatható is) a nyilvános kulcsában (\cite[Section 5.2.3.16. Key server preferences]{openpgp}). \section{Biztonsági követelmények} Most ismertetjük azokat a célkitűzéseket és jelentésüket, amiket előre meghatároztunk a SecMS elkészítésekor. Ez a rész különösen fontos, hiszen ez adja a SecMS egyedi jellegét. \subsection{Integritás} Az üzenetek fogadásakor a címzett biztos lehet benne, hogy az üzenetet változatlan formában kapja meg. Erről saját maga meg tud győződni, harmadik félben nem szükséges megbíznia. Későbbi verziókban a feladó majd eldöntheti, hogy olyan üzenetet ad-e fel, ami azon túl, hogy a címzett számára garantálja az integritást, még lehetővé teszi, hogy a címzett ezt általa kiválasztott személyek számára be is bizonyítsa. A hétköznapi életben például ezzel az erővel bír egy postai átutalási megbízás a posta által lebélyegzett feladóvevénye, de nem bír ezzel az erővel egy internetes bankon adott átutalási megbízás kinyomtatott képe: hiszen azt a HTML kódot lementve és átírva tetszőleges megbízás nyomtatható. Jelenleg a lakossági körben nincs olyan szélesen elterjedt banki szolgáltatás, amivel megnyugtatóan igazolhatnák magánemberek az interneten feladott megbízásaikat (pl. lakástulajdonosnak a bérlője valamely közüzemi átutalást). \subsection{Hitelesség} A címzett biztos lehet a feladóban. Természetesen, mint mindegyik másik biztonsági követelmény, ez is csak megfelelő felhasználás esetén érvényes, a felhasználónak tisztában kell lennie a szükséges lépésekkel, azonban más üzenőrendszerekkel ellentétben, megfelelő jártassággal az üzenet hitelességét saját maga ellenőrízni tudja. \subsection{Konfidencialitás} A SecMS a rábízott leveleket a feladó számítógépén rejtjelezi és csak a címzett számítógépén fejti meg. A felhasznált rejtjelezés kizárja, hogy az üzenetet bárki más elolvashassa (pl. a szerver üzemeltetője, vagy az internetszolgáltató). Azon túl, hogy az üzeneteket csak a címzett és a feladó tudja megfejteni, a szerverrel való kommunikáció is rejtjelezve zajlik, így más műveletek (elküldött levelek újraolvasása, kulcsletöltés, visszaigazolások) is rejtve maradnak a passzív lehallgatással próbálkozó támadó elől. \subsection{A visszaigazolások megbízhatósága} A SecMS későbbi verzióiban lehetőség lesz különböző visszaigazolások kérésére. Ez különösen fontos, mivel pénzforgalmi megbízások kezelésére is fel szeretnénk majd használni. A megvalósítandó visszaigazolástípusok: \begin{itemize} \item átvételkor: a szerver igazolja, hogy feladtunk egy bizonyos ellenőrzőösszeggel rendelkező levelet egy megadott címzett számára. Az üzenet felfedésével és a kapott hitelesített (ellenőrzőösszeg, feladó, címzett, dátum) négyes bemutatásával bizonyíthatjuk később a feladás tényén túl a feladott üzenet pontos tartalmát is. \item letöltéskor: lehetőség lesz arra, hogyha kértünk letöltéskori visszaigazolást, akkor a címzettnek ezt kötelező legyen elküldeni, a saját kulcsával hitelesítve (digitálisan aláírva), a szerver nem fogja engedni, hogy más műveletet végezzen (a levél ismételt letöltésén kívül), amíg a visszaigazolásról nem gondoskodott. \item olvasás után: ez a típus csupán informatív (hiszen a számítógép nem tudja ellenőrízni, hogy valamit valóban elolvastunk és megértettünk-e); a jelenlegi verzióban is elérhető pl. úgy, hogy ha tudatni akarjuk, hogy egy üzenetet megértettünk, akkor válaszolunk rá. Az automatizáció csak azt teszi majd lehetővé, hogy ezek az információk a visszaigazolást kérő személynél szebben jelenjenek meg, a visszaigazolást adó személy pedig könnyebben előállíthassa. \end{itemize} \section{Kriptográfiai elemek} Az ismertetésre kerülő kriptográfiai elemek közül a folyamtitkosító és a hashfüggvény konkrét megvalósítása kis programozói munkával másra kicserélhető mind a kliens-, mind a szerverprogramban. A Diffie-Hellman kulcsmegegyezés is helyettesíthető más primitívvel, azonban ez a felhasználóknál a szoftver frissítésén túl a DSA kulcsaik cseréjét is igényelheti, ami nagy számú felhasználónál már szinte megvalósíthatatlan. \subsection{A Diffie-Hellman kulcsmegegyezés} Az egész rendszerre vonatkozóan adott\footnote{Az adott értékeket és generálásuk módját a protokoll dokumentáció tartalmazza.} egy Schnorr csoport rendje (160 bites prím: $q$), az 1024 bites $p$ prím és az ezek alapján számolt $g$ generátor elem, melyek megfelelnek a \cite{fips186} szabványban leírt kritériumoknak. A SecMS minden felhasználója rendelkezik egy 160 bites $0>}{Talker(String \texttt{serverHost}, int \texttt{serverPort}, BuildContext \texttt{bc}, ParseContext \texttt{pc})} Egy-egy megfelelően inicializált \texttt{BuildContext} és \texttt{ParseContext} példányt használva kommunikál a \texttt{serverHost} és \texttt{serverPort} által meghatározott szerverrel. Szinkron üzenetváltást támogat, mindig megvárja a szerver által adott rejtjelezett választ, amit meg is fejt az adott \texttt{ParseContext} segítségével. A rejtjelezendő és elküldendő üzenetfát vagy amennyiben csak alcsomagokat (ld. SecMS protokoll leírás\cite{secms}) küldünk, annak gyökerét két különböző túlterhelt \texttt{syncMessage} nevű metódus dolgozza fel: \function{public}{Packet}{syncMessage(Packet \texttt{request})} \function{public}{SubpacketContainerPacket\hfil}{\break \hbox{\hspace{3cm} syncMessage(SubpacketContainerPacket \texttt{spRequest})}} \subsection{Nézet (View)} \subsubsection{mik.client.view.ClientPanel} A főablakban mindig egy panel jelenik meg, amin valamilyen műveletet elvégezhet a felhasználó. Minden ilyen panelnek közös őse a \texttt{ClientPanel} osztály, ami leszármazottja a Swing által szolgáltatott \texttt{JPanel} megjeleníthető panelnek. Mivel magát a ClientPanelt muszáj kibővíteni, hogy valódi viselkedése lehessen, absztrakt, így nem példányosítható. \function{protected}{<>}{ClientPanel(final View \texttt{parent})} A konstruktor a kapott View referencián keresztül protected változókba elhelyezi a \texttt{view}, \texttt{i18n}, \texttt{model} referenciákat, amiket így a leszármazott osztályok egyszerűen elérhetnek. \function{public}{boolean}{beforeDestroy()} Átdefiniálásával a leszármazott elérheti, hogy valamilyen műveletsort végre hajthasson, mielőtt egy másik panelre cserélné a program. A metódus visszatérési értéke jelzi, hogy hozzájárulását adja-e a panel a lecseréléshez. Ezt a lehetőséget jelenleg akkor használjuk, amikor a felhasználó egy félkész levél írása közben másik panelre kíván váltani vagy ki szeretne lépni a programból, ekkor figyelmeztetjük és amennyiben a mégse gombot választja, akkor hamis értékkel térünk vissza, megszakítva így a levél elvesztéséhez vezető folyamatot. \function{public abstract}{void}{afterVisible()} Átdefiniálása kötelező, az a műveletsor, ami a panel teljes megjelenítése után végzendő, pl. valamelyik komponenshez a fókusz hozzárendelése. \subsubsection{mik.client.view.KeyPanel} A nyomkövetés menü alatt található, a tárolt kulcsok részleteit megmutató panel. Mivel lehetőséget biztosít új kulcsok letöltésére is (a vezérlő GetKeyAction osztályával), megváltozhat a tárolt kulcsok listája, ezért implementálja az \texttt{Observer} interfészt, amin keresztül értesül a modell változásáról és ekkor újra feltölti a táblázat adatait. A sorok megjelenítését a \texttt{KeyTableCellRenderer} végzi. \subsubsection{mik.client.view.KeyTableCellRenderer} A kulcsokat felsoroló, illetve az érkezett üzeneteket felsoroló táblázat azon sorát, ami a saját kulcsunk zölddel, míg a szerver kulcsát pirossal volt kívánatos kiemelni, ezért egy külön \texttt{KeyTableCellRenderer} osztályt is létrehoztam, ami biztosítja ezt, újrafelhasználva a megjelenítés lényegi részét elvégző \texttt{DefaultTableCellRenderer} Java Swing osztályt. \subsubsection{mik.client.view.LoginPanel} A SecMS bejelentkező-képernyőjét és a nyelvválasztást megvalósító panel. A lényegi funkcionalitást, a bejelentkezési adatok ellenőrzését, illetve a regisztrációt a vezérlő csomag \texttt{RegisterAction} és \texttt{LoginAction} osztályai végzik. A konstruktor egyetlen bonyolult része a vezérlők billentyűzettel való navigálási sorrendjét beállító rész. A \texttt{ContainerOrderFocusTraversalPolicy} osztály egy olyan névtelen alosztályát kell itt létrehozni, ami felüldefiniálva a \texttt{getComponentAfter} és \texttt{getComponentBefore} metódusokat leírja a megfelelő, hagyományostól (nevezetesen a balról jobbra olvasás szabályaitól) eltérő, de a konkrét ablakban logikusabb és gyorsabb navigálási sorrendet. A \texttt{getComponentBefore} a \texttt{getComponentAfter} segítségével egy elhanyagolható futási idejű lineáris kereséssel megkapható, így a kívánt sorrendet csak egyszer és egyirányba kell átgondolni és leprogramozni. A megvalósított sorrenddel támasztott követelmények a következők: \begin{itemize} \item A nyelvválasztás ritkán használt funkció, a navigálásból kihagyható, elegendő, hogy van gyorsbillentyűje. \item Mivel jóval többször jelentkeznek be a felhasználók, mint regisztrálnak, az első négy komponens a következő legyen: gépnév, portszám, felhasználói név, jelszó, majd a bejelentkezés gomb következzen és csak utána a regisztráció. \item Azonban ha a regisztrációt aktivizálták, boruljon fel ez a sorrend, ekkor már a gépnévre és portszámra nem kell, hogy sor kerüljön, a felhasználói név után a megjelenített név következzen és így a jelszó kétszer egymásután adható meg, ahogy az mindenhol megszokott, majd ugorjunk a regisztráció gombra, a regisztráció megszakítása lehet a legutoljára elért funkció. \end{itemize} A követelmények alapján az elágazásrendszer már könnyen megérthető. \subsubsection{mik.client.view.MessageListPanel} A modellben aktuálisan tárolt leveleket megjelenítő panel, lehetőséget ad a modell új, most érkezett levelekkel való feltöltésére is, ezért megvalósítja az \texttt{Observer} interfészt, hogy értesülhessen a változásokról. A táblázat feladó oszlopának megjelenítését a \texttt{KeyTableCellRenderer} végzi. A levelek frissítését, illetve a válasz kezdeményezését a vezérlő csomag \texttt{RefreshAction} és \texttt{ReplyAction} osztályai biztosítják. \subsubsection{mik.client.view.MessageNewPanel} Ezzel a panellel lehet új üzenetet írni, mivel a címzett megadásakor lehetőség van még nem tárolt, új kulcs letöltésére is, változtathatja a modellt és ezért megvalósítja az \texttt{Observer} interfészt, hogy értesülve a modell változásáról újra feltölthesse a címzett-választódobozt. A címzett-választódobozban a saját kulcs zöldre színezésének megvalósítása a \texttt{KeyTableCellRenderer} osztályhoz nagyon hasonló, azonban itt listáról és nem táblázatról van szó, ezért a \texttt{DefaultListCellRenderer} osztály \texttt{getListCellRendererComponent} metódusának átdefiniálására volt szükség. \function{public final}{boolean}{beforeDestroy()} Ezt a metódust hívja meg a vezérlő, mielőtt az üzenetküldő-panel másikra cserélődne vagy a program végetérne, így átdefiniálásával elérem, hogy ha az üzenet egy részét a felhasználó már megírta, akkor figyelmeztető ablak jelenjen meg, ahol a mégsét választva még megszakítható a művelet. Ezt a vezérlőnek visszaadott hamis érték mutatja. \subsubsection{mik.client.view.View} A \texttt{View} osztály az alkalmazás/applet főosztálya, abban az értelemben, hogy a végrehajtás mindig ennek az osztálynak valamelyik metódusával kezdődik. Alkalmazás esetében a statikus \texttt{main(String[] args)} metódussal, aminek a feladata csak az, hogy létrehoz egy főablakot és azt beállítja úgy, hogy rögtön a belsejében az ``applet induljon el''. Így érjük el, hogy ugyanaz a forráskód fut alkalmazásként és appletként is. Furcsa lehet, hogy egy az MVC tervminta szerint fejlesztett alkalmazás a nézet komponens végrehajtásával és nem a vezérlőével kezdődik, ennek oka az, hogy appletként futva a Java nyelv megkötése az, hogy az első indított osztály kell, hogy a grafikus felületet nyújtó \texttt{JApplet} leszármazott legyen. Ez a feladat viszont egyértelműen a megjelenítési réteghez tartozik. Szintén az appletek miatt a konstruktort itt az \texttt{init()} és \texttt{start()} metódusok helyettesítik, ezeket hívja meg a \texttt{main} is és ezek végzik a felhasználói felület felépítését, a vezérlő és a modell inicializációját. \function{<>}{void}{toggleLanguage()} Ez a metódus valósítja meg a nyelvváltást angol és magyar között, a \texttt{LoginPanel} gombja egyszerűen csak ezt hívja. \subsubsection{mik.client.view.i18n} Ez az alosztály tartalmazza az egyes nyelvekhez tartozó \texttt{ResourceBundle} leszármazottakat \texttt{Messages\_xx} névvel, ahol \texttt{xx} a nyelv kódja, pl. a magyar osztály neve \texttt{Messages\_hu}. Ezeknek az osztályoknak rögtön a bináris bájtkód alakját generálja a gettext megfelelő segédprogramja, ezt korábban tárgyaltuk. Egyedül az angol nyelvhez kellett egy kis segédosztályt írni, mivel maga a programkód angolul készült el és csúnya megoldás lett volna készíteni egy olyan ``fordítást'', ami angolról angolra fordít. Ez a segédosztály (\texttt{Messages\_en}) a lehető legszükségesebb metódusait implementálja csak (a ResourceBundle ősben absztraktakat) a lehető legtriviálisabban (mindig \texttt{null}, illetve \texttt{false} értéket visszaadva), mivel így a felhasználó gettext csomagba tartozó metódus az eredeti angol szöveget adja vissza. \subsubsection{mik.client.view.uic} Az alosztály igyekszik kijavítani pár hibát és pótolni egy-két hiányosságot a Swing programozói felületében és a létrejövő felhasználói felületek működésében. \subsubsection{mik.client.view.uic.KeyTextField} Olyan beviteli mező (TextField leszármazott), ami csak hexadecimális számjegyek bevitelét engedélyezi, a \texttt{createDefaultModel()} metódust átdefiniálja, olyan dokumentummodellt hozva létre, ami csak az említett karakterek beillesztését engedélyezi. \subsubsection{mik.client.view.uic.Mnemonic} Az osztály statikus metódusaival egyszerűbben lehet beállítani gyorsbillentyűvel rendelkező gombok szövegét, ugyanis a szöveg részeként (a megfelelő betű előtt) csak jelezni kell egy \& jellel, hogy melyik gomb legyen a gyorsbillentyű. Ennek különösen akkor van jelentősége, amikor a gombot több nyelvre is lefordítják, ugyanis ekkor a fordítás részeként (programozói tudás nélkül) kiosztásra kerülhetnek az adott nyelvhez tartozó gyorsbillentyűk. \function{public static}{void}{setText(AbstractButton \texttt{b}, String \texttt{text})} A \texttt{b} gomb feliratát \texttt{text}-re állítja, ha a szövegben található gyorsbillentyű, akkor azt beállítja. \function{public static}{JButton}{newMnemonicButton(String \texttt{text})} Létrehoz egy új nyomógombot, amelynek feliratát a gyorsbillentyűkkel együtt inicializálja. \function{public static}{JButton}{newMnemonicButton(String \texttt{text}, Action \texttt{act})} Az előző függvényen hatásán túl még a gombot az \texttt{act}-hoz rendeli. \function{public static}{JMenu}{newMnemonicMenu(String \texttt{text})} Létrehoz egy új menüt, amelynek feliratát a gyorsbillentyűkkel együtt inicializálja. \function{public static}{JMenuItem}{newMnemonicMenuItem(String \texttt{text})} Létrehoz egy új menüelemet, amelynek feliratát a gyorsbillentyűkkel\break együtt inicializálja. \subsubsection{mik.client.view.uic.NumberField} Olyan beviteli mező (TextField leszármazott), ami csak a konstruktorban megadott értékhatárokon belüli intervallum értékeket fogad el. Egy új fókuszfigyelő segítségével, amikor a mező aktivizálódik, megjegyzi az aktuális értéket, majd a fókusz elvesztésekor ezt visszaállítja, ha a bevitt új érték nem megfelelő. \function{public}{<>}{NumberField(int \texttt{number}, int \texttt{minVal}, int \texttt{maxVal})} Ez a konstruktor létrehoz egy intervallum-ellenőrzött beviteli mezőt, \break\texttt{number} kezdőértékkel és \texttt{minVal}-\texttt{maxVal} értékhatárokkal (inkluzíve). \subsubsection{mik.client.view.uic.PasswordField} Olyan jelszóbeviteli mező, ami ha a billentyűzet segítségével kap fókuszt (pl. gyorsbillentyű vagy a tab billentyűvel való ``lépegetés''), akkor kijelöli az egész jelszót, így ha navigálás nélkül kezd el a felhasználó gépelni, akkor a szokásos viselkedésnek megfelelően, ezzel teljesen felülírja a régi adatot. A megvalósítás részletei a \texttt{TextField} megvalósításával egyezők (ld. később). \subsubsection{mik.client.view.uic.Table} Olyan JTable leszármazott, ami a konstruktorában beállítja az általunk használt táblázatok kívánt kinézetét és viselkedését, nevezetesen az egysoros kijelölést, valamint azt, hogy a tab és shift+tab billentyűk hagyományos módon a fókuszváltást idézzék elő és ne a táblázaton belül navigáljanak. \subsubsection{mik.client.view.uic.TableSorter} Speciális (a Java on-line dokumentációjából másolt) táblamodell, ami lehetővé teszi, hogy a felhasználó a címsor oszlopelemeinek megkattintásával változtassa a sorok rendezettségét. Sajnos a nyelv készítőinek sem sikerült ezt a megoldást a lehető legkielégítőbben kidolgozni, pl. a kijelölt sor elveszik a rendezettség megváltoztatásakor. A korrekt megoldást a Java nyelv 1.6-os verziója már beépítve tartalmazza, azonban ez a szakdolgozatom írásakor még éppen csak megjelent, számos kliensgépen (és így sok SecMS felhasználó számára) nem érhető el. \subsubsection{mik.client.view.uic.TextField} Olyan szövegbeviteli mező, ami ha a billentyűzet segítségével kap fókuszt (pl. gyorsbillentyű vagy a tab billentyűvel való ``lépegetés''), akkor kijelöli az egész szöveget, így ha navigálás nélkül kezd el a felhasználó gépelni, akkor a szokásos viselkedésnek megfelelően, ezzel teljesen felülírja a régi adatot. Mindezt úgy érjük el, hogy a felülbírált konstruktorokban meghívunk egy \texttt{initListener()} nevű segédfüggvényt, ami engedélyezi az egér eseményeinek figyelését (és a figyelő beállít egy jelzőbitet, ha kattintás történik), illetve egy olyan fókuszkezelőt vezet be, ami aktivizálódáskor kijelöli az egész szöveget (ha nem jelez a jelzőbit korábbi kattintást). \subsubsection{mik.client.view.uic.TimeJLabel} A JLabel kiterjesztése, ami a \texttt{SetTextErr} és \texttt{SetTextOK} metódusaival lehetővé teszi hiba, illetve információs üzenetek megjelenítését egy adott adott időre, ami után a címke eredeti üzenete lesz ismét látható. Ehhez természetesen a \texttt{SetText} utasítást is felül kellett definiálni, de annak szignatúrája nyilván nem változott, ezért csak a felhasználás szempontjából érdekes, új metódusokat mutatjuk be: \function{public}{void}{setTextErr(String \texttt{errorMessage}, final int \texttt{timeout})} Piros színnel megjeleníti az \texttt{errorMessage} által megadott feliratot, de \texttt{timeout} ezredmásodperc elteltével újra az eredeti, legutolsó \texttt{setText(String text)} hívás által beállított értéket teszi láthatóvá. \function{public}{void}{setTextOK(String infoMessage, final int timeout)} Zöld színnel megjeleníti az \texttt{errorMessage} által megadott feliratot, de \texttt{timeout} ezredmásodperc elteltével újra az eredeti, legutolsó \texttt{setText(String text)} hívás által beállított értéket teszi láthatóvá. \section{Tesztelés} \subsection{Automatikus tesztelés} Minden komolyabb algoritmuson vagy adatszerkezeten alapuló programkódot szükséges automatikusan tesztelhetővé tenni, mert ha a tesztek elegendően sok esetet lefednek, akkor a kód hibás változtatásakor nagy valószínűséggel valamelyik teszt felhívja majd a hibára a figyelmünket, így a hibákra hamarabb és kisebb hatókörben fény derülhet. Ugyanakkor felhasználói interfészeket, illetve hálózati tevékenységet végző kódokat jóval nehezebb automatikusan tesztelni, ezért a SecMS esetében automatikus tesztelést a kriptográfiai algoritmusokat megvalósító Secms Commons csomagnál végzünk a JUnit\footnote{\url{http://junit.sourceforge.net/}} rendszer segítségével. \subsection{Kitűzött tesztfolyamat} A kliensprogramot (és ezáltal a szervert) egy előre meghatározott tesztfolyamattal ellenőrizzük minden fontosabb mérföldkő után. A szakdolgozatban megvalósított funkciókhoz illeszkedő tesztfolyamat, amit természetesen a szakdolgozat verziójának véglegesítése előtt végig is ellenőriztem, a következő ($\alpha, \beta$ két különböző elindított kliensprogramot jelöl, célszerű, hogy az egyik appletként, a másik alkalmazásként fusson): \def\itemA{\renewcommand{\labelitemi}{$\alpha)$}} \def\itemB{\renewcommand{\labelitemi}{$\beta)$}} \begin{itemize} \itemA \item Alice nevű felhasználó regisztrálása, majd az érkezett üzenetek panel kiválasztása, jelenleg üres az üzenet lista, \itemB \item azonos felhasználói névvel és jelszóval, azonos/különböző megjelenített névvel a regisztráció újbóli kísérlete hibát kell, hogy adjon, \item bejelentkezés a még nem regisztrált Bob felhasználóval hibát kell, hogy adjon, \item Bob regisztrálása, belépés után az új üzenet ablakban minnél többféle nem létező, illetve hibás szintaxisú kulcs letöltése hibát kell, hogy adjon, \item Alice kulcsának a letöltése, \item üres üzenet elküldése hibát kell, hogy adjon, \item nem üres üzenet esetén a panel elhagyása figyelmeztetést kell, hogy adjon, \item üzenet elküldése, majd egy másik üzenet küldése saját magunknak, \itemA \item Alice kliensprogramjában a frissítés gombra megjelenik az új üzenet, válaszadás tesztelése, \itemB \item Bob kliensprogramjában az érkezett üzenetek között kettő üzenet kell, hogy legyen, amiből a saját magunk által küldött zöld. Ellenőrizzük a táblázat rendezhetőségét, az elemek közti váltogatást! \item A nyomkövetés menü tárolt kulcsok menüpontjának hatására megjelenő panelben a nyilvános kulcsok, ujjlenyomatok másolhatók és a vágólapra helyezhetők, a szerver kulcsa piros. A saját (zöld) kulcsunk esetében a titkos kulcs is megjelenik. \item Jelentkezzünk ki, a szerver adatbázisából kézzel töröljük ki az Alice nevű felhasználót. \item Bobként újra bejelentkezve a üzenetek listájában Alice válasz üzenete már (Alice kulcsának) hiányában nem jeleníthető meg, de ennek ellenére kiválasztásakor, rendezéskor a program logikusan viselkedik. \end{itemize} \subsection{Felhasználók bevonásával} Amikor a SecMS első már demonstrálható kliensváltozata, illetve szervere elkészült, akkor egy szeminárium keretében az ELTECRYPT kutatócsoport tagjai számára tartottunk egy bemutatót, ami előtt a felhasználóknak a szoftver használatához kapcsolódó oktatást nem adtunk, a rendszernek csak a feladatát és kriptográfiai hátterét ismerték, a felhasználói felület használatát az intuíciójukra bíztuk. Az ekkor megfigyelt nehézségek, illetve elhangzott kérdések, panaszok sokat segítettek a felület egyértelműségének növelésében. Pl. a speciális kulcsok néven túl színnel való megkülönböztetése, a regisztrációs gomb pontos működése és a különböző kulcsadatok vágólapra való helyezésének lehetősége mind olyan ötletek, amik a szemináriumon születtek. \chapter{A CD melléklet tartalma} \begin{itemize} \item \texttt{secms-protocol.pdf}: a protokoll angol nyelvű leírása \item \texttt{client-src.zip}: a kliensprogram forrása tömörítve \item \texttt{server-src.zip}: a szerverprogram forrása tömörítve \item \texttt{common-src.zip}: a SecMS Commons forrása tömörítve \item \texttt{client/}: a kliensprogram futtatásra kész állapotban, kibontva \item \texttt{server/}: a szerverprogram futtatásra kész állapotban, kibontva \item \texttt{common/}: a SecMS Commons felhasználásra készen, kibontva \item \texttt{secms-cd.md5}: a CD-n lévő fájlok MD5 hibafelismerő kódjai \end{itemize} Az ellenőrizhetőség kedvéért a \texttt{client-src.zip}, \texttt{server-src.zip} és \texttt{common-src.zip} fájlok SHA1, illetve MD5 ellenőrzőösszegeit itt is megadom: \vspace{0.5cm} MD5: % md5sum *zip \begin{verbatim} e92988cf111e86bd489e436772b6ce4e client-src.zip bcf37582ecbe222f4c0557dc7826cefa common-src.zip 1a0a8533ba12841f12273f5d9ceea1e1 server-src.zip \end{verbatim} SHA1: % sha1sum *zip \begin{verbatim} 473b4c5a0987a8305eb600fc189d78642a81da08 client-src.zip 3de988573995f16078eb341fa8dbd82069830e0b common-src.zip 017bea9f5d3a89c46d985c97614cfaedc295f6b3 server-src.zip \end{verbatim} \cleardoublepage \phantomsection \addcontentsline{toc}{chapter}{Irodalomjegyzék} \begin{thebibliography}{WFLY RIPE} \bibitem[OpenPGP]{openpgp} {\bf OpenPGP Message Format}\\Jon Callas, Lutz Donnerhacke, Hal Finney, Rodney Thayer\\ \url{http://www.ietf.org/rfc/rfc2440.txt} \bibitem[FIPS 186-2]{fips186} {\bf Digital Signature Standard}\\ \url{http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf} \bibitem[DSA]{dsa} {\bf Digital Signature Algorithm a Wikipédiában}\\ \url{http://en.wikipedia.org/wiki/Digital\_Signature\_Algorithm} \bibitem[WYY SHA1]{sha1-63} {\bf Finding Collisions in the Full SHA-1}\\ Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu\\ \url{http://www.infosec.sdu.edu.cn/paper/sha1-crypto-auth-new-2-yao.pdf} \bibitem[WFLY RIPE]{ripe-coll} {\bf Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD}\\ Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu\\ \url{http://eprint.iacr.org/2004/199.pdf} \bibitem[FluManSha]{rc4-256} {\bf Weaknesses in the Key Scheduling Algorithm of RC4}\\ Selected Areas in Cryptography 2001, pp1-24\\ Scott R. Fluhrer, Itsik Mantin, Adi Shamir\\ \url{http://www.wisdom.weizmann.ac.il/~itsik/RC4/Papers/Rc4_ksa.ps} \bibitem[DDFriFuIm]{fi} {\bf Future Imperfect}\\ David D. Friedman\\ \url{http://patrifriedman.com/prose-others/fi/commented/Future_Imperfect.html} \bibitem[XMPP]{xmpp} {\bf Extensible Messaging and Presence Protocol}\\ Jabber Software Foundation\\ \url{http://www.ietf.org/rfc/rfc3920.txt}\\ \url{http://www.ietf.org/rfc/rfc3921.txt} \bibitem[XMPP E2E]{xmpp-e2e} {\bf End-to-end signing and object encryption for XMPP}\\ Jabber Software Foundation\\ \url{http://www.ietf.org/rfc/rfc3923.txt} \bibitem[TLSv1]{tls} {\bf The TLS Protocol}\\ T. Dierks, C. Allen\\ \url{http://www.ietf.org/rfc/rfc2246.txt} \bibitem[S/MIME]{smime} {\bf Secure/Multipurpose Internet Mail Extensions \\\hbox{(S/MIME) Version 3.1 Message Specification}}\\ Ramsdell, B., Ed.\\ \url{http://www.ietf.org/rfc/rfc3851.txt} \bibitem[OTR]{otr} {\bf Off-the-Record Messaging Protocol version 2}\\ Eric Brewer, Nikita Borisov, Ian Goldberg\\ \url{http://www.cypherpunks.ca/otr/Protocol-v2-3.0.0.html} \bibitem[SECMS]{secms} {\bf SecMS Protocol Description}\\ Péter Ligeti, Zsolt Balázs Németh, Gergely Riskó\\ \url{http://sourceforge.net/projects/secms} \end{thebibliography} \end{document}