Infrastru k tu r fo r M o b ile A p p lik atio ner. 1. ju n i 2 0 0 4

Infrastru k tu r fo r M o b ile A p p lik atio ner Kim B o n d e M o rte n F lin tru p 1. ju n i 2 0 0 4

Resumé Dette s pec iale bes kriver u d viklin g en af Protec ted Peer G rou ps (PPG ), en s oftwarein fras tru k- tu r d er u n d ers tø tter im plem en tation af kon teks tafh æ n g ig e applikation er på m obile apparater forbu n d et i ad h oc, d ec en trale n etvæ rk m ed u n d ers tø ttels e af d yn am is k g ru pped an n els e, m an g e typer bru g ere, ad g an g s kon trol og h em m elig h old els e af d ata. PPG g iver m u lig h ed for opbyg n in g af h ierakis ke g ru ppes tru ktu rer u d en beh ov for c en tral s tyrin g. S pec ialet bes kriver d es ig n et af en kom m u n ikation s protokol, s om bru g es til at kom m u n ikere på g ru ppen iveau og in d ivid u elt m ellem en kelte bru g ere. Den im plem en tered e prototype d em on s trerer bru g en af d e pres en tered e kon c epter og tillad er bru g ere at kreere g ru pper, ad m in is trere m ed lem s kab og d ele in form ation er m ed an d re bru g ere. Im plem en tation en er bas eret på S c ribe, s om er en alg oritm e d er d an n er g ru pper i et peerto -peer-n etvæ rk bas eret på alg oritm en Pas try. Ab s tr a c t T h is th es is work d es c ribes th e d evelopm en t of Protec ted Peer G rou ps (PPG ) wh ic h is a s oftware in fras tru c tu re th at s u pports th e im plem en tation of c on tex tu al d epen d en t applic ation s on m obile d evic es c on n ec ted in ad h oc d ec en traliz ed n etworks with s u pport of d yn am ic g rou p form ation, m an y types of u s ers, c on trol of ad m is s ion an d c on c ealm en t of d ata. PPG offers th e pos s ibility for c on s tru c tion of h ierarc h ic g rou p s tru c tu res with ou t n eed for c en tral s teerin g. T h is th es is work d es c ribes th e d es ig n of a c om m u n ic ation protoc ol wh ic h is u s ed for c om m u n ic ation on g rou p level an d on th e in d ivid u al level between s olitary u s ers. T h e im plem en ted prototype d em on s trates th e u s e of th e pres en ted c on c epts an d allows u s ers to c reate g rou ps, ad m in is ter m em bers h ip an d s h are in form ation s with oth er u s ers. T h e im plem en tation is bas ed on S c ribe wh ic h is an alg orith m th at form s g rou ps in a peer-to-peer n etwork bas ed on Pas try.

Indho ld 1 I n tro d uk tio n 1 1.1 M otivation...................................... 2 1.2 U se C ase...................................... 2 1.2.1 Forudsætninger for use casen........................ 3 1.2.2 A ktører................................... 4 1.2.3 B eskrivelse................................. 5 1.2.4 Systemkrav................................. 6 1.3 Formål........................................ 7 2 O b jek ter o g rettig h ed er 8 2.1 O bjektmodellen................................... 9 2.1.1 Domæner.................................. 9 2.1.2 O bjekter og access-matricen........................ 10 2.2 O bjekter....................................... 11 2.2.1 R ettigheder................................. 12 2.2.2 R oller.................................... 14 2.3 Inferensregler.................................... 14 2.3.1 A ccess-matricen.............................. 14 2.3.2 Statiske regler................................ 15 2.3.3 Dynamiske regler.............................. 15 2.4 Transformationer på access-matricen........................ 17 3 S ik k erh ed 20 3.1 Symmetrisk kryptografering............................ 21 3.2 Public-key-kryptografering............................. 21 3.2.1 R SA..................................... 22 3.3 Digitale signaturer................................. 23 3.4 H ash-funktioner................................... 23 3.5 C ertifi kater..................................... 24 3.6 Distribution af nøgler................................ 27 3.7 E n protokol til sikker kommunikation....................... 27 4 Peer-T o -Peer 30 4.1 P2P vs. klient-server................................ 31 4.2 P2P rutning..................................... 32 iii

4.3 Chord........................................ 33 4.4 Pastry........................................ 33 4.5 Gruppekommunikation............................... 34 4.5.1 Scribe.................................... 35 5 Protec ted Peer G roup s (PPG ) 37 5.1 Applikationslaget.................................. 38 5.2 Komponentlaget................................... 38 5.2.1 Komponenters identitet........................... 38 5.2.2 Komponent-API.............................. 39 5.3 Rutningslaget.................................... 41 5.4 Konceptmodel.................................... 43 6 Kommunika tionsp rotokol 45 6.1 Besked-systemet.................................. 46 6.1.1 Kommunikation på gruppeniveau..................... 46 6.1.2 Direkte kommunikation mellem komponenter............... 47 6.1.3 Egenskaber ved besked-systemet...................... 51 6.2 Beskeder...................................... 52 6.2.1 Kreering af komponenter.......................... 52 6.2.2 Udledning af rettigheder.......................... 55 6.2.3 Tildeling og sletning af rettigheder..................... 58 6.2.4 Oprettelse af medlemskab......................... 59 6.2.5 Komponentspecifikke operationer..................... 62 6.2.6 Validering af beskeder........................... 63 7 Imp lementa tion 65 8 Forsla g til udv idelser 68 8.1 Replikering..................................... 68 8.2 Indmeldelse i grupper................................ 69 8.3 Capabilities..................................... 71 8.4 Søgning på tværs af grupper............................ 71 8.5 N øgleudveksling.................................. 73 9 Konklusion 74 L ittera tur 75 Ap p endiks 77 A Sekv ensdia gra mmer 77 A.1 deliver........................................ 77 A.2 sendreq uest..................................... 78 A.3 createcomponent.................................. 79 iv

B PPG kildekode 80 B.1 ppg.component................................... 80 B.1.1 Component.java.............................. 80 B.1.2 ComponentBase.java............................ 82 B.1.3 ComponentFactory.java.......................... 83 B.1.4 ComponentId.java............................. 83 B.1.5 ComponentIdFactory.java......................... 84 B.1.6 ComponentImpl.java............................ 84 B.1.7 ComponentProxy.java........................... 88 B.1.8 OperationFailedException.java....................... 91 B.2 ppg.component.file................................. 91 B.2.1 FileComponent.java............................ 91 B.2.2 FileComponentFactory.java........................ 92 B.2.3 FileComponentImpl.java.......................... 92 B.2.4 FileComponentProxy.java......................... 94 B.3 ppg.component.file.rights.............................. 95 B.3.1 ReadRight.java............................... 95 B.3.2 W riteright.java............................... 95 B.4 ppg.component.group................................ 96 B.4.1 GroupComponent.java........................... 96 B.4.2 GroupComponentFactory.java....................... 97 B.4.3 GroupComponentImpl.java......................... 98 B.4.4 GroupComponentProxy.java........................ 105 B.5 ppg.component.group.messaging.......................... 108 B.5.1 AddToJ oinl istmessage.java........................ 108 B.5.2 ComponentAvailableMessage.java..................... 108 B.5.3 ComponentDeletedMessage.java...................... 109 B.5.4 CreateComponentMessage.java...................... 109 B.5.5 ExportKeyStoreReplyMessage.java.................... 110 B.5.6 ExportKeyStoreRequestMessage.java................... 110 B.5.7 ImportKeyStoreMessage.java....................... 111 B.5.8 InformRightRemovedMessage.java.................... 111 B.5.9 InviteMessage.java............................. 112 B.5.10 IsMemberMessage.java........................... 112 B.5.11 IsMemberReplyMessage.java....................... 113 B.5.12 J oinmessage.java.............................. 114 B.5.13 J oinreplymessage.java........................... 114 B.5.14 J oinrequestmessage.java......................... 115 B.5.15 MulticastMessage.java........................... 115 B.5.16 RemoveFromJ oinl istmessage.java.................... 116 B.5.17 SendMulticastMessage.java........................ 116 B.6 ppg.component.group.rights............................ 117 B.6.1 MemberRight.java............................. 117 B.6.2 MulticastRight.java............................. 117 B.7 ppg.component.icc................................. 118 v

B.7.1 ComponentKeyStore.java......................... 118 B.7.2 Icc.java................................... 120 B.7.3 IccFactory.java............................... 136 B.7.4 IccMessageDispatcher.java......................... 136 B.7.5 IccObserver.java.............................. 138 B.8 ppg.component.messaging............................. 138 B.8.1 AddRightMessage.java........................... 138 B.8.2 HasRightMessage.java........................... 139 B.8.3 HasRightReplyMessage.java........................ 140 B.8.4 Message.java................................ 140 B.8.5 OperationDeniedReplyMessage.java.................... 141 B.8.6 OperationReplyMessage.java....................... 142 B.8.7 OperationRequestMessage.java...................... 142 B.8.8 RemoveRightMessage.java......................... 143 B.8.9 ReplyMessage.java............................. 143 B.8.10 RequestMessage.java............................ 143 B.9 ppg.component.rights................................ 144 B.9.1 AccessControlList.java........................... 144 B.9.2 Inferens.java................................ 147 B.9.3 OwnerRight.java.............................. 150 B.9.4 Right.java.................................. 150 B.10 ppg.dtl........................................ 150 B.10.1 ComponentManager.java.......................... 150 B.10.2 Dtl.java................................... 152 B.10.3 DtlAddress.java............................... 153 B.10.4 DtlMessage.java.............................. 154 B.11 ppg.dtl.requesthandler................................ 155 B.11.1 DtlClient.java................................ 155 B.11.2 DtlClientFactory.java............................ 155 B.11.3 DtlClientHandler.java........................... 155 B.11.4 DtlMessageClient.java........................... 156 B.11.5 DtlServer.java................................ 158 B.12 ppg.dtl.requesthandler.socket............................ 159 B.12.1 SocketDtlAddress.java........................... 159 B.12.2 SocketDtlClient.java............................ 159 B.12.3 SocketDtlClientFactory.java........................ 160 B.12.4 SocketDtlClientHandler.java........................ 161 B.12.5 SocketDtlServer.java............................ 162 B.13 ppg.frontend..................................... 163 B.13.1 Frontend.java................................ 163 B.13.2 FrontendListener.java............................ 163 B.14 ppg.frontend.direct................................. 164 B.14.1 DirectFrontend.java............................. 164 B.14.2 DirectFrontendListener.java........................ 165 vi

C Test 166 vii

For or d Dette speciale beskriver udviklingen af Protected Peer Groups (PPG), en softwareinfrastruktur der understøtter implementation af kontekstafhængige applikationer på mobile apparater forbundet i ad hoc, decentrale netværk med understøttelse af dynamisk gruppedannelse, mange typer brugere, adgangskontrol og hemmeligholdelse af data. Al kode er udviklet og testet med Sun s Java Software Development Kit v.1.4.2 [JAVA, 2004]. Koden er skrevet i Eclipse v.3 [ECLIPSE, 2004]. I koden anvendes freepastry [FP, 2004], som er en open source implementation af Pastry og Scribe. Rapportens layout er formatteret med L A TEX. Der er en hjemmeside relateret til dette speciale. Hjemmesiden indeholder en elektronisk kopi af rapporten, Java kildekode, JavaDoc dokumentation og en kompileret version af det udviklede testprogram. Adressen er: http://www.itu.dk/people/kimbonde/kimbonde/ima speciale/ Specialet er skrevet under IT-Universitetet i København, foråret 2004. Rapporten er skrevet på dansk, men af praktiske og forståelsesmæssige årsager er enkelte termer og begreber bibeholdt i deres engelske oprindelse i situationer hvor en oversættelse kun ville forvirre begrebet yderligere. I den udviklede software er alle funktions- og variabelnavne samt kode-kommentarer skrevet på engelsk. Kildekoden er placeret som bilag bagerst i rapporten. Vi vil gerne takke vores vejledere Thomas Hildebrand og Henning Niss for deres hjælp og vejledning under udviklingen af specialet. Morten Flintrup Kim Bonde viii

Ka p ite l 1 Introduktion I dette kapitel beskrives de idéer, som ligger til grund for specialet. Kapitlet er en introduktion, som skal indføre læseren i de oprindeligt tanker og overvejelser, som har ført frem til udviklingen af Protected Peer Groups (PPG). I afsnit 1.1 beskrives motivationen for at skrive specialet. I afsnit 1.2 præsenteres en use case, som beskriver funktionaliteten i systemet ud fra brugernes synsvinkelt. Use casen er et tænkt eksempel på hvordan PPG vil kunne anvendes i dagligdagen på ITU. I afsnit 1.3 beskrives formålet med specialet. 1

1.1 M o tiva tio n Peer-to-peer har i de seneste år vundet stor udbredelse på internettet, hvor fildelingstjenester som fx Napster, Gnutella og Emule vha. peer-to-peer danner netværk med tusinder af brugere. Peerto-peer er idéelt til fildeling pga. sin selv-organiserende natur. Peer-to-peer-netværk kræver ingen central styring, hvilket er en god egenskab i systemer hvor brugere kommer og går ofte. Derudover er de fejltolerant, da der ikke er noget sin g le poin t of failu re, som i traditionelle klient/servernetværk. De fl este peer-to-peer-systemer er kendetegnet ved, at de er åbne for alle som ønsker at deltage i dem. Netop dette er en fordel for fildelingstjenesterne, hvis styrke ligger i evnen til at skalere: fl ere brugere betyder fl ere filer. Den nyeste trend inden for peer-to-peer er grupper. Scribe [Castro et al., 2002] [Rowstron et al., 2001] er en algortime, som danner grupper i et netværk baseret på peer-to-peeralgoritmen Pastry [Rowstron and Druschel, 2001]. Hvor målet i de fl este peer-to-peer-netværk er, at rute informationer mellem enkelte computere, tilbyder Scribe kommunikation gruppeniveau. Som de fl este andre peer-to-peer-netværk er Scribe som udgangspunkt et åbent netværk, hvor alle der ønsker det, kan tilmelde sig grupperne i systemet. Motivationen for dette speciale har været, at designe en softwareinfrastruktur der understøtter grupper som i Scribe, men hvor det er muligt at hemmeligholde data og implementere adgangskontrol til grupperne. I modsætning til diverse fildelingstjenester skal det være muligt at opsætte rettigheder, som beskriver hvem der må tilgå hvilke ressourcer. En ekstra motivationsfaktor har været at undersøge, om projektet kan bidrage til IT-Universitetets forskning i kontekstafhængig kommunikation. 1.2 U s e C a s e Use Casen i dette afsnit danner grundlag for udviklingen af Protected Peer Groups (PPG) ved at introducere et scenarie, som beskriver funktionaliteten i systemet ud fra brugernes synsvinkelt. Brugerne er studerende og ansatte ved IT-Universitetet (ITU). Scenariet er et tænkt eksempel på hvordan PPG vil kunne anvendes i dagligdagen på ITU. Use Casen beskriver systemets forventede adfærd over for brugerne og er dermed med til at afdække systemets grundlæggende krav til funktionalitet. Personerne som indgår i casen er fiktive personer. Kapitlet rundes af med en analyse af de systemkrav, som kan tolkes ud fra casen og som danner grundlag for det videre arbejde med design og udvikling af PPG. Protected Peer Groups (PPG) er et system som administrerer grupper i et computernetværk. En gruppe kan fx bestå af en samling personer, som ønsker at udveksle informationer med hinanden via deres computere. En gruppe kan også være en samling af printere og servere som skal kommunikere med hinanden for at servicere brugerne. De personer/computere som er med i en gruppe, kaldes for medlemmer. PPG administrer medlemskab, dvs. indmeldelse og udmeldelse fra grupper, samt kommunikationen mellem medlemmerne. Systemet tilbyder hemmeligholdese af data inden for grupperne således at kun gruppers medlemmer, har adgang til de informationer der eksisterer i grupperne. I casen er udgangspunktet at ITU anvender PPG til kommunikation mellem studerende, ansatte og andre interessenter. Casen er fiktiv, men skal ses som motivationsfaktor for det videre arbejde med PPG. I afsnit 1.2.1 beskrives rammerne for casen: hvilke systemer (herunder PPG) der anvendes 2

på ITU for at realisere casen. I afsnit 1.2.2 beskrives beskrives casens aktører (hvilke personer der deltager) og i afsnit 1.2.3 gennemgås det egentlige use case-scenarie. I afsnit 1.2.4 analyseres af de systemkrav, som kan tolkes ud fra use case-scenariet. Disse krav danner grundlag for det videre arbejde med at analysere systemet og designe modeller og algoritmer for en konkret implementering af systemet. 1.2.1 Fo ru d sætn in g e r fo r u se case n I dette afsnit beskrives nogle forudsætninger, som skal være til stede for at casen kan realiseres. Nogle af forudsætningerne er fiktive og er blot med for at gøre casen interessant. Dette omfatter PPG, som er det system casen beskriver, og ITU s butler-spø gelse som blot et et eksempel på hvad systemet vil kunne anvendes til. På ITU findes grupper for studerende, undervisere, direktionen, studieadministationen, festudvalget, kantinen, rengøringsafdelignen mfl. Grupperne er selv-konfigurerende således at nye medlemmer eller medlemmer som forlader grupper håndteres uden central administration. IT-Universitetet har en Ekahau positionsserver [EKAHAU, 2004], der lokaliserer trådløse enheder som er tilsluttet Wireless Local Area Network (WLAN). Sådanne enheder kan være bærbare computere, PDA er mv. Positionsserveren monitorerer den fysiske position af hver enkelt enhed og servicerer applikationer som anvender lokationsbaserede informationer. Vha. positionsserveren er det muligt at følge personers fysiske færden i universitetets bygninger. På IT-Universitetet skelnes der mellem to forskellige slags grupper: de lokationsafhængige grupper og de almindelige grupper. En lokationsafhængig gruppe er en gruppe, som er underlagt nogle fysiske faktorer - fx tid og sted. En sådan gruppe eksisterer kun i kraft af en fysisk position (fx et lokale) og/eller et tidspunkt (fx indenfor almindelig kontortid). Et eksempel på dette er en møde-gruppe som kun eksisterer i mødelokalet i det tidsrum hvor mødet finder sted. De deltagere som befinder sig i lokalet i det pågældende tidsrum bliver automatisk medlemmer af gruppen såfremt de har fået tilladelse fra gruppens ejer. Forlades lokalet forlades gruppen også. Grupper af denne type ejes og administreres af universitetets positionsserver. IT-Universitetet har lokationsafhængige grupper for udvalgte fysiske lokationer: dette tæller alle undervisningslokaler, auditorier, øvelseslokaler, kantinen, kontorer og rekreative områder. De almindelige grupper eksisterer på tværs af fysiske forhold. Dette kan være en underviser-gruppe, som også eksisterer når underviserne sidder der hjemme og derfor ikke er fysisk til stede på universitetet. DELCA-spøgelser [Hansen et al., 2003] er en del af hverdagen på ITU. DELCA står for D i- se m bod ied L ocation-specifi c C onv ersational Agents, og er et forskningsprojekt under L aboratory for C ontex t-d epend ent M obile C om m unication (LaCoMoCo) på IT-Universiteten [LaCoMoCo, 2004]. Et spøgelse er en mobil agent, eller et mobilt program, som hjælper personer med forskellige gøremål i hverdagen - fx at finde vej i ITU s bygninger, overvåge ting, finde printere eller underholde med spil. D ise m bod ied hentyder til det, at spøgelser ikke er normale fysiske væsner, som er underlagt de samme fysiske love som almindelige fysiske væsener. Fx kan spøgelser gå gennem vægge, og forsvinde ud i den blå luft for senere at dukke op igen. C onv ersational hentyder til det, at DELCA-spøgelser konverserer auditivt med mennesker og forstår almindelig tale. Spøgelserne er software-programmer, som kan eksekveres på computere, PDA ere, mobiltelefoner mv., og som 3

er i stand til at flytte sig fra en fysisk enhed til en anden. Casen tager udgangspunkt i følgende grupper på IT-Universitetet: ITU Denne gruppe indeholder generel information omkring IT-Universitetet herunder pressemeddelelser, nyhedsbreve, aktivitetsplaner, ansøgningsskemaer, kursusbeskrivelser osv. Gruppen er relevant for alle som har interesse i disse informationer, fx studerende, ansatte, journalister mv. Alle interessenter kan frit melde sig ind i gruppen - dette gælder også personer som ikke har nogen direkte tilknytning til IT-Universitetet. ITU-Location Denne gruppe er lokationsafhængig og indeholder information, som er relevant for folk som befinder sig rent fysisk på IT-Universitetet - herunder lektions- og lokaleplaner, kort over universitetets bygninger, menukort med information om dagens ret i kantinen mv. ITU- Location er også hjemsted for universitetets Butler-spøgelse som guider folk rundt i bygningerne. Medlemskab af ITU-Location medfører automatisk medlemskab af ITU. Gruppen er relevant for studerende og ansatte, men også andre besøgende som fx gæsteforelæsere, håndværkere, rengøringpersonale mv. kan have glæde af informationerne i gruppen. Room-0.60 Denne gruppe er lokationsafhængig og definerer en gruppe som eksisterer i lokale 0.60. Students Denne gruppe er til for de studerende ved IT-Universitetet. Gruppen er lukket således at kun studerende ved IT-Universitetet kan blive medlem. Gruppen er ikke lokationsafhængig og dermed kan medlemskab opretholdes selvom de studerende ikke er fysisk til stede på IT-Universitetet. Gruppen indeholder information som er relevant for studerende; fx nyhedsbreve, skemaændringer og information om sociale arrangementer. 1.2.2 Ak tø rer I casen deltager følgende tre aktører: Lars Lektor på IT-Universitetet. Underviser i Location Based Services og har i den forbindelse oprettet gruppen LBS. Gruppen bruges af Lars til at dele relevante undervisnings-materialer med de studerende - fx en deltagerliste, slides til undervisningen, øvelsesopgaver og -løsningsforslag. LBS er ikke lokationsafhængig, hvilket betyder at eleverne kan tilmelde sig gruppen hjemmefra. Gruppen fungerer samtidig som et fælles forum hvor eleverne kan dele undervisningsrelevante informationer hinanden. Lars har givet tilladelse til, at alle studerende som følger kurset kan melde sig ind i gruppen. Undervisningen finder sted i lokale 0.60 onsdag formiddag kl. 9:30. Alice Ny studerende ved IT-Universitetet. Skal have sin første forelæsning i faget Location Based Services. Hun er i besiddelse af en PDA med WLAN-tilslutning og har på opfordring fra IT- Universitetet installeret en PPG-klient på sin PDA, så hun kan deltage i ITU s grupper. Hun har læst den information som er tilgængelig i ITU-gruppen, herunder kursusbeskrivelsen til Location Based Services. Hun har også forberedt sig til undervisningen ved at læse de slides og lignende materialer, som Lars har gjort tilgængelige gennem LBS-gruppen. Hun har dog ikke kendskab til IT-Universitetets fysiske indretning, herunder hvor lokale 0.60 er. 4

Bob Studerende ved IT-Universitetet. Følger ligesom Alice faget Location Based Services. Han har været studerende i et stykke tid, og er derfor fortrolig med PPG. 1.2.3 B eskrivelse Scenarie 1 Alice træder ind af døren på IT-Universitetet onsdag morgen kl. 09:15 og bliver spontant kontaktet af universitetets butler-spøgelse, som taler til hende fra en højttaler på vægen. Han fortæller at hun har 15 minutter inden hendes første forelæsning i Location Based Services starter i lokale 0.60. Han spørger, om hun ønsker at blive fulgt hen til lokalet. Det vil Alice gerne. Hun accepterer en invitation på sin PDA, hvorefter et lille kort med en pil dukker frem i displayet. Hun følger guiden frem til lokalet. Scenarie 2 I undervisningslokalet møder Alice Bob, som er i gang med at læse kursets velkomshilsen på sin bærbare computer. Denne velkomsthilsen har Alice ikke set før, og spørger derfor Bob, om han kan overføre den til hende. Bob forklarer, at hun blot skal kigge i mappen LBS på sin PDA. Alice opdager til sin overraskelse, at velkomstdokumentet allerede er blevet lagt ind på hendes PDA uden at hun vidste det. Scenarie 3 Lars ankommer til lokalet og går i gang med at præsentere sig selv og kurset. I præsentationen indgår nogle elektroniske dokumenter, som Lars sender til eleverne. Ved at adressere til gruppen LBS kan Lars dele dokumenterne med alle studerende på kurset inklusiv dem som ikke er fysisk til stede. Nogle af dokumenterne er derimod kun relevante for dem, som er fysisk til stede. Disse dokumenter adresserer Lars til de elever, som både er med i kursets gruppe (LBS) og samtidigt befinder sig i lokale 0.60. Scenarie 4 Alice og Bob beslutter sig for, at de vil danne en læsegruppe. Til formålet, har de brug for, at kunne dele dokumenter med hinanden. Bob kreerer en ny gruppe, som han kalder for AB. Alice forsøger at tilgå gruppen, men får ikke lov. Bob forklarer, at det er fordi han automatisk ejer gruppen, fordi det var ham som kreerede den. Derefter giver han Alice adgang til gruppen på lige vilkår med ham selv. Nu er Alice medejer af gruppen, og kan tilgå alt hvad der er i den. Gennem AB kan Alice og Bob altså udveksle informationer, uden at andre elever kan se dem. Scenarie 5 Alice og Bob laver sin første skriftlige opgave. For at Lars skal kunne læse opgaven, bliver han tildelt rettigheden til at læse dokumentet fra AB. Eventuelle andre dokumenter som ligger i AB kan Lars ikke se. 5

1.2.4 S y stemkrav Use casen beskriver nogle grundlæggende krav som skal opfyldes af PPG for at casen kan realiseres. Forudsætningerne i afsnit 1.2.1 beskrev hvordan Alice på forhånd har installeret en PPGklient, som gør hende i stand til at tilgå ITU s grupper både på ITU og hjemmefra. Denne forudsætning fortæller med andre ord, at PPG ikke blot skal kunne anvendes på et lokalt netværk (fx IT-Universitetets LAN), men overalt hvor brugerne færdes. I scenarie 1 bliver Alice budt velkommen af ITU s butler-spøgelse, som først taler til hende fra en højttaler på vægen, og senere guider hende gennem bygningen fra hendes PDA. Dette fortæller at der skal være mulighed for at implementere mobil kode i systemet - altså programmer som flytter sig fra én fysisk position til en anden. Desuden skal teknologien være mulig at implementere på forskellige platforme, som i dette eksemplet hvor butleren først hopper fra en pc forbundet til en højttaler og derfra videre til en PDA. Y derligere skal det være muligt at kombinere teknologien med lokationsafhængige parametre således, at butleren kan registrere Alice s fysiske færden. Med andre ord, skal det være muligt at præsentere brugere med informationer, som er relevante for dem i den situation de befinder sig i. I eksemplet bliver Alive automatisk meldt ind i gruppen ITU-Location i det øjeblik hun træder ind af døren. Scenarie 2 beskriver hvordan de informationer, som allerede er i en gruppe bliver tilgængelige for nye medlemmer af gruppen. I eksemplet åbner Alice mappen LBS. Det der i virkeligheden sker er, at hun melder sig ind i gruppen LBS (tilladelsen til at melde sig ind, har hun fået af Lars, der som underviser administrerer gruppen), hvorefter det velkomsdokument, som i forvejen eksisterer i gruppen, bliver tilgængeligt for hende. For Alice ser det ud som om, hun har fået en kopi af dokumentet. Med andre ord, er det transparent over for Alice hvordan hun rent teknisk får adgang til dokumentet. Scenarie 3 beskriver hvordan informationer distribueres til alle medlemmerne af en gruppe. I eksemplet deler Lars dokumenter med eleverne på kurset. Altså skal det ikke blot være muligt at kommunikere direkte mellem to enheder; det skal være muligt nemt at distribuere data til mange på én gang. Scenariet beskriver også, at det skal være muligt at opstille krav til hvem der modtager informationer. I eksemplet sender Lars dokumenter de elever, for hvem det gælder, at de både befinder sig i gruppen LBS og i lokalet 0.60 (gruppen Room-0.60). I scenarie 4 forsøger Alice at tilgå gruppen AB uden at hun har fået tilladelse af gruppens ejer Bob og forsøget bliver afvist. Derefter tildeler Bob Alice de samme rettigheder til gruppen som han selv har. Dette beskriver at det i PPG skal være muligt, nemt at tildele rettigheder til andre brugere - i dette tilfælde rettigheden til at administrere AB på samme vilkår som Bob. I scenarie 5 får underviseren Lars lov til at læse en opgavebesvarelse, som Alice og Bob har lagt i gruppen AB. Men han kan ikke rette i den. Scenariet fortæller dermed, at rettigheder til de informationer der er i en gruppe, kan variere alt efter hvem der prøver at tilgå dem. Eksemplet fortæller yderligere, at Lars kun kan se det i AB, som han har rettigheder til - altså den pågældende opgavebesvarelse og ikke andre dokumenter som ellers eksisterer i gruppen. Altså skal det være muligt, inden for samme gruppe, at have forskellige rettigheder over forskellige informationer. 6

1.3 For m ål Formålet med specialet er, at designe et system, som understøtter de krav, der blev skitseret i use casen: Det skal være muligt at oprette grupper til udveksling af informationer i et computer-netværk. Grupperne skal fungere uden central styring og det skal være muligt at administrere medlemskab og beskytte gruppernes indhold med rettigheder. Det skal være muligt at oprette private grupper med hemmeligholdelse af data således, at kun dem som har de fornødne rettigheder kan se og tilgå gruppernes indhold. Grupper skal kunne organiseres i strukturer, således at medlemskab af én gruppe automatisk medfører medlemskab af andre grupper. Rettighederne til gruppers indhold skal kunne ændres løbende. Det skal være muligt at kommunikere på gruppeniveau, dvs. distribuere informationer til alle medlemmer af en gruppe. Det skal være muligt for gruppers medlemmer at blive meldt ind og ud af grupper, uden at dette har indvirkning på andre medlemmer af grupperne. 7

Kapitel 2 Obje kte r og re ttig he de r Det system som blev beskrevet i use casen i afsnit 1.2 består af nogle entiteter, som er underlagt et regelsæt, der bestemmer hvilke operationer, der kan foretages på de enkelte entiteter. Af entitetstyper kan nævnes filer, processer, hukommelsesblokke mv. En operation er en handling, som påvirker eller ændrer en entitets tilstand; fx data som bliver skrevet i en fil. En operation udføres af én entitet på en anden entitet. Forskellige entitetstyper har forskellige operationer og hver entitetstype kan teoretisk set have uendelig mange forskellige operationer. Regelsættet bestemmer hvilke entiteter der har lov til at udføre hvilke operationer. Forskellige entiteter har potentielt forskellige rettigheder til at udføre operationerne. I kapitlet indføres begrebet gruppe, som dækker over en samling af entiteter. En gruppe er i sig selv også en entitetstype, som er underlagt det samme regelsystem som andre entiteter. Derfor kan en gruppe også udføre operationer på andre grupper. Regler tildeles på gruppeniveau, hvilket vil sige, at alle entiteter, der har lov til at udføre operationer på entiteterne i en gruppe, har lov til at udføre de samme operationer. Formålet med dette kapitel er at beskrive en model, som gør det muligt at implementere ovenstående system. I afsnit 2.1 beskrives først objekt-modellen [Lampson and Alto, 1971], som er en model, der beskæftiger sig med rettigheder i et system med mange entitetstyper, og som eventuelt kan være distribueret. I afsnit 2.2 gives nogle eksempler på forskellige entitetstyper og operationer, som det vil være muligt at implementere. Der gives yderligere nogle eksempler på konkrete rettighedstyper. I afsnit 2.3 anvendes objekt-modellen sammen med inferensregler til at definere og beskrive det regelsæt som alle entiteter er underlagt. I afsnit 2.4 anvendes inferensreglerne i et tænkt eksempel, hvori der indgår nogle konkrete entitetstyper og rettigheder til at foretage ændringer i access-matricen. Kapitlet afrundes med en evaluering af den udviklede model. 8

2.1 O b jek tmod ellen Rettighedssystemet i dette kapitel er inspireret af artiklen Protection [Lampson and Alto, 1971] fra 1971. Artiklen beskriver en generel mekanisme til håndtering af adgangskontrol således, at forskellige dele i et computersystem kan beskyttes mod utilsigtet adgang fra programmer og brugere. Fortatterne argumenterer for, at adgangskontrol har stor betydning i computersystemer, hvor kritiske og/eller personlige data potentielt set er tilgængelige for en stor mængde brugere og programmer. Adgangskontrollen skal sikre data mod ondsindede handlinger og fejlhandlinger fra brugere og computerprogrammer. Adgangskontrol er i dag en integreret del i de fleste operativsystemer. I 70 erne hvor Protection er fra, var multibrugersystemer og computernetværk primært forbeholdt banker, forsikringsselskaber, statslige institutioner og universiteter, men i dag hvor internettet er blevet en fast del af mange menneskers hverdag, er der for alvor brug for at kunne beskytte data. Utallige eksempler på virus, orme, trojanske heste, spyware, hackere osv. understreger vigtigheden af god adgangskontrol i alle systemer. Men ikke kun i systemer, hvor der er adgang udefra, er vigtige at beskytte. En vigtig anerkendelse er, at truslen ofte kommer indefra, fra medarbejderen som af den ene eller anden grund er interesseret i at skade andre eller tilegne sig selv fortrolig information. De seneste år har vist mange eksempler hvor brugeren selv, ofte pga. manglende viden omkring sikkerhed, er en medvirkende årsag til spredning af virus - emails med vedhæftede programmer, som brugeren ukritisk eksekverer, er gode eksempler herpå. Eksemplerne understreger for alvor vigtigheden af et godt sikkerhedssystem, hvori adgangskontrol har en central rolle. Adgangskontrol skal kunne styres både på brugerniveau og internt i computersystemerne mellem de enkelte programmer. 2.1.1 Domæner Protection arbejder med et idealiseret system kaldet besked-systemet. Besked-systemet består af processer, der som udgangspunkt ikke deler data og som kommunikerer med hinanden ved at sende beskeder. En besked består af en identifikation af afsender-processen efterfulgt af et arbitrært argument. Identifikationen påføres af systemet og kan ikke ændres af processerne. Argumentet er blot noget data og hvilke data, der sendes varierer alt efter den aktuelle kontekst. Hver proces tildeles et navn i form af en heltalsværdi, således at en given værdi altid refererer til den samme proces. Navnet bruges af systemet som identifikation i beskederne. Alle processer kan sende beskeder til hinanden og beskederne leveres i den rækkefølge som de er afsendt i. I besked-systemet er alt hvad der eksisterer ejet af en proces og det kan ikke tilgås af andre processer end ejeren. Det som en proces ejer, hører derfor ind under processens domæne. Hver process er sit eget domæne, der kan betragtes som sin egen separate maskine med egen RAM, disk osv., og isoleret af hardware fra alle andre domæner med undtagelse af besked-systemet som beskrevet ovenover. Når en proces (A) ønsker at kommunikere med proces (B) sker det efter følgende princip: 1. A, hvis navn er [1234], ønsker at sende en besked indeholdende værdierne [AA BB CC] til B. A leverer beskeden til systemet og venter derefter på en svar-besked fra B. 2. Systemet påhæfter A s navn som identifikation til beskeden og leverer den til B. 9

3. B modtager beskeden [1234 AA BB CC]. Eftersom den første værdi bliver påhæftet af systemet uden A s indvirken, så ved B at beskeden kommer fra A. 4. B sender en svar-besked til A og systemet påhæfter B s identifikation til beskeden. 5. A modtager svar-beskeden og verificerer at den indeholder B s identifikation. Systemet beskytter A mod uventede svar-beskeder fra B (eller andre processer i systemet), idet A ved hvornår den forventer en svarbesked fra B. Der kan opstå situationer, hvor en svarbesked ikke når frem - evt. som følge af en fejl i B. I denne situation bør A implementere et timeout, således at der aldrig ventes længere end den tid som B forventes at være om at håndtere forespørgslen. Som antydet i artiklen er identifikationen i en besked ikke det samme som et password. Således gælder, at A ikke alene på baggrund af sit navn kan tilegne sig rettigheder over ting i B s domæne. Identifikationen beviser blot over for B, at den kommunikerer med A, men fortæller ikke noget om hvilke rettigheder A har. En problemstilling som metoden ovenover ikke adresserer er, hvordan A og B på en sikker måde udveksler deres navne. Godtnok kan B læse A s navn fra beskeden, men hvordan sikrer B sig, at navnet rent faktisk tilhører A? Protection nævner et eksempel, hvor A og B er to bruger-terminaler. De to brugere ved terminalerne ønsker at kommunikere med hinanden gennem systemet, men inden da råber bruger-a sit identifikationsnummer gennem lokalet og bruger-b indtaster det i sin terminal. Derefter råber bruger-b sit identifikationsnummer gennem lokalet og bruger-a indtaster det i sin terminal. De to brugere kan nu kommunikere sikkert gennem systemet. Ulempen ved metoden er, at de to brugere er nødt til at kommunikere ansigt til ansigt inden datatransmissionen kan finde sted. Kernen i problemstillingen drejer sig om hvordan nøgler udveksles over et usikkert medium. En løsning foreslået af Diffie og Hellman [Diffie and Hellman, 1976] drejer sig om netop dette. Metoden der er kendt som Diffie-H elleman key agreement protocol er baseret på asymmetrisk kryptering og beskriver en protokol til, hvordan to nøgler kan udveksles over et usikkert medium uden nogen forudgående kommunikation. Asymmetrisk kryptering og nøgleudveksling behandles separat i kapitel 3. 2.1.2 O bjekter og access-matricen Til håndtering af rettigheder foreslår Protection en løsning der kaldes objekt-systemet. I objektsystemet indgår tre dele: objekter, domæ ner og en access-matrice. Objekterne er de entiteter, i systemet, som det skal være muligt at beskytte. Dette kan fx være datafiler, hukommelsessegmenter mv. Objekter har navne, som gør dem globalt unikke - artiklen foreslår en 64-bit heltalsværdi; en anden løsning er at anvende en hashværdi baseret på MD5 eller SHA-1 beregnet over objektets navn og indhold (hash-værdier og -algoritmer behandles separat i afsnit 3.4). Domænerne blev introduceret i forrige afsnit. Det er de entiteter i systemet, som har adgang til objekterne. I besked-systemet var domænerne en process, med eksklusiv adgang til sine egne objekter og ikke til andre objekter. Denne model bliver nu generaliseret således, at objekter kan deles på tværs af domæner. Desuden betragtes domæner som værende en speciel type objekter, der kan beskyttes på lige vilkår med andre objekttyper. Access-matricen kæder domæner sammen med objekter via rettigheder. Et domæne har potentielt set forskellige rettigheder til objekterne i systemet end andre domæner. Objekter og domæner 10

organiseres således, at domæner placeres i matricens rækker og objekter i matricens kolonner. Et udsnit af access-matricen, som den er illustreret i Protection er vist i figur 2.1. A!! " * owner * owner * call * owner control control * read * write! " call * read wakeup! " owner read control Figur 2.1: Ud s n it a f F ig u r 1 fra a rtikle n P ro - te c tio n [L a m p s o n a n d Alto, 19 7 1]. F ig u re n v is e r access-m a tric e n, h v o r d o m æ n e r e r p la c e re t i m a tric e n s ræ kke r o g o b je kte rn e i ko lo n n e rn e. Tilg a n g s re ttig h e d e r e r illu s tre re t i d e e n ke lte c e lle r. Access-matricen skal læses således at celle #$&%' refererer til de rettigheder som domæne i har til objekt j. I figur 2.1 vises nogle eksempler på rettigheder, hvoraf kun nogle få vil blive beskrevet her: ow ner indikerer at et domæne ejer et objekt. At eje et objekt medfører retten til at slette objektet. control indikerer at et domæne kan kontrollere et andet domæne: Objekt-systemet opererer med en såkaldt kopiérbarh edsegenskab (illustreret med en stjerne (* ) ud for den enkelte rettighed) som betyder at et domæne ( kan kopiere rettigheder r videre til et andet domæne (, hvis ( kontrollerer ( og kopiérbarhedsegenskaben er sat for r. Fx kan! " kopiere readrettigheder over )* videre til " eftersom kontrollerer og har * read-rettigheden sat over +,. 2.2 Objekter I dette afsnit og fremefter arves begrebet objekt fra Protection beskrevet i afsnit 2.1. Begrebet gruppe introduceres. En gruppe er det samme som et domæne i Protection. De entiteter som omfattes af systemet kaldes for objekter. Objekterne har forskellige egenskaber, men fælles for dem alle er, at de er underlagt det samme regelsystem. Regelsystemet skal beskytte objekterne mod uautentificeret tilgang og behandles nærmere i afsnit 2.2.1. I dette afsnit beskrives nogle eksempler på forskellige objekter og deres anvendelsesområder. Objekterne kan have forskellige formål og adfærd. De kan fx bruges til at lagre, bearbejde og formidle data eller til at starte og stoppe processer. Herunder nævnes nogle få eksempler på objekter: fi ler Datafiler til opbevaring af informationer. Informationerne kan være digitale billeder, lyd, film, dokumenter mv. Fildelingstjenester såsom Kazaa, Napster og OpenSource-projektet Emule, som i de senere år har vundet stor udbredelse på internettet, giver netop denne mulighed for hurtigt og nemt at dele data med andre. Lagringsformen kan være temporær eller persistent efter behov; fx kan der anvendes RAM, flash eller disk mv. Filen kan endda være replikeret eller distribueret således, at filens indhold ligger spredt i et netværk. processer En proces kan foretage beregninger selvstændigt på foranledning af andre. Denne mulighed kan fx anvendes i forbindelse med distribuerede beregninger og grid-teknologi, hvor 11

processen modtager og bearbejder en lille del af en større beregning. Et eksempler på dette er SETI@home, et projekt under Berkley universitetet i Californien [SETI, 2004], som anvender distribuerede algoritmer til bearbejdning af radiosignaler i håbet om at finde intelligent liv i rummet. Løsninger som disse kan have kommerciel interesse, da processorkraft er en potentiel handelsvare. Processerne skal kunne startes og stoppes remote. Mobile agenter (herunder spø gelser) Mobile agenter er eksempler på distribuerede, selvstændige og ofte intelligente applikationer, som frit kan bevæge sig rundt i et netværk og indsamle data, foretage beregninger og interagere med mennesker. Spøgelser som dem under DELCA-projektet på IT-Universitetet i København [Hansen et al., 2003], er en speciel type mobil agent, som kommunikerer auditivt med mennesker. Mobile agenter kan med fordel anvendes i små systemer (fx embeddede systemer), hvor mangel på RAM eller lagerplads sætter en naturlig grænse for, hvor meget software enheden kan rumme. Her kan mobile agenter bidrage med ny, midlertidig funktionalitet til en given opgave. Et eksempel er en printer, der modtager et printjob i et på forhånd ukendt format. Vha. den nævnte teknologi kan printeren downloade en mobil agent, som er i stand til at håndtere jobbet. Efter endt processering, kan printeren vælge at fjerne agenten og frigive ressourcerne. Det nævnte eksempel danner også grobund for en kommerciel anvendelse, idet den mobile agent fx kan råde over en patenteret algoritme, som lejes ud efter et pay-per-view-princip. En gruppe er en speciel type objekt, som indeholder andre objekter. En gruppe kan derfor indeholde filer, processer, spøgelser og andre grupper. Med grupper er det muligt at samle objekter i kategorier efter anvendelsesområde og funktionalitet, rettigheder o.lign. I praksis vil én gruppe fx kunne bruges til opbevaring af dokumenter, en anden til distribution af spøgelser og en tredie som fællesmængde af de to første. Ved at begrænse hvem der kan tilgå objekterne i de forskellige grupper, er det muligt at opbygge en gruppestruktur, som følger forretningsmæssige forhold, sikkerhedszoner og hierakier fra den virkelige verden. Dette kan være brugbart i en organisation, hvor den almindelige medarbejder skal have begrænset adgang til følsomme data som lønforhold, forretningsstrategi og økonomi, men hvor ledelsen skal have ubegrænset adgang. Objekterne i systemet er underlagt en række rettigheder, som skal sikre dem mod uautentificeret tilgang. Rettighederne skal sikre, at følsomme data ikke bliver lækket eller ændret af uvedkommende. En rettighed sættes specifikt for det enkelte objekt. Objekter er selvstændige og ligeledes er de rettigheder, som er gældende for dem. Hvis tilstanden af ét objekt ændres, påvirkes tilstanden af andre objekter af samme type ikke. I det efterfølgende skelnes mellem to forskellige rettighedstyper: de almindelige rettigheder og rettigheder, som medfører andre rettigheder; også kaldet roller. En rettighed giver rettighedshaveren mulighed for at udføre en specifik operation på det pågældende objekt. Med rettighedshaver menes den gruppe som har rettigheden til at udføre operationen. En rolle er en specifik egenskab, som en gruppe har i kraft af en rettighed, den har fået tildelt. Dette kan fx være muligheden for at sætte og fjerne andre rettigheder. 2.2.1 Rettigh eder En rettighed giver mulighed for at udføre en specifik operation på et objekt. Hvilken semantisk betydning den enkelte rettighed har bestemmes af det enkelte objekt: rettigheder som read og 12