Datalogi 1F rapportopgave K2 Anonym datakommunikation

Transkript

1 Datalogi 1F rapportopgave K2 Anonym datakommunikation 23. april Administrativ information Rapportopgave K2 stilles fredag den 23. april 2004 og skal afleveres senest fredag den 14. maj kl. 11: i DIKU s 1.delsadministration, Universitetsparken 1, 2100 København Ø. Besvarelser, der sendes med posten, skal være DIKU i hænde senest ved afleveringsfristens udløb. Besvarelser kan udarbejdes individuelt eller i grupper med op til tre deltagere. Såfremt den studerende har tilmeldt sig rapporteksamen vil K2 senere blive censureret. Der gives ingen mulighed for at forbedre besvarelsen og der gives ikke reduktion i opgavens omfang ved mindre grupper. Gruppesammensætningen ved aflevering af K2 behøver ikke at være den samme som for G1 og K1. Vigtige meddelelser vedrørende denne opgave vil blive meddelt i kursets nyhedsgruppe og på kursushjemmesiden På hjemmesiden kan man ligeledes se en plan for instruktorvagt i opgaveperioden. Ændringer eller præciseringer meddeles i nyhedsgruppen og på kursushjemmesiden af Jørgen Sværke Hansen. 2 Anonym datakommunikation Formålet med denne opgave er at designe og implementere et system, der kan anvendes til anonym kommunikation. Vi vil nedenfor introducere en form for anonym kommunikation inspireret af Tarzan (se for yderligere information), og vil i de efterfølgende afsnit gå i detaljer med hvad der kræves af løsningen til denne opgave. Ved almindelig datakommunikation ses det oftest som en fordel at afsender og modtager klart fremgår af en besked. Men ønsker to parter at kommunikere sammen uden at en tredje part kan opdage denne kommunikation, ændres dette til at være en ulempe. I denne opgave ønskes implementeret et system der i praksis kan skjule identiteten af afsenderen af en besked i et større netværk. Dette kan opnås ved at placere en større mængde relæer til videresending af beskeder forskellige steder i netværket, og derefter lade en besked blive sendt rundt mellem et antal relæer inden den afleveres til modtageren. For at skjule afsenderens identitet foretager hvert relæ en transformation af beskeden inden den videresendes. På denne måde gøres det svært for en tredjepart at overvåge netværkstrafikken og følge en enkelt beskeds vej gennem relæerne. Selve transformationen er oftest baseret på kryptering/dekryptering af beskederne. Bemærk at det skitserede system ikke er immunt overfor angreb. Eksempelvis kan en angriber med kendskab til al trafik i systemet analysere beskedudvekslingserne mellem alle relæer for derved at knytte en afsender til en modtager. Relæerne kan eksempelvis imødegå dette angreb ved at sikre

2 at der er en konstant mængde trafik mellem relæerne eller ved at opsamle beskeder og sende dem afsted i tilfældig rækkefølge. Vi vil i opgaveteksten bruge forskellige former for kryptering til at skjule indholdet af beskeder i netværket. Et kendskab til implementation af kryptering er dog ikke nødvendigt for at løse opgaven, men vi vil i det følgende skitsere den overordnede funktion af de to anvendte krypteringsformer. Givet en besked B, en nøgle KN og en krypteringsalgoritme kan man skjule indholdet af beskeden B ved at kryptere den via krypteringsalgoritmen med nøglen KN. Dette resulterer i en kodet besked KN(B), som kun kan transformeres (dekrypteres) til klarteksten B hvis man kender dekrypteringsnøglen DN og dekrypteringsalgoritmen. Det vil sige, at DN(KN(B)) = B. Hvis DN og KN er den samme nøgle, taler man om symmetrisk kryptering, og ellers er der tale om asymmetrisk kryptering. Den asymmetriske kryptering omtales ofte som offentlig nøgle kryptering, idet en part A kan distribuere sin krypteringsnøgle KN A (den offentlige nøgle) frit, mens det kun er A selv der kan dekryptere beskeder med DN A (den private nøgle), idet denne holdes hemmelig. Det er således nemt for andre parter at sende beskeder til A, som kun A kan læse, givet de andre parter er sikre på hvad A s offentlige nøgle er (ved asymmetrisk kryptering kan man også bruge den private nøgle til kryptering og den offentlige nøgle til dekryptering, f.eks., til brug ved digitale signaturer, men det er denne opgave uvedkommende). Den interesserede læser kan finde yderligere information om kryptering i CN kapitel 7. Lad os vende tilbage til anonymiseringen af beskeder ved at betragte et eksempel på anonym kommunikation. Vi har en afsender A, der ønsker at sende en besked B til modtageren M. For at skjule B s spor gennem netværket udvælger A fire relæer r1,..., r4. Vi antager, at A har kendskab til krypteringsnøgler for r1,..., r4 og M. Når A ønsker at afsende B til M, vil A indkapsle beskeden ved at kryptere den en gang med hver af nøglerne for r1,..., r4 og M - i omvendt rækkefølge af beskedens rute gennem relæerne. A afsender altså en besked af formen: [r1, k r1 ([r2, k r2 ([r3, k r3 ([r4, k r4 ([M, k M (B)])])])])] til r1, hvor k x er x s nøgle og [x, k x (y)] er en besked hvor headeren angiver x som modtager og hvor datadelen y er krypteret med x s nøgle. Bemærk at dette kræver at afsenderen M kan kryptere beskeder som kun x kan dekryptere. Når r1 modtager beskeden vil den dekryptere datadelen og derved se at den næste modtager af beskeden er r2, og sende beskeden [r2, k r2 ([r3, k r3 ([r4, k r4 ([M, k M (B)])])])] til r2. r2 vil dekryptere datadelen og se at den næste modtager er r3. Derved har hvert relæ kun kendskab til den forudgående og den næste station på beskedens vej gennem netværket og samtidig er de enkelte relæer ikke i stand til at dekryptere beskeden idet de kun kender deres egen nøgle. Figur 1 illustrerer hvordan B videresendes fra A til M via relæerne. For overskuelighedens skyld er beskeddata forkortet således at B r3 angiver beskeden som r3 modtager fra r2. Indtil nu har vi ignoreret hvordan A og relæerne bliver enige om nøglerne til dekryptering af de modtagne beskeder. Vi kan forestille os at relæerne og klienter anvender asymmetrisk kryptering, hvor hvert relæ offentliggør sin offentlige nøgle (detaljerne omkring verifikation af ægtheden af en offentlig nøgle vil vi se bort fra i denne opgave). En klient kan så initielt bruge en offentlig nøgle til at kommunikere med et relæ uden at blive aflyttet. Asymmetrisk kryptering har dog den ulempe, at det er væsentligt langsommere end symmetrisk kryptering. Hvis der skal afsendes en serie af beskeder kan det derfor betale sig at bruge den asymmetriske kryptering til bilaterale forhandlinger med de enkelte relæer omkring en symmetrisk krypteringsnøgle. Disse symmetriske 2

3 r4 r4 k r4 (B M) r3 M (B) k M r1 r2 k r2 (B r3) r3 k r3 (B r4) r2 M r1 k r1 (B r2) A Figur 1: Eksempel på videresending af besked ved anonym datakommunikation krypteringsnøgler anvendes derefter til selve datatransmissionen. Der er altså i realiteten tale om at oprette en forbindelse til anonym datakommunikation mellem A og M. 2.1 Opgavens formål I skal i denne opgave designe og implementere et relæ til forbindelsesorienteret anonym kommunikation ved anvendelse af en kombination af asymmetrisk og symmetrisk kryptering. Alle kommunikerende enheder i systemet er relæer, hvilket vil sige at både afsender og modtager af en besked selv skal fungere som relæ. Der er to hovedpunkter i opgaven: Relæerne skal vedligeholde en liste over alle aktive relæer i systemet samt relæernes offentlige nøgler. Relæerne skal kunne oprette forbindelser til anonym kommunikation, sende og modtage beskeder via sådanne forbindelser, samt kunne nedlægge forbindelser. Relæerne skal implementeres i C/C++ og anvende TCP via Berkeley socket interfacet til kommunikation mellem relæerne. Bemærk at socket programmering i C/C++ anvender et andet API end Java eksemplerne i CN gør. Appendiks A er en introduktion til socket programmering i C/C++. Opgaven er lagt an på at I selv skal definere store dele af de nødvendige protokollers virkemåde og udformning. Dette betyder at en væsentlig del af arbejdet går ud på at fastlægge og dokumentere de krævede protokoller ud fra den til tider løse beskrivelse nedenfor. Dokumentationen af en protokol omfatter som minimum: En beskrivelse af alle beskedtyper i protokollen og deres indhold En tilstandsmaskine, der viser hvilke tilstande en protokol kan være i, og hvordan de forskellige hændelser kendt af protokollen (f.eks., modtagelse af en bestemt beskedtype) ændrer protokollens tilstand samt hvilke operationer der skal foretages som reaktion på hændelsen. CN kapitel 3 indeholder en række eksempler på tilstandsmaskiner til beskrivelse af protokoller. Disse tilstandsmaskiner skal danne grundlag for implementationen af protokollerne. 3

4 2.2 Vedligeholdelse af liste over aktive relæer For at kunne udvælge de relæer der skal indgå i en anonym forbindelse, skal et relæ kende de andre aktive relæers adresse samt offentlige nøgle, og relæerne skal derfor samarbejde omkring at vedligeholde en sådan liste. Det drejer sig i realiteten om at vedligeholde en form for rutningsinformation til oprettelse af forbindelser. For hvert relæ er det nødvendigt at kende relæets IP adresse og TCP port nummer samt dets offentlig nøgle. Når et relæ starter, skal det først generere et nøglepar til asymmetrisk kryptering. Derefter skal det opbygge en liste over eksisterende relæer, samt sikre at andre relæer får kendskab til det nystartede relæs adresse og offentlige nøgle. Hvis et relæ er alene, er det således tilstrækkeligt at generere nøgleparet. Er det derimod ikke alene, kontakter det et andet relæ for at starte opbygningen af listen over relæer. Ved løsning af opgaven kan dette eksisterende relæ angives af brugeren, der starter relæet, f.eks. ved hjælp af en parameter til relæet. Når kontakten er etableret, kan det nystartede relæ modtage en liste over eksisterende relæer i netværket fra det eksisterende relæ. Samtidig skal det nystartede relæ starte offentliggørelsen af sig selv som nyt relæ. Det er op til jer at udvikle en passende protokol til opbygning af listen samt offentliggørelsen af nye relæer. For at sikre at systemet kan understøtte et stort antal relæer skal denne offentliggørelse foretages på en måde, der sikrer at hver knude (inklusiv den nye knude) kun skal kommunikerer med et tocifret (base 10) antal relæer for hver offentliggørelse uanset antallet af relæer i systemet. Protokollen skal kunne håndtere at knuder frivilligt forlader systemet, samt at flere nye relæer starter samtidig. 2.3 Forbindelsesorienteret anonym datakommunikation Relæerne skal understøtte en protokol for forbindelsesorienteret anonym kommunikation mellem to relæer R 0 og R N, hvor forbindelsen etableres via N-1 mellemliggende relæer. Protokollen og implementationen skal tillade at N er vilkårlig stort, men I kan ved afprøvning af implementationen sætte N til 4. I det følgende vil vi skitsere de typer af beskedudvekslinger, der er nødvendige for at implementere denne protokol. Vi vil skelne mellem kontrolbeskeder, der bruges til administration af forbindelser og databeskeder, der indeholder de data, der skal sendes anonymt via en etableret forbindelse. Idet der kun er tale om en skitse, er beskedernes nøjagtige indhold og format ikke angivet Oprettelse af forbindelse En forbindelse oprettes mellem de to relæer R 0 og R N via N-1 mellemliggende relæer R 1 til R N 1. R 0 kan ikke tage direkte kontakt til relæerne R 1 til R N, idet dette ville afsløre R 0 s identitet. I stedet anvendes en trinvis udvidelse af forbindelsen via de mellemliggende relæer, således at forbindelsen først etableres til R 1, derefter udvides til R 2, og så fremdeles indtil forbindelsen når helt til R N. Som omtalt i indledningen skal protokollen anvende symmetrisk kryptering på den etablerede del af forbindelsen og asymmetrisk kryptering ved udvidelse af en forbindelse. Man vil således under selve oprettelsen af forbindelsen have en etableret del af forbindelsen, hvor der anvendes symmetrisk kryptering og et sidste led (det led forbindelsen udvides med) hvor der anvendes asymmetrisk kryptering. En forbindelse fra R 0 til R N etableres som følger: 1. R 0 udvælger N-1 relæer R 1 til R N 1 hvor N fastsættes af R 0. 4

5 2. for hvert relæ R i (hvor 0 < i <= N) genererer R 0 en symmetrisk nøgle SN i, der bruges til at kryptere kommunikationen til R i. 3. R 0 opretter en TCP forbindelse til R 1 og sender en kontrolbesked, krypteret med R 1 s offentlige nøgle ON 1, der fortælle at efterfølgende kommunikation vil blive krypteret med SN 1. R 1 kvitterer for kontrolbeskeden til R 0 krypteret med SN R 0 fortsætter med iterativt at forlænge forbindelsen via den etablerede del af forbindelsen. Efter at have oprettet delforbindelsen til R 1 konstrueres en kontrolbesked til R 2, der fortæller at beskeder fra R 1 vil være krypteret med SN 2. Denne kontrolbesked krypteres med R 2 s offentlige nøgle ON 2, og sendes indkapslet i en kontrolbesked til R 1, der fortæller R 1 at den skal forlænge forbindelsen ved oprette en TCP forbindelse til R 2 og derefter sende den indkapslede kontrolbesked til R 2. Kontrolbeskeden til R 1 er selvfølgelig krypteret med SN 1. R 2 kvitterer for oprettelsen af den næste del af forbindelsen ved at sende en kontrolbesked tilbage til R 1 krypteret med SN 2, og R 1 sender denne kontrolbesked videre til R 0 krypteret med SN 1. R 0 dekrypterer først med SN 1 og derefter med SN 2 og kan dermed se at endnu en delforbindelse er succesfuldt etableret. Således fortsættes indtil hele forbindelsen er etableret til R N. Skulle der undervejs opstå problemer med at et mellemliggende relæ ikke er tilgængeligt, erstattes dette relæ af et andet af R 0. Er R N ikke tilgængeligt, kan forbindelsen ikke oprettes i sin helhed, og den allerede etablerede del af forbindelsen skal nedlægges. Når forbindelsen til anonym kommunikation er etableret, vil der altså mellem hvert relæ i forbindelsen være etableret en TCP forbindelse, hvor der sendes data krypteret med en symmetrisk nøgle. I hver ende af TCP forbindelsen vil den være identificeret af et håndtag (eng.: handle), som entydigt identificere TCP forbindelsen i den givne relæproces. Figur 2 skitserer en mulig datastruktur for videresendelse. Et relæ modtager en besked på TCP forbindelsen med håndtag fh 1, og kan ved et opslag i en tabel over aktive forbindelser konstatere at beskeden er krypteret med den symmetriske nøgle SN 1, og at forbindelsen fortsætter via TCP forbindelsen identificeret af fh 2. Vi har ved oprettelse af forbindelsen en aktiv part og en passiv part, der begge er relæer. Den passive part skal altid være klar til at modtage nye forbindelser, i.e., man skal ikke udføre en eksplicit handling på den passive part for at en indkommende forespørgsel om oprettelse af en forbindelse accepteres. Det forholder sig heller ikke sådan, at der skal ske en sammensmeltning af forbindelser hvis to aktive parter forbinder til hinanden samtidig. Der skal kunne være etableret flere forbindelser i hver retning mellem to relæer Transmission af databeskeder Når først en forbindelse er etableret mellem to relæer R 0 og R N, kan R 0 sende en databesked B til R N ved at kryptere den med de symmetriske nøgler SN 1,..., SN N i omvendt rækkefølge. En databesked har altså ved afsendelse fra R 0 formen SN 1 (SN 2 (... SN N 1 (SN N (B))...)) Hvert af de mellemliggende relæer kan ud fra den TCP forbindelse hvorpå databeskeden modtages finde den nødvendige nøgle til dekryptering samt hvilken TCP forbindelse databeskeden skal videresendes på. R N kan ligeledes sende en databesked til R 0 ved at kryptere en databesked med SN N og derefter sende beskeden den modsatte vej i forbindelsen. De enkelte relæer på vejen vil kryptere 5

6 fh 0 fh 1 fh 2 fh 3 fh 4 fh 5 R 0 SN1 R 1 SN R 2 2 SN R 3 3 fh 1 fh 1 SN 1 fh 2 Figur 2: Eksempel på etableret forbindelse mellem R 0 og R 3 med to ekstra relæer R 1 og R 2 databeskeden med deres symmetriske nøgle, og derefter videresende databeskeden til det forudgående relæ. R 0 vil således modtage en databesked med samme kryptering som dem den selv afsender, og R 0 kan umiddelbart dekryptere databeskeden Afsendelse og modtagelse af databeskeder Indtil nu har vi undgået at diskutere, hvor databeskederne der sendes via den forbindelsesorienterede anonyme kommunikation kommer fra og hvor de havner på destinationsrelæet. Dette kræver specifikationen af en grænseflade mellem protokoldelen af relæet og brugeren af den anonyme kommunikation, i.e., en netværksapplikation. For at begrænse opgavens omfang skal en sådan grænseflade ikke implementeres. I stedet skal der i selve relæet indbygges en testtilstand, som tillader den part, der aktivt opretter forbindelsen, at sende en serie databeskeder, der returneres af modparten Nedlæggelse af forbindelse Når en forbindelse skal nedlægges er det tilstrækkeligt for R 0 at sende en kontrolbesked S gennem forbindelsen til R N, som kvitterer for S ved at nedlægge TCP forbindelsen til R N 1. Når det foregående relæ opdager at forbindelsen er nedlagt, kan det selv nedlægge næste TCP forbindelse i forbindelsen. Nedlæggelsen af TCP forbindelsen fungerer således som kvittering for modtagelsen af S. 2.4 Kryptering Ved implementationen af protokollerne er det ikke et krav at der implementeres algoritmer til symmetrisk og asymmetrisk kryptering/dekryptering. I stedet kan man foran en besked, der skal 6

7 krypteres, placere fire bytes der angiver en krypteringsnøgle. En dekryptering består derefter af at sammenligne disse fire bytes med den nøgle beskeden forventes krypteret med. Er de ens, kan beskedens klartekst fremskaffes ved at fjerne de fire bytes. Bemærk at der ved denne metode ikke er forskel på at symmetrisk og asymmetrisk kryptering, idet man i begge tilfælde sammenligner de fire bytes med krypteringsnøglen (dette under antagelse af at der ved asymmetrisk kryptering kun anvendes den offentlige nøgle til kryptering). Selve genereringen af nøgler kan således klares ved at fastsætte de fire bytes, f.eks. ved hjælp af tilfældige tal. Ved implementationen skal det dog tilstræbes at denne simulering af kryptering er indkapslet så den senere kan erstattes af rigtige krypteringsalgoritmer. 2.5 Håndtering af fejl Skulle et relæ blive nødt til at forlade netværket eller skulle relæet eller knuden gå ned, skal alle forbindelser gennem relæet nedlægges. Det er ikke nødvendigt at håndtere netværkspartitionering - mister et fungerende relæ kontakten til et andet relæ, kan det fungerende relæ således gå ud fra at det andet relæ er ophørt med at eksistere. 3 Implementation Implementationen skal som tidligere nævnt skrives i C/C++ og anvende Berkeley socket API et. Al kommunikation mellem relæer skal benytte TCP. Selve afviklingen af relæer kan foretages på DIKUs 1. dels Linux maskiner. Vær ved udvikling af relæet opmærksom på at I får fjernet alle processer inden I logger ud - brug eventuelt kommandoen zap. Implementationen af relæet skal bygges op over de tilstandsmaskiner, I udfærdiger for de to protokoller. Nedenfor er skitseret en mulig opbygning af hovedløkken for et sådant relæ. do { <vent på hændelse på aktive TCP forbindelser> if(<besked modtaget>) { switch(protokoltype) { case <rutning>: tilstandsmaskinerutning.hændelse(<besked er modtaget>, <besked indhold>); break; case <anonymkomm>: tilstandsmaskineanonymkomm.hændelse(<besked er modtaget>, <besked indhold>); break; } } else if(<ny TCP forbindelse>) { <accepter ny TCP forbindelse> <tilføj forbindelse til mængden af aktive TCP forbindelser> } else if(<timer udløbet>) { <behandl timerhændelser> } } while(true) 7

8 Når der skal ventes på aktivitet på mere end en TCP forbindelse kan man med fordel anvende enten poll eller select systemkaldet (se de elektroniske manualsider for en nærmere beskrivelse af poll og appendiks A afsnit 6.13 for select). Ved begge systemkald specificerer man de filhåndtag man vil overvåge aktiviteten på og de hændelser man er interesseret i (typisk om der er data klar til at blive modtaget eller om der er plads til at sende yderligere data). Tilstandsmaskinerne kan ligeledes opbygges med en central switch, der for en given hændelse udfører den passende serie af handlinger for en given kombination af hændelse og tilstand (se også figur 3.33 i CN). Det er muligt at afvikle hele relæet med en enkelt tråd uden væsentlig forringelse af relæets reaktionstid på nye hændelser, hvis behandlingen af en hændelse ikke blokerer (hvis enkelte systemkald kan blokere bør I argumentere for at dette sker yderst sjældent). Eksempelkode til etablering af TCP forbindelser forefindes i Appendiks A. Bemærk at ikke hele appendikset er relevant, men især afsnit 6.5 og TCP eksemplerne i afsnit 6.6 er gode at læse. 4 Rapporten Det udførte arbejde skal beskrives og dokumenteres i en rapport. Kravene til rapporten er: 1. Omfanget må maksimalt være 30 sider, eksklusiv bilag. Der lægges vægt på, at rapporten er velstruktureret og præcis. 2. Indledningen skal indeholde en kort statusrapport, der klargør i hvilken udstrækning opgaven er løst. 3. Rapporten skal indeholde en analyse der fastlægger de enkelte protokoller. For rutningsprotokollen er følgende overordnede problemstillinger som minimum relevante: hvordan sikres at alle relæer får kendskab til et nyt relæ under hensyntagen til at flere relæer kan koble sig på samtidig forskellige steder og relæer kan forlade systemet. hvordan distribueres information om et nyt relæ så systemet kan skalere til meget store antal relæer. For den forbindelsesorienterede anonyme kommunikation er følgende problemstilling som minimum relevant: Hvordan håndteres utilgængelige relæer ved forbindelsesetablering samt nedbrud af relæer ved etablerede forbindelser. Hvordan håndteres flere samtidige forbindelser Endvidere skal den nøjagtige udformning af protokollerne dokumenteres. Som tidligere beskrevet omfatter dokumentationen af en protokol omfatter som minimum: En beskrivelse af alle beskedtyper i protokollen og deres indhold En tilstandsmaskine, der viser hvilke tilstande en protokol kan være i, og hvordan de forskellige hændelser kendt af protokollen ændrer protokollens tilstand. CN kapitel 3 indeholder en række eksempler på tilstandsmaskiner til beskrivelse af protokoller. 4. Rapporten skal indeholde en kort beskrivelse af relæets funktioner og struktur. 8

9 5. Der skal dokumenteres ved hjælp af en afprøvning i hvilket omfang protokollerne i det udviklede relæ overholder de specifikationer, der er fastlagt i opgaveteksten og rapporten. 6. Rapporten skal kort beskrive forenklende antagelser og begrænsninger. 7. Vær opmærksom på at afleverede kildetekster skal være letlæseligt. Vær især opmærksom på at LATEX ikke respekterer tabuleringer, hvilket kan betyde at kildeteksterne bliver vanskelige at læse. Rapporten behøver ikke at at omfatte en brugsvejledning. 9

10 A Fotokopi af siderne 258 til 331 fra bogen Unix Network Programming af W. Richard Stevens (ISBN ) udgivet i 1990 af Prentice Hall De følgende sider er kopieret i ca. 130 eksemplarer. 10