Filbaseret piratkopiering Jens Emil Gydesen, Mathias Ormstrup Bjerregaard Mikkel Alexander Madsen, Nichlas Bo Nielsen Sander Jespersen & Ulf Gaarde Simonsen 19. december 2011 Forord Dette P1 projekt er udarbejdet af 6 datalogistuderende p˚ a Aalborg Universitet p˚ a første semester. Projektet startede den 17. oktober 2011 og blev afleveret den 20. december 2011. Projektet er udarbejdet ud fra et tema der hed: “Fra eksisterende software til modeller” med form˚ al at vi studerende opn˚ ar færdigheder i problemorienteret projektarbejde i en gruppe. Et krav til P1 var at der udover en rapport skulle udvikles et program samt laves en procesanalyse. Kildekoden til programmet kan ses i bilaget. Udover kildekoden er der en ordliste og et projektforslag. Programmet er udviklet i C, som var et krav til projektet. Ud fra et projektkatalog, udgivet af vejledere, valgte vi emnet “Om at bekæmpe piratsoftware”. Vores rapport er opdelt i kapitler med dertilhørende underafsnit. Der vil undervejs være kildehenvisninger til brugte kilder. Kilderne er markeret med tal som henviser til litteraturlisten. Alle kilders webadresser fungerede ved projektaflevering den 20. december 2011. Bilaget vil kunne findes bagerst i rapporten. Rapporten er udviklet i LATEX. Vi vil gerne takke vores hovedvejleder Hans H¨ uttel og vores bivejleder Jens Fisker Kaae for vejledning. Derudover retter vi en tak til Erik Ramsgaard Wognsen som har hjulpet os med at forst˚ a princippet bag signering af filer. Underskrifter Jens Emil Gydesen Mathias Ormstrup Bjerregaard Mikkel Alexander Madsen Nichlas Bo Nielsen Sander Jespersen Ulf Gaarde Simonsen Det Teknisk-Naturvidenskabelige Basis˚ ar Datalogi Strandvejen 12-14 Telefon 96 35 97 31 Fax 98 13 63 93 http://tnb.aau.dk Titel: Filbaseret piratkopiering Tema: Fra eksisterende software til modeller Projektperiode: P1, efter˚ arssemesteret 2011 17. oktober til 20. december Projektgruppe: B220 Deltagere: Jens Emil Gydesen Mathias Ormstrup Bjerregaard Mikkel Alexander Madsen Nichlas Bo Nielsen Sander Jespersen Ulf Gaarde Simonsen Vejledere: Hovedvejleder: Hans H¨ uttel Bivejleder: Jens Fisker Kaae In this report, we looked into the world of computer piracy. We analysed the problem by looking at the extent of piracy, the reasons behind it and the way in which it affects the concerned parties. We made a solution for a subproblem, how to make a timelimited file, based on the Abstract: research of the analysis. Afterwards we researched encryption, hashing and signatures for our algorithm. This was used for our application which would put a timelimit on an executable file. The application is made in the programming language C. We finish the report with a conclusion and a discussion. Oplagstal: 10 Sidetal: 83 Bilagsantal og –art: 3; Kildekode ordliste, projektforslag Afsluttet den 20. december - 2011 Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) m˚ a kun ske efter aftale med forfatterne. Indhold 1 Indledning 1.1 Omfang af piratkopiering . . . . . 1.2 Aktører . . . . . . . . . . . . . . 1.2.1 Piratkopister . . . . . . . 1.2.2 Udbydere . . . . . . . . . 1.3 Er der tale om et problem, som er 1.4 Datalogiske løsningsmuligheder . 1.5 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . nødvendigt at . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . løse? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 5 5 7 8 10 12 2 Kryptografiske primitiver 13 3 Anvendte kryptografiske primitiver 3.1 Hashing . . . . . . . . . . . . . . . 3.2 RSA . . . . . . . . . . . . . . . . . 3.2.1 Eksempel p˚ a RSA . . . . . . 3.3 Signering . . . . . . . . . . . . . . . . . . . 15 15 18 19 20 . . . . . . . . 21 21 22 25 25 26 33 33 37 4 Implementering af algoritmen 4.1 Analyse . . . . . . . . . . . . . 4.2 Algoritmen . . . . . . . . . . . 4.3 Implementation . . . . . . . . . 4.3.1 Main . . . . . . . . . . . 4.3.2 void *thread . . . . . . . 4.3.3 Oprettelse af testversion 4.3.4 Nøglefilen KF il . . . . . 4.4 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Konklusion 43 5.1 Projektets resultater . . . . . . . . . . . . . . . . . . . . . . . 43 5.2 Vurdering af løsning . . . . . . . . . . . . . . . . . . . . . . . 44 5.3 Perspektivering . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3 Literature I Kildekode 46 51 A Applikationen 52 B Applikation eksempel 57 C Kildekode 59 D Kode til generering af nødvendige filer 64 II 68 Ordliste E Ordliste 69 III 71 Projektforslag F Projektforslag 72 Figurer 4.1 4.2 4.3 4.4 4.5 Flowchart af Første test . Anden test . Tredje test . Fjerde test . applikationen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 38 40 41 42 Tabeller 1.1 1.2 1.3 1.4 Konsolenheder solgt i 2010 . . . . . . . . . . Forbig˚ aet indtjening . . . . . . . . . . . . . Oversigt over BNP i 24 lande . . . . . . . . Højeste og Laveste Piratkopieringsrate i 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 4 3.1 3.2 Binære operatorer . . . . . . . . . . . . . . . . . . . . . . . . . 16 Sikkerhed i hashfunktioner . . . . . . . . . . . . . . . . . . . . 17 Kapitel 1 Indledning Fil-baseret piratkopiering er i stor grad, blevet et internationalt emne og danner grundlag for megen diskussion. Piratkopiering er primært et problem, for underholdnings- og software industrien, og derfor indebærer piratkopiering ofte overtrædelser af loven om ophavsret. Det skal dog siges, at ophavsretten kan variere fra land til land. Det er utrolig nemt at piratkopiere, det kræver blot en computer og internet s˚ a kan man f˚ a adgang til meget materiale. Ophavsret er en juridisk rettighed, der beskytter kreative værker for at blive udgivet uden tilladelse af ophavsret ejeren. I bund og grund giver ophavsret ejeren eneret, til at fremstille eksemplarer samt at udgive det p˚ agældende materiale. Dette er den danske ophavsretslov §1: “§1. Den, som frembringer et litterært eller kunstnerisk værk, har ophavsret til værket, hvad enten dette fremtræder som en i skrift eller tale udtrykt skønlitterær eller faglitterær fremstilling, som musikværk eller sceneværk, som filmværk eller fotografisk værk, som værk af billedkunst, bygningskunst eller brugskunst, eller det er kommet til udtryk p˚ a anden m˚ ade. Stk. 2. Kort samt tegninger og andre i grafisk eller plastisk form udførte værker af beskrivende art henregnes til litterære værker. Stk. 3. Værker i form af edb-programmer henregnes til litterære værker.” [2] Vi ser fra ovenst˚ aende juridiske grundlag, at det ikke er lovligt at kopiere andres værker i Danmark. Dette indebærer alts˚ a kopiering af software, spil, e-bøger, musik, film og meget mere. M˚ aden som man har forsøgt at bekæmpe piratkopiering p˚ a, har vist sig at 1 KAPITEL 1. INDLEDNING være ineffektiv og problemet er stadig stigende. Vi har i dette projekt valgt en anderledes tilgang til problemet. Det har vist sig, at der bliver piratkopieret for at prøve materiale af, dvs. at her er en mangel og vi har forsøgt at skabe en løsning til dette delproblem. For at løse dette problem, vil vi i rapporten dække hvordan dette er blevet gjort samt dække teorien bag det.. 1.1 Omfang af piratkopiering I dette afsnit vil der blive redegjort for omfanget af problemet. Vi har undersøgt de forskellige markeder og fundet tal fra disse. Bemærk at tallene er estimeringer foretaget af eksperter inden for omr˚ adet. Siden 1999 er mængden af musik, der blev solgt i USA næsten halveret fra et ˚ arligt salg p˚ a $14,6 milliarder til $7,7 milliarder. Det antages at der fra 2004 til 2009, blev hentet mere end 30 milliarder sange ved fil deling. Derudover har NPD group inc. konkluderet, at de amerikanske borgere kun har betalt for 37% af det musik de lytter til [33]. BSA er en amerikansk organisation, som repræsenterer mange store softwarevirksomheder [10]. De har lavet en større gennemg˚ aende undersøgelse, hvor de bl.a. skriver at 41% af alt software er anskaffet ulovligt, hvilket svarer til en mistet profit p˚ a $53 milliarder [11]. Markedet for spil dækker mange slags konsoller samt computere. Konsoller er specifikt designet til at spille p˚ a, og derfor er det dem, som vil blive undersøgt. For at f˚ a et overblik over konsolmarkedet p˚ a verdensplan, vises en tabel med antallet af solgte enheder i 2010, af de mest kendte og nyeste enheder. Tallene for Sonys konsoller i Tabel 1.1, er blev lavet gennem udregninger fra Sonys regnskab. Deres regenskabs˚ ar g˚ ar fra 31. marts til 31. marts ˚ aret efter. Derfor blev tallet fundet ved at tage de tre første kvartaler i ˚ ar 2010, samt det sidste kvartal i 2009, hvorefter de lægges sammen [36]. Dette var ikke muligt for Nintendos enheder, da der ikke er oplyst kvartaler uden for det nuværende regnskabs˚ ar, af denne ˚ arsag blev de tal, som stod direkte, sat ind i Tabel 1.1 under regnskabs˚ aret for ˚ ar 2010 og det samlede salg [29]. Den sidste store producent af konsoller er Microsoft, og tallene for deres Xbox 360 blev regnet ud p˚ a samme m˚ ade som Sonys tal [27]. Alle tallene i Tabel 1.1 er omregnet til millioner, hvis de er oplyst anderledes i kilden. -2- 1.1. OMFANG AF PIRATKOPIERING Enheder solgt i 2010 Nintendo DS Nintendo Wii Sony Playstation 3 Sony Playstation Portable Microsoft Xbox 360 27,1 20,5 14,4 7,7 10,4 Enheder solgt siden frigivelse Nintendo DS 149,0 Nintendo Wii 89,4 Sony Playstation 3 55,5 Sony Playstation Portable 38,9 Microsoft Xbox 360 35,2 Tabel 1.1: Konsolenheder solgt i 2010 [36] [29] [27] Som der kan ses i Tabel 1.1, s˚ a har de to h˚ andholdte konsoller tilsammen 187,9 millioner enheder solgt ud af de sammenlagte 368 millioner. Det er lidt mere end 50% af markedet, og derfor vil undersøgelsen af spil, blive yderligere afgrænset til kun at indeholde de to mest populære h˚ andholdte enheder. Den ene er fra Nintendo, kaldet Nintendo DS, og den anden er fra Sony, den hedder Playstation Portable (PSP). Ifølge en japansk undersøgelse, som er lavet i samarbejde med et af Tokyos universiteter(Baba Lab), er spil til Nintendos DS og Sonys PSP blevet kopieret for $49,1 milliarder i perioden 2004 til 2009. De kom frem til dette, ved at tælle alle samlede antal downloads for top 20 spil til disse enheder, p˚ a de mest populære downloadsider. Herefter multiplicerede de det tal med salgsprisen og fire. Deres tal er antagelser for downloads i Japan og at de stod for 25% af alle downloads af disse spil [16]. Ogs˚ a filmindustrien mærker piratkopiering. Den samlede filmindustri (inkl. biografer og filmudlejning) g˚ ar iflg. Tabel 1.2 glip af en ˚ arlig indtægt p˚ a $18,2 milliarder. [25]. I Tabel 1.3 og Tabel 1.4, listes der en række af lande, s˚ aledes at der kan ses Forbig˚ aet indtægt i milliader Software $53 Konsol(DS og PSP) $9,8 Musik $0,6 Film $18,2 Tabel 1.2: Forbig˚ aet indtjening hvilke lande, som er fattige, og hvordan det hænger sammen med mængden af piratkopierede filer. Den første Tabel 1.3 er landets BNP per indbygger Tabel 1.4. Den anden er raten af piratkopiering. -3- KAPITEL 1. INDLEDNING Georgien Zimbabwe Bangladesh Moldova Yemen Armenien Venezuela Hviderusland Libyen Aserbajdsjan Indonesien BNP pr indbygger i 2010 $2,620 USA $595 Japan $673 Luxembourg $1,631 New Zealand $1,130 Australien $2,996 Østrig $13,451 Sverige $5,765 Belgien $9,957 Finland $5,647 Schweiz $2,946 Danmark $47,184 $43,137 $108,921 $29,352 $42,131 $44,863 $48,832 $42,969 $44,522 $66,934 $55,988 Tabel 1.3: Oversigt over BNP i 24 lande [4] De navne og tal der er markeret med fed, er tal fra 2009 da tal fra 2010 ikke var tilgængelige. Højeste Piratkopieringsrate Georgien 93% Zimbabwe 91% Bangladesh 90% Moldova 90% Yemen 90% Armenien 89% Venezuela 88% Hviderusland 88% Libyen 88% Aserbajdsjan 88% Indonesien 87% Laveste Piratkopieringsrate USA 20% Japan 20% Luxembourg 20% New Zealand 22% Australien 24% Østrig 24% Sverige 25% Belgien 25% Finland 25% Schweiz 26% Danmark 26% Tabel 1.4: Højeste og Laveste Piratkopieringsrate i 2010 [12] Som der kan læses ud fra Tabel 1.3 og Tabel 1.4, er piratkopiering i højere grad udbredt i de fattige lande, frem for lande der er bedre stillet. De fattige lande vil have meget svært ved at f˚ a r˚ ad, til at købe professionelt og lovligt software. Prisen for software i de fattige lande er ikke tilpasset lønniveauet, -4- 1.2. AKTØRER derfor kan software, som kan betales ud af en dansk dagløn, tage en uge eller mere at f˚ a r˚ ad til [15]. Nogle indbyggere i fattige lande, tjener helt ned til f˚ a hundrede dollars om ˚ aret [5]. Løsningen for folk der skal bruge et stykke software, kan derfor være at benytte sig af en piratkopi, for at f˚ a det nødvendige software som opfylder deres behov [15]. Piratkopiering kan desuden ogs˚ a være med til at skabe monopol [39]. Vi kan f.eks. opstille scenariet af en studerende, der har brug for et billedredigeringsværktøj som Adobe Photoshop CS5. Dette koster $699 [7]. Det er mange penge, at skulle bruge for de fleste studerende og for nogen helt umuligt. I stedet vil personen m˚ aske vælge at piratkopiere produktet for at f˚ a det gratis. Forestiller man sig, at piratkopiering ikke eksisterede og personen virkelig havde brug for et alternativt produkt, med samme funktionalitet og til en mindre pris, s˚ a ville han i alt sandsynlighed (det antages at personen ville vælge det billigere program, hvis det har samme funktionalitet) købe en konkurrents produkt. P˚ a denne m˚ ade fremmes monopolen af dette produkt. Det samme kan kan være gældende for Microsoft Windows. Hvis alle var tvunget til at betale, ville Windows da være det største Operativ system? Eller ville en anden konkurrent være mere udbredt, som f.eks. Linux? Efter at være præsenteret for omfanget af piratkopiering, er det blevet tydeliggjort at problemet er eksisterende. Der er alts˚ a et tab i indkomst som virkning af problemet, dette er penge som ikke er blevet tjent, fordi produktet er blevet piratkopieret og ikke købt. 1.2 Aktører Der er tre primære aktører inden for emnet. Den første af disse er piratkopisterne, som er dem der uploader eller downloader filer ulovligt fra internettet. Den anden er udbyderen, det er denne aktør, som skal tjene penge p˚ a salg af de produkter, som de ejer rettighederne til. Den sidste af de tre aktører er forbrugeren, men de vil ikke blive undersøgt nærmere, da forbrugeren ikke er direkte indblandet i problemet. 1.2.1 Piratkopister Der findes forskellige slags piratkopister, de kan deles op i mange underkategorier. Der er to slags piratkopister, der vil blive undersøgt nærmere, disse er uploadere og downloadere. Derudover er der ogs˚ a dem som kopierer over p˚ a -5- KAPITEL 1. INDLEDNING fysiske enheder i form af CD’er eller DVD-skiver. En af hoved˚ arsagerne til at piratkopiering af filer finder sted, er at det er gratis. Dette er en attraktiv egenskab, specielt n˚ ar mange finder det dyrt at skaffe sig materialet lovligt. Derudover er der ogs˚ a opst˚ aet en hvis social accept af at downloade ulovlige filer fra internettet. En anden meget vigtig ting som motiverer piratkopiering, er at prøve et produkt før man køber det. Friheden til gratis at prøve noget og derefter købe det, kan alts˚ a ogs˚ a drive en person til at piratkopiere [9]. Det er ikke uden konsekvenser, at hente eksempelvis software eller musik p˚ a internettet. Det hentede materiale kan være defekt pga. f.eks. manglende opdateringer. Manglende opdateringer kan give mulighed for sikkerhedshuller i systemet og kan dermed give let adgang til vira eller identitetstyveri. Der vil ikke være support eller gives garanti fra udviklere, som beskytter piratkopisten hvis produktet laver skade p˚ a maskinen, der ikke kan repareres [14]. Et andet problem er den risiko der løbes ved at bryde loven, hvis man fanges i det kan man forvente straf. Hvilke strategier benytter piratkopister sig af ? I dette afsnit redegøres der for, hvordan piratkopister distribuerer deres materiale. Dette er vigtigt at vide, for at kunne nærme sig løsninger, som kan gøre det mere kompliceret at piratkopiere eller stoppe problemet helt. Der findes udgivelsesgrupper som udgiver piratkopieret materiale. For at en gruppe kan udgive et stykke software, skal der først være en leverandør, der skaffer materialet. Dette er dog ikke altid muligt og gruppen skal vente p˚ a at materialet bliver udgivet. Derefter skal der foretages en reverse engineering p˚ a dette stykke software, ofte kaldt cracking. Ved cracking ændrer piratkopisterne ved en eller flere filer, for at gøre det muligt at g˚ a udenom den mulige beskyttelse programmet har, f.eks en cd-nøgle. Dette arbejde foretages af en cracker, som ogs˚ a er en del af gruppen. Efter at materialet er skaffet og cracket, skal det blot pakkes sammen og udgives, samme forhold gør sig gældende for spil. Ved musik og film er det lidt anderledes. Materialet skal først udgives af et pladeselskab, eller andet og kan derefter ekstrakteres og derefter udgives[14]. Det udgivne materiale bliver derefter distribueret. To eksempler p˚ a udgivere er aXXo [8], som er en af de mest kendte film piratkopister og Razor1911 [32], som er en gruppe der bl.a. cracker spil. BitTorrent protokollen kan f.eks. bruges til at dele materialet. Det væsentlige ved BitTorrent protokollen er, at alle deltagere i torrent-filen kan have en eller flere dele af det samlede data og man kan hente sm˚ a dele af det samlede data fra alle som har det, alts˚ a en sværm af data uden en direkte vært for materialet, hvilket gør det svært at spore [13]. -6- 1.2. AKTØRER Et sidste notat der bør nævnes om piratkopisterne er at grupperne meget ofte opfordrer til at købe produktet, hvis man kan lide det. Dette sker i form af en NFO(info) fil hvor der f.eks. kan st˚ a: “Support the software companies. If you play this game BUY it.” [14]. 1.2.2 Udbydere Udbyderes primære opgave er at sælge produktet. Deres arbejde kan ogs˚ a omfatte at stoppe piratkopiering, for at undg˚ a tabt indkomst. Udbyderne vil gerne stoppe problemet, fordi de bliver snydt for penge, n˚ ar de produkter de vil sælge, bliver ulovligt kopieret af piratkopister. Vi har set tidligere i Afsnit 1.1, at omfanget af piratkopiering er et stort problem. Da mange penge tabes er der en tydelig grund til at udbyderne vil bekæmpe dette. Hvilke strategier benytter udbyderne sig af ? En af de ting mange udbydere vælger at gøre, er at tilføje et Digital Rights Management(DRM) system til deres fysiske produkter. Der findes forskellige DRM systemer, men deres hovedform˚ al er adgangskontrol af filer [24]. Et eksempel p˚ a brug af DRM er Ubisofts spil Assassins Creed. Ubisofts DRM til dette spil gik ud p˚ a at n˚ ar brugeren installerede spillet, var det ikke alle filerne der var med i installationen. Man skulle derimod have en internet forbindelse, og hver gang man startede spillet, ville der blive hentet nogle filer til spillet, som gjorde det funktionelt [41]. Ofte opretter rettighedshavere organisationer der har til form˚ al at beskytte ophavsretten p˚ a objekter der er i deres felt. F.eks blev BSA nævnt tidligere, og i Danmark har vi RettighedsAlliancen, som har hele den danske musik- og filmbranche bag sig i deres form˚ al med at beskytte ophavsretsholdernes rettigheder. RettighedsAlliancen hed tidligere Anti-Piratgruppen hvor de aktivt sagsøgte folk, der havde brudt ophavsretten, ved enten at downloade eller dele filer med andre. Dette forehavende blev stoppet, da det viste sig, at det var stortset umuligt at dømme privatpersoner uden tilst˚ aelse [34]. Den internationale Motion Picture Association(MPA) st˚ ar blandt andet for at lave kampagner der fortæller folk at piratkopiering er tyveri [21]. -7- KAPITEL 1. INDLEDNING 1.3 Er der tale om et problem, som er nødvendigt at løse? Vi har nu set p˚ a omfanget af problemet og analyseret de indblandede aktører. I dette afsnit vil problemet blive analyseret nærmere og der vil argumenteres for hvorfor problemet skal løses. Et af hovedargumenterne der bliver brugt i emnet piratkopiering er at det er tyveri [21]. Motion Picture Association of America(MPAA) bruger ogs˚ a udtrykket tyveri omkring alle former for piratkopiering [28]. Men ser man p˚ a den danske straffelov §276, er piratkopiering ikke er tyveri, da en fil p˚ a en computer ikke er en rørlig ting. ”§276. For tyveri straffes den, som uden besidderens samtykke borttager en fremmed rørlig ting for at skaffe sig eller andre uberettiget vinding ved dens tilegnelse. Med rørlig ting sidestilles her og i det følgende en energimængde, der er fremstillet, opbevaret eller taget i brug til frembringelse af lys, varme, kraft eller bevægelse eller i andet økonomisk øjemed.” [6] Piratkopiering er ogs˚ a blevet et politisk emne, og der er et ønske om at ændre ophavsretsloven. Der er blevet formet et politisk parti, hvis hovedm˚ al handler om fildeling og beskyttelse af privatlivet. Dette parti har f˚ aet navnet Piratpartiet. Dette politiske projekt startede i Sverige og partiet stillede op til Europa Parlamentets valget i 2006, men kom ikke ind. De forsøgte igen i 2009 og denne gang fik de 7% af de svenske stemmer, hvilket svarer til et mandat. Der blev i mellemtiden oprettet et tysk parti, med samme navn og en politik som minder meget om det svenske søsterpartis. Dette parti stillede ogs˚ a op i 2009, men fik ikke nok tyske stemmer til at f˚ a nogle mandater. I 2010 var der valg til den svenske riksdag, men der kom Piratpartiet ikke ind, da det kun fik 0.76% af stemmerne, det samme skete for piratpartierne i England og Frankrig, som ikke kom ind i deres respektive parlamenter. I 2011 var der landdagsvalg i Berlin og der stillede det tyske Piratparti op og fik et resultat der overraskede alle de politiske kommentatorer og partiet selv. De fik 8.9% af stemmer hvilket svarer til 15 mandater og dermed fik de ogs˚ a skaffet sig indflydelse, da de valgte at støtte den siddende leder og forlænge hans periode. Netop dette valgresultat mener parties leder er rigtigt vigtigt for piratpartier verdenen over, da det kan starte en kædereaktion af valgresultater, som giver pladser til de andre partier i de forskellige landes regeringer. -8- 1.3. ER DER TALE OM ET PROBLEM, SOM ER NØDVENDIGT AT LØSE? ”Det er en af den slags nøglebegivenheder, der fører til, at nye piratpartier bliver stiftet i andre lande og f˚ ar flere medlemmer og vælgere i andre lande. S˚ a snart folk hører, at piratpartiet er blevet valgt ind i Berlin, kan det tænkes, at folk eksempelvis overvejer at stemme p˚ a dem i Tjekkiet” - Fabio Reinhardt [20] Der findes ogs˚ a et dansk piratparti, men dette har ikke haft ret stort held i forhold til det tyske og svenske. De fik ikke samlede nok underskrifter til at kunne stille op til det danske folketingsvalg i 2011, men de fulgte de danske politikere tæt, hvor de gav r˚ ad og tips til hvem der var bedst at stemme p˚ a set med en fildelers øjne i forhold til ophavsretsloven [31]. Der er ogs˚ a en del der bruger piratkopiering til at teste produktet før de køber det, som en slags prøve, for at undg˚ a at betale for noget, som de m˚ aske ikke kan lide. Der er mange programmer der ikke giver mulighed for at prøve det, før man giver penge for det. Det samme gælder for film og musik. Bliver der downloadet et par numre fra et album vil personen der har downloadet det kunne afgøre om albummet er værd at betale for. Det sker at der kun er f˚ a numre p˚ a et album, som en forbruger ønsker at høre og derved kan personen blive skuffet, hvis han har købt hele albummet og føler sig snydt. Et andet eksempel er hvis det er en helt ny kunstner, s˚ a er chancen for at man køber et album derfra ganske lille, eftersom man ikke kender til det. Downloader man det første album kan det ske, at man gerne vil købe det næste, hvad end ens begrundelse til det er (støtte kunstneren, etisk korrekthed osv.). Film er dog lidt anderledes, da det ikke er sikkert at man vil se filmen igen efter første gang og kan derfor ikke betragtes som en prøve ligesom spil, software eller musik. Bill Gates, tidligere CEO af Microsoft, udtalte i 1998 følgende: ”As long as they are going to steal it, we want them to steal ours. They’ll get sort of addicted, and then we’ll somehow figure out how to collect sometime in the next decade” - Bill Gates [17] Der er en konstatering omhandlende problemet. Skal piratkopiering foreg˚ a skal det helst være deres produkter der bliver hentet. Microsoft er dog en gigantisk virksomhed, men det er ikke kun dem der fører denne holdning. LogMeIn er en mindre virksomhed som lider af det samme problem, som Microsoft ang˚ aende piratkopiering, deres chief executive officer(CEO) har den samme holdning til problemet: -9- KAPITEL 1. INDLEDNING “If people are going to steal something, we sure as hell want them to steal our stuff” - Michael Simon [23]. Der kan konkluderes at for en udbyder af denne slags, er der stadig profit i et piratkopieret produkt, selv for et mindre firma, de vil dog stadigvæk gerne have at man køber produktet frem for ulovlig kopiering. Markus Persson, som er udvikler af spillet Minecraft, har givet udtryk for at piratkopiering kan være en form for reklame, der kan skabes potentielle nye kunder ved at ordet spreder sig mellem venner og bekendte [30]. Det samme gør sig gældende ved andre brancher, den tabte indkomst kan stadig tillægges en værdi i form af gratis omtale. Selvom der m˚ aske er mindre tab ved salg, s˚ a vil et større og bedre rygte kunne indbringe flere penge igennem f.eks. deres næste film, merchandise, koncerter, og andet. Der er rig mulighed for at piratkopiering kan hjælpe med at promote dem og derved give dem flere penge end de hypotetisk har mistet. 1.4 Datalogiske løsningsmuligheder I denne sektion er nogle af vores overvejelser, med hensyn til løsning af et delproblem inden for emnet. Dette er overvejelser, som er grundlag for vores løsningsmodel. Disse vil ikke begrundes yderligere. Overordnet set har vi kigget p˚ a disse muligheder: • Vandmærkning af filer • Fil slitage • Fil med begrænset antal brug • Tidsbegrænset brug af filer Vandmærkning af filer Vandmærkning af filer kan forst˚ as og gøres p˚ a to m˚ ader. Den ene m˚ ade er at mærke filerne i koden, s˚ aledes at de ville kunne blive genkendt ved at tjekke om det er tilstede, alts˚ a ligesom et fysisk vandmærke. Den anden m˚ ade er direkte vandmærkning af digitale film s˚ a der er et synligt vandmærke imens man ser filmen. En datalogisk løsning inden for dette problem ville være at finde ud af hvordan der sørges for at et vandmærke i koden p˚ a en fil ikke følger med hvis der sker en uautoriseret kopiering af filen, og derved sørge for at det er muligt at - 10 - 1.4. DATALOGISKE LØSNINGSMULIGHEDER tjekke filen for uautoriseret kopiering. Det synlige vandmærke skal dog følge med i en kopiering, s˚ a man kan se at filmen eller billedet er kopieret. Fil slitage Konceptet bag slitage p˚ a en fil, er at sammenligne med fysisk slitage. Dette er en ide som er svær at implementere. Et eksempel p˚ a hvordan dette kunne gøres: I en e-bog kunne der f.eks. fjernes ord over tid og i musik eller film kunne kvaliteten forringes. Fil med begrænset antal brug Konceptet bag denne ide er tilsvarende en prøveversion til et stykke software, forskellen er blot at man har fuld adgang til det p˚ agældende materiale, dog med det forbehold at det kun kan bruges et begrænset antal gange. Tidsbrænset brug af filer Dette minder om begrænset antal brug, dog med den fordel at det er baseret p˚ a tid og ikke de antal gange, som brugeren har ˚ abnet filen. Dette forhindrer at brugeren ikke bare kan holde filen ˚ aben og dermed bruge det ubegrænset. - 11 - KAPITEL 1. INDLEDNING 1.5 Problemformulering P˚ a baggrund af de overvejelser og delkonklusioner, der er arbejdet med i problemanalysen, skal problemet afgrænses og en konkret problemstilling findes. Der kan ud fra problemanalysen konkluderes, at filbaseret piratkopiering, som helhed, er for stort et problem, til at det kan løses med vores ressourcer, og vi vil derfor fokusere p˚ a at f˚ a en del af problemet løst, ved at løse et delproblem inden for emnet. Der er blevet set p˚ a hvordan at piratkopisterne opfører sig og hvad de ønsker af produkter, som har en effekt p˚ a deres holdning til piratkopiering. Der er fundet ud af i Afsnit 1.2.1, at folk ønsker at kunne prøve hele produktet, inden at de bestemmer sig for, om det er pengene værd at købe det. Hertil kan man afgrænse problemet til et delproblem, som er prøveversioner i en afgrænset tidsperiode. Det vil give folk muligheden for at teste produktets potentiale inden der tages stilling til, om produktet er pengene værd. Hvis brugeren skal have mulighed for at kunne afprøve et produkt vil det, hvis man ser datalogisk p˚ a det, være et spørgsm˚ al om, hvordan man kan lave en tidsbegrænsning af et produkt. For at brugeren ikke skal have mulighed for at ændre i det tidsbegrænsede produkt, skal der være en form for beskyttelse af den tidsbegrænsende applikation. Efter afgrænsningen ønsker vi at besvare p˚ a følgende datalogiske spørgsm˚ al: Hvordan laver man tidsbegrænsning af filer og hvordan sørger man for, at tidsbegrænsningen ikke kan brydes eller p˚ a anden m˚ ade ændres? Krav til produkt: Der opstilles nogle krav til selve udførelsen af projektets produkt. Den tidsbegrænsende applikation, skal skrives i programmeringssproget C. Applikationen skal tælle tiden, der er brugt i den gældende fil. N˚ ar tiden overskrider den maksimale mængde af tid man m˚ a bruge filen, skal den lukke filen, med en p˚ amindelse om at filen lukkes, sammen med applikationen. Applikationen skal ogs˚ a afholde filen fra at ˚ abne, hvis det har overskredet den maksimale tid. Dertil skal der tilføjes en sikkerhed p˚ a vores applikation, s˚ a det ikke er muligt for brugeren at komme udenom tidsbegrænsningen og derved gøre vores produkt ubrugeligt. Vi vælger at fokusere p˚ a at udvikle en applikationen, der tidsbegrænser et eksternt program, men princippet bag løsningen vil fungere med andre medier, s˚ asom film og musik. - 12 - Kapitel 2 Kryptografiske primitiver I dette kapitel vil de kryptografiske primitiver forklares. Kryptering er meget vigtig i forhold til sikkerhed i dag. Der bliver sendt alle mulige former for person-følsomme informationer over internettet. Hvis ikke det var for kryptering, ville alle disse informationer være let tilgængelige for uvedkommende. Kryptering g˚ ar ud p˚ a at gøre alle disse informationer ulæselig for alle udover de intentionelle modtagere. Hvis man tager udgangspunkt i en besked M ,en kryptering E, samt en dekryptering D vil man kunne beskrive kryptering s˚ aledes: M + E → E(M ) (2.1) E(M ) + D → M (2.2) Hvis beskeden bliver krypteret vil den være ulæselig. Dekrypterer man derefter den krypterede meddelelse, vil den være læselig igen. Til krypteringen og dekrypteringen bruges der nogle bestemte nøgler. Disse nøgler best˚ ar af et bestemt bit-mønster, som er lavet til at kunne dekryptere eller kryptere en bestemt kryptering. M˚ aden disse nøgler h˚ andteres p˚ a er forskelligt alt efter hvilket kryptosystem der bliver anvendt [38]. Der findes to overordnede kryptosystemer, symmetrisk og asymmetrisk. Det symmetriske kryptosystem bruges til at sende information til bestemte modtagere. I dette system bruges der kun en nøgle K til at kryptere og dekryptere. Man kan beskrive dette kryptosystem som: M + EK → EK (M ) (2.3) EK (M ) + DK → M (2.4) 13 KAPITEL 2. KRYPTOGRAFISKE PRIMITIVER Dette betyder at det symmetriske kryptosystem kun kan bruges til at sende til en mere eller mindre bestemt modtager, da det kræves at b˚ ade sender og modtager har nøglen K installeret [38]. Hvis vi ser p˚ a det asymmetriske kryptosystem, er dette lavet til flere forskellige og ukendte modtager. Her er der mere end en nøgletype, her er b˚ ade en privat nøgle Kpriv og en offentlig nøgle Kpub . Forklaringen til dette kryptosystem ville se s˚ aledes ud: EKpriv (M ) + DKpub → M (2.5) Og omvendt kan man sige: EKpub (M ) + DKpriv → M (2.6) Dette betyder at der i dette kryptosystem kræves en nøgle til kryptering og en anden til dekryptering og dette gør den ideel til flere forskellige modtagere, da sender og modtager kan have hver sin nøgle [38]. - 14 - Kapitel 3 Anvendte kryptografiske primitiver I dette kapitel vil vi forklare to anvendte kryptografiske primitiver. I Afsnit 3.1 vil vi forklare anvendelsen af hashfunktioner. I Afsnit 3.2 vil RSA kort forklares. I Afsnit 3.3 vil vi forklare anvendelsen af signering. 3.1 Hashing I dette afsnit vil teorien bag hashfunktioner beskrives, form˚ alet med funktionerne, hvordan hashværdierne laves, samt hvordan hashfunktioner brydes og gøres sikre. En hashfunktion fungerer ved at et input M bliver lavet om til et output h, ved brug af funktionen hash, alts˚ a kan man beskrive en hashfunktion som: hash(M ) = h (3.1) Her er h det som kaldes hashværdien og denne værdi repræsenterer det originale input. M inputtet kan f.eks. være en fil eller en tekststreng. Form˚ alet med hashfunktioner er at beskytte det originale input, da en ændring i inputtet vil betyde at hashværdien ændres og dette kan opdages hvis programmet tjekker hashværdien. Der findes mange forskellige hashfunktioner, som hver har sin m˚ ade at producere en hashværdi. En simpel hashfunktion kunne f.eks. producere hashværdien, ved brug af den binære operation AND(og), af alle bytes i inputtet [35]. AND er en af flere forskellige operationer, der kan anvendes, n˚ ar et input skal laves om til en hashværdi. Ved brug af binære værdier viser tabellerne 15 KAPITEL 3. ANVENDTE KRYPTOGRAFISKE PRIMITIVER nedenfor, hvordan AND operatoren laver to værdier om til en, samt hvordan 3 andre af de mest normale operatorer kaldet OR(eller), XOR(eksklusivt eller) og NOT(ikke) gør det [40]. In: 11 XOR: 1 0 01 00 Out: In: 0 11 1 AND: 1 0 1 01 0 00 Out: In: 1 11 0 OR: 1 0 0 01 0 00 Out: 1 In: 0 NOT: 1 1 0 0 Out: 0 1 Tabel 3.1: Binære operatorer Dette vil sige at hvis man i f.eks. XOR har to bytes der ses som 1, vil disse blive komprimeret til et 0 som der ses i Tabel 3.1. I de mere moderne og kendte hashfunktioner anvendes disse fire former for operationer. Ved at blande disse gøres det mere kompliceret for en potentiel hacker at bryde sikkerheden i hashfunktionen. For at kunne bryde sikkerheden i en hashfunktion kræves der at en hacker beregner preimage af hashfunktionen. Hvis man tager udgangspunkt i den tidligere nævnte matematiske beskrivelse af en hashfunktion, samt givet y ∈ h s˚ a vil preimage kunne beskrives som: hash−1 (y) (3.2) Hvis det lykkes for en hacker at beregne sig frem til dette, vil det være muligt at lave ændringer i programmet og stadig have den samme hashværdi. Det betyder at ændringen ikke ville kunne opdages. Dette kaldes for et preimage angreb. I de mest sikre hashfunktioner er dette en af de eneste m˚ ader hvorp˚ a funktionen kan brydes. Et preimage angreb g˚ ar matematisk set ud p˚ a at finde en besked M 0 som er lig den originale M hvis man tager hashværdierne af dem: hash(M 0 ) = hash(M ) (3.3) De mindre sikre hashfunktioner har et andet problem. Mange af de mindre sikre funktioner indeholder to forskellige preimage, M 1 og M 2, som kan føre til den samme hashværdi. Dette kaldes en kollision og det kan udnyttes af en hacker til at lave et kollisions angreb, som er en af de nemmeste m˚ ader, hvorp˚ a en hashfunktion kan brydes [35]. Dette angreb kan beskrives som: hash(M 1) = hash(M 2) - 16 - (3.4) 3.1. HASHING Hvor det gælder at M 1 6= M 2. Udover at hashfunktioner helst skal være kollisionsfrie, s˚ a skal funktionerne ogs˚ a helst være envejs. Dette betyder at det skal være svært at regne sig fra en givet hashværdi h, til et input M , alts˚ a: h = hash(M ) (3.5) Hvis dette er tilfældet kaldes det en envejs hashfunktion. Hvis der derimod er mulighed for at regne sig tilbage til preimage fra hashværdien, siger man at funktionen har en ”trapdoor”[22]. Nogle af de mest kendte hashfunktioner er MD5(message-digest algorithm) [37], SHA-1(secure hash algorithm) [26] og SHA-512 [42]. Forskellen p˚ a disse tre funktioner er bl.a. hvilke operationer de bruger, samt hvilken bitstørrelse deres hashværdier er p˚ a. Bitværdien afgør hvor store hashværdierne er og generelt set er det sværere at bryde en hashværdi med en større bitværdi, hvilket betyder at der kræves flere operationer for at bryde dem. Antal operationer for brydning, hvilken type angreb, samt bitværdierne p˚ a de tre tidligere nævnte hashfunktioner ses her: Funktion: MD5 SHA-1 SHA-512 Bitværdi: Angreb type: 128 Kollision 160 Kollision 512 Preimage Operationer: 2020,96 2051 2501 Tabel 3.2: Sikkerhed i hashfunktioner Som det ses er MD5 den funktion, der kræver mindst antal operationer at bryde, samtidigt med at der er mulighed for et kollisions angreb, alt dette gør den til den mest usikre. SHA-512 derimod kan ikke brydes ned med det mere simple kollisions angreb, samtidigt med at der kræves rigtig mange operationer for at bryde den, hvilket gør den til mest sikre. SHA-1 har stadig ulempen ved kollisions angreb, men kræver flere operationer end MD5 som ses i Tabel 3.2. Grunden til at man ikke altid bruger den aller sikreste kan b˚ ade være p˚ a grund af den øgede kompleksitet i at bruge funktionerne, samt et øget krav til lagerplads og processorkraft. Hashfunktioner bruges alt i alt til at sikre data, der ikke m˚ a ændres, ikke bliver ændret. Dette gøres ved at en funktion producerer et unikt ID til det - 17 - KAPITEL 3. ANVENDTE KRYPTOGRAFISKE PRIMITIVER originale input. Hashværdien bliver lavet ved hjælp af forskellige operatorer, herunder XOR, AND, OR og NOT. Kompleksiteten af at bryde en hashfunktion afhænger bl.a. af størrelsen p˚ a hashværdien og to af de mest normale metoder til brydning af en hashfunktion er preimage angreb og kollisions angreb. 3.2 RSA Til asymmetrisk kryptering er der ogs˚ a her forskellige kryptosystemer, en af disse er RSA. RSA kryptering, som er opkaldt efter Ron Rivest, Adi Shamir og Leonard Adleman [35], er et asymmetrisk kryptosystem der krypterer ved hjælp private Kpriv og offentlige Kpub nøgler. Krypteringsprocessen begynder med at den offentlige nøgle Kpub og den private nøgle Kpriv laves. Kpub best˚ ar af to tal, det ene er produktet af to tilfældige primtal Q og P , det andet er krypteringsnøglen C [35]. I udregningerne bruges der mod som er resten efter heltalsdivision mellem to tal. Kpub laves ved først at finde produktet af Q og P , som her kaldes N. N =Q·P (3.6) Dertil findes krypterings nøglen Kpub , som er det tilfældige primtal C, dog skal C være indbyrdes primisk med (P − 1)(Q − 1), dvs. at det eneste tal der m˚ a g˚ a op i C og (P − 1)(Q − 1) er 1 eller −1. Derefter laves den private nøgle Kpriv , ved brug af den udvidede Euclidiske algoritme [3]: CKpriv = 1 mod (P − 1)(Q − 1) (3.7) Dette kan ogs˚ a skrives op med Kpriv isoleret: Kpriv = C −1 mod ((P − 1)(Q − 1)) (3.8) RSA er et blokciffer, som betyder at den skal deles op i lige store dele, der er mindre end N for at der kan krypteres. Hvis beskeden M deles op i I dele kommer krypteringen til at se s˚ aledes ud: EI = MIC - 18 - mod N (3.9) 3.2. RSA Dekrypteringen af EI kommer s˚ a til at være Kpub MI = EI 3.2.1 mod N (3.10) Eksempel p˚ a RSA Dette afsnit vil vise et eksempel p˚ a, hvordan en RSA krypteringsprocess fungerer [35]. Hvis P og Q vælges tilfældigt til at være 47 og 71 vil krypteringensprocessen komme til at se s˚ aledes ud: Først findes N : N = 47 · 71 = 3337 (3.11) E vælges til at være 79 og den private nøgle Kpriv bliver til: Kpriv = 79−1 mod 3220 = 1019 (3.12) I dette eksempel vil den krypterede del angives som C imens at M er originalen. For at kryptere en meddelelse skal den først brydes ned i sm˚ a dele. I dette eksempel er der taget udgangspunkt i at kryptere talrækken: M = 6882326879666683 (3.13) Hvis den brydes op i dele af 3(f.eks. 123, 456), kommer M , til at se s˚ aledes ud: M1 M2 M3 M4 M5 M6 = 688 = 232 = 687 = 966 = 668 = 003 (3.14) (3.15) (3.16) (3.17) (3.18) (3.19) (Der indsættes ’00’ i M6 , fordi de skal have samme længde som de andre led og ’00’ har ingen matematisk betydning). Herefter bruges krypteringsformlen 3.9 og krypteringen kommer til at se s˚ aledes ud: 68879 mod 3337 = 1570 = E1 (3.20) Hvis dette gøres for hele talstrengen vil: E = 15702756209122762423158 (3.21) - 19 - KAPITEL 3. ANVENDTE KRYPTOGRAFISKE PRIMITIVER Til denne proces er der brugt den offentlige nøgle Kpub , nu skal der bruges den private nøgle Kpriv , til at dekryptere talstrengen. Dette gøres ved at bruge dekrypteringsformlen som er givet ved: Mi = Eid mod N (3.22) Bruges denne formel i forhold til eksemplet vil det se s˚ aledes ud: 15701019 mod 3337 = 688 = M1 (3.23) Hele M vil kunne findes ved at dekryptere hver enkelt talstreng med dekrypteringsformlen. P˚ a baggrund af dette kan det ses at man kan lave en krypteringsmetode, hvor det er muligt at kryptere med ´en krypteringsnøgle og dekryptere med en anden, s˚ aledes at brugeren kun behøver at f˚ a den offentlige nøgle Kpub . 3.3 Signering I dette afsnit vil der forklares teori om signering af filer, herunder hvordan det fungerer og hvorfor det bruges. Signering af digitale filer fungerer ligesom signering af fysiske dokumenter. P˚ a et fysisk dokument skrives der en signatur for at verificere dokumentet, det samme gælder for signering af filer. Her er det blot en samling bytes der ligger sammen med eller i filen [35]. Filer signeres for at man kan verificere at filen er ægte, dvs. ikke cracket. Signeringen af en fil kan beskrives som: (M )S (3.24) Hvor S er signeringen og M er den signerede fil. Signeringen kan foretages med RSA kryptering, dertil krypteres der først med den offentlige nøgle: (M )S = Kpriv (M ) (3.25) For at tjekke om signeringen er rigtig dekrypteres der med den private nøgle: Kpub (Kpriv (M )) = M - 20 - (3.26) Kapitel 4 Implementering af algoritmen Dette kapitel beskriver alt vedrørende udvikling af applikationen og implementeringen af algoritmen. I Afsnit 4.1 g˚ ar vi mere ind i kravene til applikationen. I Afsnit 4.2 er selve algoritmen. I Afsnit 4.3 implementeres algoritmen i vores løsning. Derefter beskriver Afsnit 4.4 testning af vores applikation. 4.1 Analyse N˚ ar applikationen kører skal den starte med at tjekke hvorvidt der er mere tid tilbage. Hvis der er mere tid tilbage skal den ˚ abne det tilhørende program og derefter starte med at tælle brugt tid op s˚ a længe programmet kører. Da den anden fil der ˚ abnes sagtens kan være et andet program, er det derfor nødvendigt for os, at kunne bruge multiprocessing. Før at applikationen vil være brugbar skal det ikke være muligt for brugeren(personen der vil ˚ abne den tidsbegrænsede fil) at kunne “snyde sig frem” til mere tid. Da man ikke kan gemme data i et eksekverbar fil efter det er blevet lukket, er det nødvendigt at bruge en datafil hvor information ang˚ aende tiden kan gemmes i. Ved brug af hash funktioner og signering kan denne datafil beskyttes, s˚ aledes at man ikke kan ændre i den. Uden beskyttelse ville brugeren kunne kopiere filen der kontrollerer tiden, s˚ aledes at tiden vil kunne blive nulstillet. Til dette skal der bruges et krypteringsbibliotek. Vi bruger her cryptlib som er et krypteringsbibliotek der ikke kræver erfaring med kryptering for at kunne bruges. Vi opstiller nogle krav for algoritmen: Datakrav: Inkludering af bibliotek 21 KAPITEL 4. IMPLEMENTERING AF ALGORITMEN • #include ”cryptlib.h” Problem inputs • Program eller fil der skal tidsbegrænses • Fil hvor brugt tid kan gemmes Problem outputs • Begrænsning og lukning af filer og programmer der overskrider tiden • Overskrivning af ny tid ved lukkelse af programmet 4.2 Algoritmen Vi tager at: • {P } er programmet som skal tidsbegrænses • K er kontrolfilen • {T }U er en fil med indholdet T , signeret af udbyder U • h(M ) er hash af en besked M • {O}U er vores tidsbegrænsende applikation, som ogs˚ a er signeret • t er tiden • tmax er den maksimale mængde af tid der m˚ a bruges Derefter kan algoritmen beskrives s˚ aledes: 1. Tag input til {O}U • Eksternt program: {P }U • Kontrolfil med tiden t: {K(t)}U 2. Tjek for signering og hash if {h(K(t)1 )}U = {h(K(t)2 )}U then Run{P } else Exit end if - 22 - 4.2. ALGORITMEN 3. Tjek for tid if t < tmax then Run{P } else Exit end if 4. Tæl tiden t op, s˚ a længe program {P } kører while {P } do t=t+1 end while 5. Afslut program {P} if Exit then {O}U = {P, h(K(t0 ))}U end if Et flowchart af applikationen er vist i Figur: 4.1. - 23 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN Applikation Start Input: Program {P, h(K(t))}U Input: Kontrolfil {K(t)}U F˚ a input Nej Signering rigtigt? Ja Hash rigtig? Nej Afslut Program Ja Er der mere tid? Nej Ja Opdater tid {t} Start program {P } Kør til lukning Applikation Stop Output: {P, h(K(t0 ))}U Figur 4.1: Flowchart af applikationen - 24 - 4.3. IMPLEMENTATION 4.3 Implementation I dette afsnit vil der gennemg˚ as hvordan algoritmen er blevet implementeret i et C-program. Sm˚ a stykker af C-kode vil tages ud og forklares gennemg˚ aende. Dertil skal det tilføjes at det som st˚ ar som crypt eller CRYPT, er defineret fra cryptlib biblioteket. Vores produkt blev en suite, hvori det er muligt for en udvikler at implementere sit program og derved f˚ a det tidsbegrænset. 4.3.1 Main Main funktionen er til udvikleren. Den skal indsættes i udviklerens eget program, hvorefter det er muligt at f˚ a programmet tidsbegrænset. Dette opn˚ as ved at benytte multithreading, s˚ aledes at vores applikation kan tælle tiden op ved siden af i en anden tr˚ ad. C biblioteket “pthread” gør det muligt at lave en standard tr˚ ad, som kan initialiseres og derefter startes. “tid” er tr˚ adens unikke ID(Thread ID). Se Bilag A for samlet kildekode. pthread t tid ; p t h r e a d c r e a t e (& t i d , NULL, thread , NULL) ; Hvor tid er et pthread t objekt og thread er den funktion der ønskes at tid skal køre. Herefter kommer den while-løkke hvori udviklerens produkt skal køre, som har følgende parametre: w h i l e ( t l o P != 1 && c != 0 ) 10 { /∗ 12 ∗ PROGRAM KODE ∗/ 14 } tloP(time left of Program) er en global variabel som pthread t tid sætter til 1, hvis der er noget som forhindrer programmet i at køre. Dette kan fremkomme n˚ ar tiden er udløbet, signaturen ikke længere er korrekt eller der er sket modificeringer i kontrolfilen K(t) eller U . Hvor K(t) er vores - 25 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN kontrolfil (K.cf) og U er filen hvori signeringen er skrevet (hshfl.sig). Det skal være muligt for brugeren af produktet, selv at bestemme hvorn˚ ar programmet skal lukke. Dette kan evt. gøres med en variabel c, som afslutter while-løkken n˚ ar den f˚ ar en bestemt værdi, f.eks.: w h i l e ( t l o P != 1 && c != 0 ) 10 { p r i n t f ( ”Tryk ’ 0 ’ f o r a t a f s l u t t e ” ) ; 12 s c a n f ( ”%d” , c ) ; } Til sidst i den fastsatte kode i main funktionen, findes der en afslutningskontrol, som tjekker at programmet lukker ned af korrekte ˚ arsager: 22 i f ( t l o P == 1 ) exit ; 24 e l s e i f ( c == 0 ) exit ; 26 e l s e p r i n t f ( ” A f s l u t t e d e pga ukendt f e j l ! \ n” ) ; Hvis afslutningen af while-løkken sker pga. tr˚ aden, s˚ a vil tloP være 1. Hvis ikke dette er tilfældet, s˚ a kan det være brugeren selv har valgt at afslutte programmet og s˚ a vil c være 1. Hvis ingen af disse tilfælde passer, s˚ a er der sket en fejl og brugeren informeres. Det er muligt for udvikleren selv at tilføje muligheder, hvis udvikleren har et andet system til fejlfinding i sit produkt. 4.3.2 void *thread void *thread er funktionen som tr˚ aden vil eksekvere. Det er i denne funktion at signeringen bliver tjekket og ændring i K(t) bliver ændret til K(t’). Se Bilag A for den sammenhængende kode af void *thread. Det første der sker efter variablerne er blevet deklareret, er initialiseringen af cryptlib biblioteket: 14 //INITIALISERE CRYPTLIB status = cryptInit () ; 16 i f ( s t a t u s != CRYPT OK) { 18 p r i n t f ( ”CRYPTLIB INITIALISATION FAILED ! ” ) ; } - 26 - 4.3. IMPLEMENTATION Hvis cryptlib ikke initialiseres korrekt vil der blive vist en fejlmeddelelse til brugeren, s˚ adan at brugeren er klar over problemet. Dette burde dog ikke ske, medmindre brugeren har modificeret indholdet af det p˚ agældende produkt. N˚ ar cryptlib er blevet initialiseret, hentes de nøgler, som skal benyttes til at læse og skrive signeringen: cryptKeysetOpen (& c r y p t K e y s e t , CRYPT UNUSED, CRYPT KEYSET FILE, ” /PATH/TO/KEYS/ ” , CRYPT KEYOPT READONLY) ; “/PATH/TO/KEYS/” er stien til hvor nøglerne ligger p˚ a en computer, eller en server. Funktionen cryptKeysetOpen tager følgende input: • CRYPT KEYSET *keyset • const CRYPT USER cryptUser • const CRYPT KEYSET TYPE keysetType • const char *name, const • CRYPT KEYOPT TYPE options Vi benytter CRYPT UNUSED som cryptUser, fordi denne funktion ikke er brugerbegrænset. Man kan begrænse de forskellige muligheder med brugere i cryptlib. Det kan sammenlignes med administratorer og almene brugere p˚ a f.eks. et internetforum. Da der i dette tilfælde ikke er en bruger, men kun en funktion, benytter vi CRYPT UNUSED. Herefter benytter vi CRYPT KEYSET FILE for at specificere at vi ønsker at hente nøglerne fra en nøglefil, hvortil en sti skal opgives. Dette kan b˚ ade være lokalt, men ogs˚ a p˚ a en server. Til sidst informeres cryptlib om, at der kun ønskes at læse nøglerne fra filen ved hjælp af CRYPT KEYOPT READONLY. Dette er standard metoden til at hente nøgler fra en fil p˚ a, hvis de skal bruges til kryptering eller lignende, fordi her ønskes ikke at ændre i nøglerne. Efterfølgende skal der tilføjes de nøgler vi ønsker at have i keysettet. I dette tilfælde en privat Kpriv og offentlig nøgle Kpub . Dette gøres p˚ a følgende m˚ ade: //INITIALISERE KEYSET OG CONTEXT 34 c r y p t G e t P r i v a t e K e y ( c r y p t K e y s e t , &privateKey , CRYPT KEYID NAME, ”B220” , ”B220” ) ; cryptGetPublicKey ( c r y p t K e y s e t , &publicKey , CRYPT KEYID NAME, ”B220” ) ; - 27 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN Hvor cryptGetPrivateKey tager følgende input: • const CRYPT HANDLE cryptHandle • CRYPT CONTEXT *cryptContext • const CRYPT KEYID TYPE keyIDtype • const void *keyID, • const char *password Den første parameter til funktionen, er hvilket keyset man ønsker at hente den private nøgle til. Da det er muligt at benytte mange keysets, er dette en nødvendighed. Herefter skal man specificere i hvilken context man ønsker at gemme den private nøgle. Dvs. man linker nøglen til et keyset og giver den herefter sin egen context, som man kan benytte hvis man skal bruge netop denne nøgle. Et keyset kan indeholde uendelig mange nøgler, s˚ a det er vigtigt at huske hvilke nøgler der er i hvilke keysets. Efter man har fortalt hvilket keyset og context at nøglerne skal tilhøre, skal cryptlib vide hvilken nøgle man ønsker. En keyfile kan ligesom et keyset indeholde et utal af nøgler og alle gemte nøgler har et unikt reference ID kaldet et label. Man benytter nu dette label med CRYPT KEYID NAME ved at oplyse navnet p˚ a den nøgle der ønskes. Man kan ogs˚ a bruge e-mail og andre ID referencer, men i dette tilfælde har den kun et navn; ”B220”. Til sidst oplyses et keyID og kodeord. Kodeordet skal bruges fordi private nøgler altid er krypteret n˚ ar de er opbevaret som filer(DES3 kryptering som standard). Der skal derfor oplyses et kodeord, som i dette tilfælde er ”B220”. Der gøres nu det samme med den offentlige nøgle, dog kræver den ikke et kodeord fordi den er offentlig. Der skal nu ogs˚ a initialiseres en context hvori man ønsker at benytte en hashfunktion p˚ a en given data og det gøres p˚ a følgende m˚ ade: 36 c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; cryptCreateContext skal først have at vide hvilken context der ønskes initialiseret, derefter hvilken bruger der gør det. Vi benytter igen CRYPT UNUSED, da der som allerede beskrevet ikke er nogle brugere. Til sidst gøres der opmærksomt p˚ a at der her ønskes benyttelse af SHA-1 (3.1) algoritmen i denne context. - 28 - 4.3. IMPLEMENTATION Efter at nøglerne {K}pub samt {K}priv er p˚ a plads, kan man ˚ abne kontrolfilen K(t): //˚ ABNER KONTROLFILEN ”K. c f ” 24 k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f s e e k ( k F i l e , 0 , SEEK END) ; 26 k S i z e = f t e l l ( k F i l e ) ; rewind ( k F i l e ) ; 28 b u f f e r = m a l l o c ( s i z e o f ( c h a r ) ∗ k S i z e ) ; fread ( buffer , 1 , kSize , kFile ) ; Det der benyttes her, er en simpel standard metode til at ˚ abne filer i C ved hjælp af fopen(“filename”, “r”) samt fread(void * ptr, size t size, size t count, FILE * stream). Man starter med at ˚ abne filen, finder slutningen p˚ a den, læser dens størrelse og sætter dens mængde plads af i heapen, hvorefter filindholdet bliver læst til en buffer, som her er kaldt ”buffer”. Da man nu har sine nøgler og filen K(t), kan der nu benyttes en hashfunktion p˚ a filen K(t) og derved f˚ a h(K(t)): 38 //HASH AF FILINDHOLD cryptEncrypt ( hashFile , kFile , kSize ) ; 40 c r y p t E n c r y p t ( h a s h F i l e , k F i l e , 0 ) ; CryptEncrypt skal have at vide i hvilken context den skal lave krypteringen, i dette tilfælde hashFile, som lige er initialiseret til SHA-1 algoritmen og cryptlib vil derfor benytte denne algoritme p˚ a den data vi tilføjer. Den data der bliver tilføjet er filen kFile, som er en stream af filen K(t). Til sidst skal der oplyses hvor mange tegn der skal arbejdes med og det er kSize, alts˚ a størrelsen af indholdet af filen K(t). Efter man har benyttet en hashfunktion p˚ a dataen og hashværdien ligger i contexten, skal man benytte hashfunktionen en gang til, men denne gang med ‘0’, som sidste parameter, for at fortælle cryptlib der ikke kommer mere data. N˚ ar der er blevet anskaffet en hash af kontrolfilen K(t), som kaldes h(K(t)), skal hashværdien signeres, s˚ adan man f˚ ar {h(K(t))}U . Det gøres s˚ aledes: c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , hashFile ) ; 44 s i g n a t u r e F i l e = m a l l o c ( signatureMaxLength ) ; c r y p t C r e a t e S i g n a t u r e ( s i g n a t u r e F i l e , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , h a s h F i l e ) ; - 29 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN For at forklare hvad der sker her, kigger vi p˚ a de input parametre som funktionen cryptCreateSignature kræver: • void *signature • const int signatureMaxLength • int *signatureLength • const CRYPT CONTEXT signContext • const CRYPT CONTEXT hashContext Den første parameter er en af de vigtigste, det er en pointer til en void (void *) hvor signaturen skal placeres. Denne skal allokeres dynamisk, da dens størrelse kan variere. Det er dog muligt at afsætte mere plads end der er nødvendigt, men med den metode er der en risiko for at man f˚ ar nogle bytes med, som ikke er en del af signeringen og det vil give problemer senere hen. Den dynamiske allokering forklares herunder. Herefter skal funktionen bruge en pointer til en variabel af typen int (int *), som f˚ ar en værdi tilsvarende den længde signaturen har. CRYPT CONTEXT signContext er den nøgle der skal signeres med og CRYPT CONTEXT hashContext er den context hvori hashværdien h(K(t)), skal ligges. Som det kan ses, benyttes funktionen to gange. Dette er, som der blev forklaret ovenfor, for at der skal allokeres plads til signeringen dynamisk. N˚ ar man bruger “NULL” og “0” som de to første parametre, s˚ a bliver signatureMaxLength lavet til den størrelse signaturen f˚ ar og man kan derfor bagefter allokere plads til signeringen med malloc, og til sidst lave den rigtige signering, uden “NULL” og “0”. cryptDestroyContext ( hashFile ) ; Denne funktion ødelægger den context der kaldes hashFile. Det er vigtigt at ødelægge alle cryptlibobjekter inden man lukker programmet, dels fordi cryptlib ellers giver en fejlmeddelelse, men ogs˚ a for at gøre arbejdet mere sikkert. Da der ikke skal bruges hashFile igen, ødelægges den derfor. De efterfølgende linjer kode, er noget der allerede er gennemg˚ aet, men for nogle nye objekter, s˚ a det vil der ikke blive g˚ aet mere i dybden med; i korte træk sker følgende: - 30 - 4.3. IMPLEMENTATION 1 //˚ ABNER FILEN MED SIGNATUREN h s h f l = f o p e n ( ” h s h f l . s i g ” , ” rb ” ) ; 3 f s e e k ( h s h f l , 0 , SEEK END) ; hSize = f t e l l ( hshfl ) ; 5 rewind ( h s h f l ) ; hsh = m a l l o c ( s i z e o f ( c h a r ) ∗ h S i z e ) ; 7 f r e a d ( hsh , 1 , h S i z e , h s h f l ) ; fclose ( hshfl ) ; Hvor indholdet af U hentes og der gemmes en pointer til indholdet, som kaldes hsh. 68 s i g n a t u r e R e s u l t = c r y p t C h e c k S i g n a t u r e ( hsh , b y t e s C o p i e d F i l e , publicKey , h a s h F i l e ) ; Denne funktion tjekker signeringen. Funktionen tager følgende input: • const void *signature • const int signatureLength • const CRYPT HANDLE sigCheckKey • const CRYPT CONTEXT hashContext Første parameter er den signatur der ønskes tjekket, som her er den signering vi henter fra filen U , efterfulgt af hvor mange bytes den er p˚ a Efter dette, skal man tilføje den offentlige nøgle Kpub , som hører til den private nøgle Kpriv som signeringen {h(K(t))}U , oprindeligt blev lavet med. Da vi i dette tilfælde kun har ´en privat Kpriv og ´en offentlig nøgle Kpub , er det ikke et problem. I større og mere komplekse systemer, kan det være sværere at finde den korrekte nøgle. Til sidst skal der oplyses den hashværdi som blev signeret, da denne skal bruges til sammenligning. Dette er nødvendigt, fordi signering er en oneway trapdoor funktion(se Afsnit 3.1), s˚ a n˚ ar den dekrypterer signeringen med den offentlige nøgle Kpub , vil den f˚ a en hashværdi, DKpub ({h(K(t))}U ), som den tjekker med den hashværdi der er oplyst. Stemmer disse to overens, s˚ a er signeringen korrekt og returværdien vil blive CRYPT OK. Følgende kode tager sig af de tilfælde hvor signeringen ikke passer og sætter den globale variabel tloP til 1, hvilket signalerer til resten af programmet at det skal lukke ned ved næste givne mulighed. Denne mulighed der her - 31 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN snakkes om, er n˚ ar while-løkken som kører udvikleres program har kørt et loop, eller hvis udvikler implementerer variablen tloP i sin kode, kan det være p˚ a det tidspunkt denne ønsker: 72 i f ( s i g n a t u r e R e s u l t == CRYPT ERROR SIGNATURE) { 74 p r i n t f ( ”SIGNATURE NOT VERIFY! \ n” ) ; tloP = 1; 76 } e l s e i f ( s i g n a t u r e R e s u l t == CRYPT ERROR NOTFOUND) 78 { p r i n t f ( ”THE KEY NEEDED WAS NOT FOUND\n” ) ; 80 tloP = 1; } 82 e l s e { 84 p r i n t f ( ”A WIZARD STOLE YOUR DATA. SORRY! \ n” ) ; tloP = 1; 86 } Den næste del af koden tager udgangspunkt i, at resultatet af cryptCheckSignature er CRYPT OK. Hvis signeringen passer, tjekkes der, om brugeren har mere tid tilbage at benytte programmet i. Hvis dette ikke er tilfældet, s˚ a lukkes programmet ned. Hvis brugeren har mere tid tilbage, skal K(t) opdateres til K(t0 ) og signeres igen, da den vil f˚ a en ny hashværdi efter ændringen. Mange af funktionerne er nogle som allerede er blevet gennemg˚ aet, s˚ a der vil primært blive forklaret hvad der sker: Værdien for hvor lang tid brugeren har benyttet programmet tælles op som det første. Herefter skrives den nye data til kontrolfilen K(t), hvor der benyttes fflush for at gennemtvinge en skrivning til filen. N˚ ar dette er passeret, laves der en hash for filen K(t) p˚ a ny og filen signeres igen. Dette gøres, da en ny værdi i filen K(t) vil ændre dens hashværdi og da signeringen er p˚ a hashværdien, skal dette opdateres. Denne opdatering i signeringen gennemtvinger ogs˚ a en skrivning til harddisken. Til sidst ødelægges det resterende cryptlibobjekter og cryptlib lukkes. Efter et bestemt tidsinterval starter hele processen forfra. Dette tidsinterval kan afhænge fra udbyder til udbyder, afhængig af hvor lang tid de ønsker at brugerne har til at teste programmet i. - 32 - 4.3. IMPLEMENTATION 146 c r y p t K e y s e t C l o s e ( c r y p t K e y s e t ) ; cryptDestroyContext ( privateKey ) ; 148 c r y p t D e s t r o y O b j e c t ( publicKey ) ; s t a t u s = cryptEnd ( ) ; 150 i f ( s t a t u s != CRYPT OK) { 152 p r i n t f ( ”CRYPTLIB SHUTDOWN FAILED\n” ) ; } 154 s l e e p ( 2 ) ; 4.3.3 Oprettelse af testversion De forg˚ aende afsnit tager udgangspunkt i at, der allerede eksisterer en kontrolfil K(t), en keyfile KF il samt en fil hvori signeringen ligger U . Der er ikke blevet forklaret hvordan disse laves og hvilke data de skal indeholde, som vil blive forklaret her. Den fulde kode til oprettelsen af disse filer findes i Bilag D. Princippet er for dette meget lig noget af det vi allerede har gennemg˚ aet, men der vælges alligevel at gengive koden, dog med kort beskrivelse af de ting der allerede er blevet diskuteret og med en uddybende forklaring til det som er nyt. 4.3.4 Nøglefilen KF il Nøglefilen som skal benyttes skal genereres før den kan benyttes. N˚ ar dette lille program kører vil det generere en unik nøglefil, som kan bruges til at skrive og læse signeringer med. Se Bilag D for samlet kildekode. Først skal vi initialisere vores context: 26 //INITIALISATION AF CONTEXT c r y p t C r e a t e C o n t e x t (& sigKeyContext , CRYPT UNUSED, CRYPT ALGO RSA) ; Metoden er den samme, som allerede beskrevet i 4.3.2, med den forskel, at vi her benytter RSA algoritmen. Det blev nævnt i 4.3.2 at hver nøgle havde en unik nøgleID (keyID) og den laves p˚ a følgende m˚ ade: - 33 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN //LABLER 30 c r y p t S e t A t t r i b u t e S t r i n g ( sigKeyContext , CRYPT CTXINFO LABEL, label , labelLenght ) ; Hvor CRYPT CTXINFO LABEL forklare funktioenne vi ønsker at sætte atributten CTXINFO LABEL til ‘label’ med længden ‘labelLenght’. N˚ ar dette er p˚ a plads, kan vi generere en nøgle til contexten: 32 //LAVER KEY cryptGenerateKey ( sigKeyContext ) ; Denne funktion er nem at benytte, fordi man allerede p˚ a nuværende tidspunkt har givet den al den information den skal bruge for at kunne lave en nøgle: Context hvori nøglen skal ligge, algoritmen der skal benyttes(RSA) og et label til denne nøgle. Nøglen skal nu, modsat det der blev vidst i Afsnit 4.3.2, sættes ind i et keyset og dertil benytter man følgende kode: //LAVER KEYSET 36 cryptKeysetOpen (& c r y p t K e y s e t , CRYPT UNUSED, CRYPT KEYSET FILE, ” k e y s . p15 ” , CRYPT KEYOPT CREATE) ; cryptAddPrivateKey ( c r y p t K e y s e t , sigKeyContext , ”B220” ) ; Hvor funktionen cryptKeysetOpen tager følgende argumenter: • CRYPT KEYSET *keyset • const CRYPT USER cryptUser • const CRYPT KEYSET TYPE keysetType • const char *name, const • CRYPT KEYOPT TYPE options Denne funktion er blevet forklaret i Afsnit 4.3.2, med undtagelse af den sidste parameter, som her er anderledes. I stedet for at ˚ abne et keyset som Read Only, laver vi i stedet den fil hvori keysettet skal ligge. Det sidste der skal gøres inden nøglerne er klar til brug, er at føje dem i et certifikat: - 34 - 4.3. IMPLEMENTATION //LAVER CERTIFICAT 40 c r y p t C r e a t e C e r t (& c r y p t C e r t i f i c a t e , CRYPT UNUSED, CRYPT CERTTYPE CERTIFICATE) ; c r y p t S e t A t t r i b u t e ( c r y p t C e r t i f i c a t e , CRYPT CERTINFO SELFSIGNED, 1) ; 42 c r y p t S e t A t t r i b u t e ( c r y p t C e r t i f i c a t e , CRYPT CERTINFO CA, 1 ) ; //GØR DET MULIGT AT SIGNE MED CERTIFIKAT 44 c r y p t S e t A t t r i b u t e ( c r y p t C e r t i f i c a t e , CRYPT CERTINFO KEYUSAGE, CRYPT KEYUSAGE DIGITALSIGNATURE | CRYPT KEYUSAGE KEYENCIPHERMENT) ; 46 //SIGNERER CERTIFICAT c r y p t S i g n C e r t ( c r y p t C e r t i f i c a t e , sigKeyContext ) ; 48 cryptAddPublicKey ( c r y p t K e y s e t , c r y p t C e r t i f i c a t e ) ; Der bliver her benyttet en del funktioner lige efter hinanden og de vil nu blive forklaret i rækkefølge: Funktionen cryptCreateCert: • CRYPT CERTIFICATE *cryptCert • const CRYPT USER cryptUser • const CRYPT CERTTYPE TYPE certType Her er første parameter et certifikatobjekt som bliver initialiseret her. Her benyttes igen CRYPT UNUSED som cryptUser og til sidst oplyses hvilket certifikat der skal laves. Funktionen cryptSetAttribute benyttes tre gange lige efter hinanden og deres form˚ al forklares her. Vi ønsker at lave et certifikat som fungere som “administrator certifikat”. Det betyder, at dette certifikat ikke har nogle begrænsninger. Normalt n˚ ar man udsteder certifikater til brugere af ens produkt, skal de ikke have mulighed for selv at lave certifikater, men kun mulighed for fx at tjekke en signatur. Dette gøres ved at benytte cryptSetAttribute to gange, hvor man angiver sit certifikatobjekt, og første gang tilføjer CRYPT CERTINFO SELFSIGNED for at forklare vi ønsker et “selfsigned” certifikat, alts˚ a at der ikke er brug for godkendelse fra et “administartor certifikat” for at lave det. Tredje parameter skal altid være 1 i denne sammenhæng. Det kan ses som en betegnelse for at CRYPT CERTINFO SELFSIGNED sættes til true. - 35 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN Anden gang man benytter cryptSetAttribute til at sætte attributten CRYPT CERTINFO betyder det at man laver et CA certifikat(Certificate Authority). Tredje og sidste brug af cryptSetAttribute er for at sætte attributten CRYPT CERTINFO KEYUSAGE til CRYPT KEYUSAGE DIGITALSIGNATURE og CRYPT KEYUSAGE KEYENCIPHERMENT, som gør at certifikatet m˚ a lave digital signering samt muligheden for at dekryptere med det. Dekrypteringen benyttes til at læse signaturen. De sidste to funktioner, cryptSignCert og cryptAddPublicKey bruges til at signere certifikatet med den private nøgle Kpriv , for at gøre det gyldigt og tilføje den offentlige nøgle Kpub til certifikatet ogs˚ a. Herefter er nøglefilen klar til brug. Oprettelse af U Se Bilag D for samlet kildekode. //INITIALIZERE 40 c r y p t G e t P r i v a t e K e y ( c r y p t K e y s e t , &privateKey , CRYPT KEYID NAME, ”B220” , ”B220” ) ; cryptGetPublicKey ( c r y p t K e y s e t , &publicKey , CRYPT KEYID NAME, ”B220” ) ; 42 c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; 44 //HASH AF FILINDHOLD cryptEncrypt ( hashFile , buffer , b u f f e r S i z e ) ; 46 c r y p t E n c r y p t ( h a s h F i l e , b u f f e r , 0 ) ; 48 //SIGNERE HASH FILE c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , hashFile ) ; 50 s i g n a t u r e F i l e = m a l l o c ( signatureMaxLength ) ; c r y p t C r e a t e S i g n a t u r e ( s i g n a t u r e F i l e , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , h a s h F i l e ) ; Her initialiseres, hashes og signeres der; princippet er det samme som fra Afsnit 4.3.2. Signeringen skrives herefter til en fil U , som senere indlæses af programmet til sammenligning, som beskrevet i Afsnit 4.3.2: - 36 - 4.4. TESTS 56 //SKRIVER SIGNERING TIL FIL h s h f l = f o p e n ( ”FDSS . s i g ” , ”wb” ) ; 58 f w r i t e ( s i g n a t u r e F i l e , 1 , b y t e s C o p i e d F i l e , h s h f l ) ; fflush ( hshfl ) ; 60 f c l o s e ( h s h f l ) ; Kontrolfilen K(t) Kontrolfilen K(t) best˚ ar af to tal hhv. tMax og tCur. Filen er en simpel tekstfil, hvori de to tal st˚ ar, men kan ogs˚ a laves med kode: 1 k F i l e = f o p e n ( ”K. c f ” , ”w” ) ; f p r i n t f ( k F i l e , ”%d %d” , tMax , tCur ) ; 3 fflush ( kFile ) ; fcl ose ( kFile ) ; Hvor tCur er lig 0, og tMax er den samlede maksimale prøvetid i hele minutter. 4.4 Tests I dette afsnit vil de udførte tests p˚ a vores applikation beskrives. For at udføre de ønske tests er der tilføjet printf-funktioner, som ikke er oplyst i kildekoden. Dette blev gjort for at bedømme om applikationen, gjorde som den skulle. Det skal dog her siges, at grundet manglede ressourcer, har det ikke været muligt at lave nogle store dybdeg˚ aende tests. Der er blot blevet testet om applikationen levede op til disse krav: • Kan det overhovedet eksekveres? • Kan det køre b˚ ade med det implementeret program samt tr˚ aden? • Lukker applikationen korrekt n˚ ar prøvetiden er overst˚ aet? • Tillader applikationen brugeren at benytte det efter prøvetiden er udløbet? • Tillader applikationen der ændres i kontrolfilen K(t)? - 37 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN Figur 4.2: Første test Den første test som applikationen blev udsat for, var om det reelt bare kunne køre og lukke korrekt ned. Dette gik fejlfrit som det kan ses p˚ a Figur 4.2. Tiden bliver talt op og programmet lukker p˚ a ‘0’ som input. - 38 - 4.4. TESTS Anden test vi udsatte applikationen for, var om det program som var implementeret ogs˚ a virkede. Vi brugte til dette form˚ al et simpelt program, som bare kopierede det tegn der blev givet som input og lukkede ned p˚ a ‘0’. Resultatet kan ses midt p˚ a Figur 4.3. Den tredje test som blev udført, var at se om applikationen vil lukke korrekt ned, n˚ ar den maksimale prøvetid var benyttet. Endnu en gang bestod applikationen denne test, som det ses p˚ a Figur 4.4. Den næst sidste test der blev udført p˚ a applikationen, var om det vil nægte brugeren adgang efter at den maksimale prøvetid var n˚ aet. Som Figur 4.5 illusterer, klarede applikationen ogs˚ a denne test. Den sidste test, var om applikationen tillod ændringer i K(t) og dertil er svaret nej. Hvis dette gøres af brugeren, vil man ved start af applikationen f˚ a samme besked som der sluttes med p˚ a Figur 4.4. - 39 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN Figur 4.3: Anden test - 40 - 4.4. TESTS Figur 4.4: Tredje test - 41 - KAPITEL 4. IMPLEMENTERING AF ALGORITMEN Figur 4.5: Fjerde test - 42 - Kapitel 5 Konklusion I dette kapitel konkluderes der p˚ a projektet. I Afsnit 5.1 konkluderer vi p˚ a projektet, og p˚ a om der er blevet svaret p˚ a problemformuleringen. I Afsnit 5.2 vurderer vi vores løsning. I Afsnit 5.3 perspektiverer vi p˚ a projektet. 5.1 Projektets resultater Vores problemformulering lød: Hvordan laver man tidsbegrænsning af filer og hvordan sørger man for, at tidsbegrænsningen ikke kan brydes eller p˚ a anden m˚ ade ændres? Vi har lavet en applikation der tidsbegrænser en eksekverbar fil, samt krypterede og signerede applikationen for at forhindre forbrugeren i at redigere i tidsbegrænsningen. For at gøre dette har vi undersøgt teorien bag kryptering af filer, og hvordan det ville kunne implementeres i et C-program. Tidsbegrænsingen fungerer i vores tilfælde p˚ a følgende m˚ ade: open (K) 2 r e a d ( tCur and tMax ) ; 4 i f ( tCur < tMax ) run ; 6 else exit ; 43 KAPITEL 5. KONKLUSION Vi har brugt signering af filer til at sikre at brugeren ikke kan ændre i filerne. Dette er gjort ved at signere hashen af filen med RSA kryptering. EKprivat (h(k(t)) → {h(k(t))}U (5.1) Vores applikation opfylder de væsentligste krav vi har opstillet, som var at brugeren ikke kunne f˚ a adgang til at ændre i filerne s˚ aledes at tidsbegrænsningen vil være nyttesløs, samt at der er en tidsbegrænsning p˚ a et program. Dog opfylder applikationen ikke kravet om at komme med en p˚ amindelse om at det bliver lukket. Det er en mindre detalje som er let og hurtigt at implementere. Derudover har det ikke været muligt at forhindre brugeren i at kopiere programmet, og igennem det f˚ a ubegrænset tid. Det ville kræve en server som vi ikke havde adgang til. 5.2 Vurdering af løsning Efter at have implementeret vores løsning, er det ideelt at overveje om denne løsning, løser det reelle problem. Der blev formuleret et problem med en datalogisk tilgang til dette. Det datalogiske aspekt i det var at skabe en tidsbegrænset fil. Man kan argumentere for at vores løsning løser problemet. I virkeligheden handler det om, at piratkopiering ofte foreg˚ ar bare for at prøve produktet. Det er fra dette udgangspunkt at vores applikation er skrevet, alts˚ a har vi løst et delproblem af problemet, piratkopiering. Vores løsning muliggør at prøve det fulde program i modsætning til mange former for prøveversioner. Løsningen kan ogs˚ a overføres til andet end software. Det giver god mening at implementere løsningen i f.eks. musik, hvor forbrugeren har mulighed for begrænset afspilning af nummeret og skal derefter betale for det fulde produkt. Ved f.eks. film eller e-bøger er det anderledes, ideen er jo at implementere et helt produkt, for at dette skulle kunne fungere med e-bøger eller film, skal forbrugeren ikke have mulighed for at se eller læse alt under tidsperioden. Det er alts˚ a nødvendigt at indstille tiden i forhold til materialet. Der er dog ogs˚ a ulemper ved vores løsning, dette indebærer f.eks. at man blot kan kopiere mappen hvor programmet ligger i p˚ a følgende m˚ ade: Skaf programmet → kopier det → brug programmet → n˚ ar tiden udløber, bruges den kopierede mappe. Den løser alts˚ a problemet, men den er stadigvæk nem at cracke, dette problem kan som sagt løses ved server verificering. - 44 - 5.3. PERSPEKTIVERING 5.3 Perspektivering Som videreudvikling p˚ a at løse piratkopieringsproblemet kan man forestille sig at der bliver taget andre metoder i brug end den vi har fremstillet. De synlige vandmærker i film kan muligvis udvikles i en retning, der gør at maskiner som afspiller filen eller dvd’en med filmen p˚ a, tjekker for dette vandmærke. Den vil s˚ a afspille filmen med vandmærket aktivt medmindre der er en fil N , som fortæller maskinen at den ikke skal. Dermed kan piratkopiering fra dvd’er bekæmpes hvis det gøres besværligt at samtidig f˚ a N med i kopieringen. Ulempen med dette er dog at hvis filmen bliver downloadet som en format der kan ses p˚ a computeren, kræver det at denne fil N , men den vil med stor sandsynlighed blive hentet sammen med filmen. Da kopiering af filer er en eksakt kopi, er det svært at forhindre vandmærket i ikke at blive kopieret med, men det kan forstilles at forskning p˚ a omr˚ adet, en dag gør det muligt for data ikke at kunne kopieres. Hvis slid kunne indføres p˚ a en fil, er en af de helt store ulemper der kan skade industrien, er at forbrugeren vælger et alternativt produkt for at undg˚ a at miste sine filer til slitage. Mange forbrugere kan risikere at sidde med følelsen af at skulle betale for noget to gange hvis filerne pludselig ikke virker længere. En anden uønsket reaktion fra forbrugeren kan være at de vælger at blive piratkopister, med samme argument at de ikke ønsker at betale to gange for samme produkt. Det kan dog vise sig at nogle er villige til at betale for en ny kopi. Dermed kan producenten tjene penge fra den side hvis ikke prisen sættes ned, som et resultat p˚ a det mulige slitage. Vores applikation er i nuværende stadie, ikke fuldstændig sikkert. Det er stadigt muligt at kopiere mappen og derved f˚ a ubegrænset tid. Der kan skabes yderligere sikkerhed, via en server over internettet. Dette har dog den ulempe at en internetforbindelse er p˚ akrævet, hvilket det ikke kan garanteres, at alle altid har adgang til. Løsningsmodellen kan yderligere øge salget af software, da forbrugeren har muligheden for at kunne prøve produktet før det skal betales. Dette kan medføre at softwarefirmaer tjener flere penge og dermed kan udvikle bedre produkter og udvide med flere arbejdspladser, hvilket yderligere medfører en øget indtægt p˚ a indkomstskat, samt øget salg der giver flere penge i statskassen. Eftersom applikationen p˚ a nuværende tidspunkt kun passer til et program, kan en videreudvikling p˚ a denne model sprede den til andre platforme, heriblandt konsoller. - 45 - KAPITEL 5. KONKLUSION En alternativ løsning til problemet kan være større udbud eller udvikling af tjenester som Spotify, som er en service der tilbyder det meste musik gratis mod at der er reklamer fra tid til anden [1]. Hvis man kan overføre dette til spil eller film vil m˚ aden hvorp˚ a disse industrier tjener penge blive ændret og i højere grad ligne det som musikindustrien tjener penge p˚ a. Hvis lovlig adgang til materiale p˚ a internettet bliver gjort lige s˚ a let som piratkopiering til en retfærdig pris, har internettet et stort potentielle til at blive en god indtægtsmulighed. Der er allerede p˚ a nuværende tidspunkt mange aktive antipirat strategier. Blandt dem er, som det tidligere nævnt, DRM(se Afsnit 1.2.2 hvilket vores applikation ogs˚ a er, da det begrænser brugerens rettigheder omkring tidsforbruget. Der eksisterer allerede mange former for tidsbegrænsede programmer og computerspil, men de giver oftest ogs˚ a en begrænsning i funktionerne, hvilket der ikke er i vores. Der er derfor en risiko for at løsningen ikke ender som noget forbrugeren ser positivt p˚ a, hvis producenten misbruger muligheden for at smide reklamer ind for at f˚ a betaling fra brugeren, hvilket i sidste ende kan irritere forbrugeren mere end det positive faktum, at de kan prøve produktet gratis. Tidligere (se Afsnit 1.3) blev det politiske aspekt nævnt kort. Hvis piratpartierne f˚ ar større indflydelse p˚ a regeringerne rundt om i verdenen, kan det meget vel betyde reformer af ophavsretten i mange lande, hvilket kan betyde piratkopiering som vi kender det i dag, ikke længere vil eksistere. Der er alts˚ a her tale om en alternativ m˚ ade at bekæmpe piratkopiering p˚ a, ved ikke længere at definere det som et problem. I Schweiz har de en anderledes ophavsretslov. Det er ikke ulovligt at piratkopiere f.eks. film. Det blev besluttet ikke at ændre p˚ a loven, p˚ a baggrund af en undersøgelse der blev udført i 2010 [19]. Her er dog kun tale om et land og dets normer, det er ikke sikkert at den samme udvikling vil indtægten i andre lande positiv, dog er det en mulighed. - 46 - Litteratur [1] http://www.spotify.com. 46 [2] Bekendtgørelse af lov om ophavsret. https://www.retsinformation. dk/forms/r0710.aspx?id=129901. 1 [3] Euclidiske algorithm. http://aleph.straylight.co.uk/eea.pdf. 18 [4] Gdp per capita. PCAP.CD. 4 http://data.worldbank.org/indicator/NY.GDP. [5] List of minimum wages by country. http://en.wikipedia.org/wiki/ List_of_minimum_wages_by_country. 5 [6] Straffeloven. https://www.retsinformation.dk/Forms/r0710.aspx? id=133530. 8 [7] Adobe. http://www.adobe.com/products/photoshop.html. 5 [8] aXXo. http://axxomovies.org/. 6 [9] Deborah Bothun and Matthew Lieberman. Piracy survey summary report. Technical report, PwC, 2010. http://www.pwc.com.uy/es_ UY/uy/publicaciones/assets/piracy-survey.pdf. 6 [10] BSA. Bsa members. http://www.bsa.org/country.aspx. 2 [11] BSA. Softare piracy on the internet: A threat to your security. Technical report, BSA, October 2009. http://portal.bsa.org/ internetreport2009/2009internetpiracyreport.pdf. 2 [12] BSA. 2010 piracy study. Statistic report, BSA, Maj 2011. http://portal.bsa.org/globalpiracy2010/downloads/study_ pdf/2010_BSA_Piracy_Study-Standard.pdf. 4 [13] Bram Cohen. The bittorrent protocol specification, January 2008. http: //www.bittorrent.org/beps/bep_0003.html. 6 47 LITTERATUR [14] Paul Craig. Software Piracy Exposed. Syngres Publishing, Inc., 2005. 6, 7 [15] Cory Doctorow. Why poor countries lead the world in piracy. theguardian, 1:1, Maj 2011. http://www.guardian.co.uk/technology/2011/ may/03/why-poor-countries-lead-world-piracy. 5 [16] Anoop Gantayat. Piracy cost game industry over 3.8 trillion yen – report. Blog, Juni 2010. http://andriasang.com/comles/cesa_ piracy_report/. 3 [17] Corey Grice and Sandeep Junnarkar. Gates, buffett a bit bearish, July 1998. http://news.cnet.com/2100-1023-212942.html. 9 [18] Peter Gutmann. cryptlib Security Toolkit, version 3.4 edition, October 2010. ftp://ftp.franken.de/pub/crypt/cryptlib/. 69, 70 [19] Hachman. Piracy pays for itself, swiss government says, December 2011. http://www.pcmag.com/article2/0,2817,2397173,00.asp. 46 [20] Troels Heeger. Tysk piratparti vinder p˚ a venstreorienteret profil. Information, 1:1, September 2011. http://www.information.dk/279912. 9 [21] IPOS. Launch of anti-piracy movie trailer. Press Release, July 2004. http://www.ipos.gov.sg/topNav/news/pre/2004/Launch+of+ anti+piracy+movie+trailer.htm. 7, 8 [22] Jeff. Electronic signatures, 2008. http://en.kioskea.net/contents/ crypto/signature.php3. 17 [23] Karaganis. Adobe logic. h, April 2011. http://piracy.ssrc.org/ adobe-logic/. 10 [24] Julia Layton. How digital rights management works. http://computer. howstuffworks.com/drm.htm. 7 [25] LEK. The cost of movie piracy. Analysis, LEK, 2004. http://austg. com/include/downloads/PirateProfile.pdf. 3 [26] St´ephane Manuel. Classification and generation of disturbance vectors for collision attacks against sha-1. Technical report, CRI - Paris Rocquencourt, . 17 - 48 - LITTERATUR [27] Microsoft. Earnings release fy10 q1. http://www.microsoft.com/ investor/EarningsAndFinancials/Earnings/Kpi/fy10/Q1/Detail. aspx. 2, 3 [28] MPAA. Types of content theft. http://www.mpaa.org/ contentprotection/types-of-content-theft. 8 [29] Nintendo. Consolidated sales transition by region. //www.nintendo.co.jp/ir/library/historical_data/pdf/ consolidated_sales_e1109.pdf. 2, 3 http: [30] Markus ”Notch”Persson. How piracy works., September 2010. http: //notch.tumblr.com/post/1121596044/how-piracy-works. 10 [31] Piratpartiet. http://www.piratpartiet.dk. 9 [32] Razor. http://www.razor1911.com/. 6 [33] RIAA. Frequently asked questions. Website, 2011. http://www.riaa. com/faq.php. 2 [34] Dorrit Saietz and Rune Eltard-Sørensen. Pirater p˚ a internet f˚ ar frit spil. Politiken, 1:1, November 2009. http://politiken.dk/kultur/ article828707.ece. 7 [35] Bruce Schneier. Applied Cryptography, Second Edition: Protocols, Algorthms, and Source Code in C. Wiley Computer Publishing, 1996. 15, 16, 18, 19, 20 [36] Sony. Psp worldwide hardware unit sales. http://www.scei.co.jp/ corporate/data/bizdatapsp_sale_e.html. 2, 3 [37] Dengguo Feng Tao Xie. How to find weak input differences for md5 collision attacks. Technical report, Chinese Academy of Sciences og The Center for Soft-Computing and Cryptology, . 17 [38] Jeff Tyson. How encryption works. http://computer.howstuffworks. com/encryption.htm. 13, 14 [39] Martin Vilcans. The real problem with software piracy, Februar 2008. http://www.librador.com/2008/02/01/ The-Real-Problem-with-Software-Piracy/. 5 [40] Eric Weisstein. Boolean function. http://mathworld.wolfram.com/ BooleanFunction.html. 16 - 49 - LITTERATUR [41] Marcus Yam. Ubisoft’s drm for assassin’s creed ii is cracked, April 2010. http://www.tomshardware.com/news/ assassins-creed-crack-hack-drm-ac2,10260.html. 7 [42] Lei Wang og Kazumaro Aoki Yu Sasaki. Preimage attacks on 41step sha-256 and 46-step sha-512. Technical report, NTT Information Sharing Platform Laboratories og The University of ElectroCommunications, . 17 - 50 - Del I Kildekode 51 Bilag A Applikationen main 1 i n t main ( ) { 3 pthread t tid ; p i d t pid ; 5 int c = 1; 7 p t h r e a d c r e a t e (& t i d , NULL, thread , NULL) ; 9 w h i l e ( t l o P != 1 && c != 0 ) { /∗ ∗ PROGRAMKODE START ∗/ /∗ ∗ PROGRAMKODE AFSLUTTET ∗/ } 11 13 15 17 19 //KONTROL AF AFSLUTNING i f ( t l o P == 1 ) exit ; e l s e i f ( c == 0 ) exit ; else p r i n t f ( ” A f s l u t t e d e pga ukendt f e j l ! \ n” ) ; 21 23 25 27 return 0; } 52 void *thread v o i d ∗ t h r e a d ( v o i d ∗ argument ) 2 { //VARIABLER 4 int status , signatureResult , bytesCopiedFile , signatureMaxLength = 1 0 0 , tMax , tCur , run = 0 ; long kSize , hSize ; 6 v o i d ∗ s i g n a t u r e F i l e , ∗ hsh , ∗ s i g n a t u r e N e w V a l u e F i l e , ∗ b u f f e r ; FILE ∗ k F i l e , ∗ h s h f l ; 8 CRYPT CONTEXT h a s h F i l e , p r i v a t e K e y ; 10 CRYPT KEYSET c r y p t K e y s e t ; CRYPT HANDLE publicKey ; 12 //INITIALISERE CRYPTLIB 14 status = cryptInit () ; i f ( s t a t u s != CRYPT OK) 16 { p r i n t f ( ”CRYPTLIB INITIALISATION FAILED ! ” ) ; 18 } 20 22 do { ˚BNER KEYSET //A cryptKeysetOpen (& c r y p t K e y s e t , CRYPT UNUSED, CRYPT KEYSET FILE, ” /PATH/TO/KEY/FILE” , CRYPT KEYOPT READONLY) ; 24 26 28 30 ˚BNER KONTROLFILEN ”K. c f ” //A k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f s e e k ( k F i l e , 0 , SEEK END) ; kSize = f t e l l ( kFile ) ; rewind ( k F i l e ) ; b u f f e r = malloc ( s i z e o f ( char ) ∗ kSize ) ; fread ( buffer , 1 , kSize , kFile ) ; 32 34 36 38 40 //INITIALISERE KEYSET OG CONTEXT c r y p t G e t P r i v a t e K e y ( c r y p t K e y s e t , &privateKey , CRYPT KEYID NAME, ”B220” , ”B220” ) ; cryptGetPublicKey ( c r y p t K e y s e t , &publicKey , CRYPT KEYID NAME, ”B220” ) ; c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; //HASH AF FILINDHOLD cryptEncrypt ( hashFile , kFile , kSize ) ; cryptEncrypt ( hashFile , kFile , 0) ; - 53 - BILAG A. APPLIKATIONEN 42 //SIGNERE HASH FILE c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , h a s h F i l e ) ; s i g n a t u r e F i l e = m a l l o c ( signatureMaxLength ) ; c r y p t C r e a t e S i g n a t u r e ( s i g n a t u r e F i l e , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , h a s h F i l e ) ; 44 46 cryptDestroyContext ( hashFile ) ; 48 //˚ ABNER FILEN MED SIGNATUREN h s h f l = f o p e n ( ” h s h f l . s i g ” , ” rb ” ) ; f s e e k ( h s h f l , 0 , SEEK END) ; hSize = f t e l l ( hshfl ) ; rewind ( h s h f l ) ; hsh = m a l l o c ( s i z e o f ( c h a r ) ∗ h S i z e ) ; f r e a d ( hsh , 1 , h S i z e , h s h f l ) ; fclose ( hshfl ) ; 50 52 54 56 58 //LAVER CONTEXT TIL HASH c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; 60 //HASHER K. c f cryptEncrypt ( hashFile , kFile , kSize ) ; cryptEncrypt ( hashFile , kFile , 0) ; 62 64 fcl ose ( kFile ) ; 66 68 //SAMMENLIGNER SIGNATUR s i g n a t u r e R e s u l t = c r y p t C h e c k S i g n a t u r e ( hsh , b y t e s C o p i e d F i l e , publicKey , h a s h F i l e ) ; 70 cryptDestroyContext ( hashFile ) ; 72 i f ( s i g n a t u r e R e s u l t == CRYPT ERROR SIGNATURE) { p r i n t f ( ”SIGNATURE NOT VERIFY! \ n” ) ; tloP = 1; } e l s e i f ( s i g n a t u r e R e s u l t == CRYPT ERROR NOTFOUND) { p r i n t f ( ”THE KEY NEEDED WAS NOT FOUND\n” ) ; tloP = 1; } else { p r i n t f ( ”A WIZARD STOLE YOUR DATA. SORRY! \ n” ) ; tloP = 1; 74 76 78 80 82 84 - 54 - 86 } 88 //TÆLLER K. c f EN OP HVIS DER ER MERE PRØVETID, ELLERS LUKKES PROGRAMMET i f ( s i g n a t u r e R e s u l t == CRYPT OK) { k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f g e t s ( buffer , 100 , k F i l e ) ; fcl ose ( kFile ) ; s s c a n f ( b u f f e r , ”%d %d” , &tMax , &tCur ) ; 90 92 94 96 98 100 i f ( tCur < tMax ) { tCur += 1 ; k F i l e = f o p e n ( ”K. c f ” , ”w” ) ; f p r i n t f ( k F i l e , ”%d %d” , tMax , tCur ) ; fflush ( kFile ) ; 102 c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; 104 106 108 110 free ( buffer ) ; k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f s e e k ( k F i l e , 0 , SEEK END) ; kSize = f t e l l ( kFile ) ; rewind ( k F i l e ) ; b u f f e r = malloc ( s i z e o f ( char ) ∗ kSize ) ; fread ( buffer , 1 , kSize , kFile ) ; 112 114 116 118 120 //HASH AF FILINDHOLD cryptEncrypt ( hashFile , kFile , kSize ) ; cryptEncrypt ( hashFile , kFile , 0) ; fc lose ( kFile ) ; //SIGNERE HASH FILE c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , h a s h F i l e ) ; s i g n a t u r e N e w V a l u e F i l e = m a l l o c ( signatureMaxLength ) ; cryptCreateSignature ( signatureNewValueFile , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , hashFile ) ; 122 124 126 //SKRIVER SIGNERING TIL FIL h s h f l = f o p e n ( ” h s h f l . s i g ” , ”wb” ) ; f w r i t e ( signatureNewValueFile , 1 , bytesCopiedFile , hshfl ) ; fflush ( hshfl ) ; fclose ( hshfl ) ; 128 - 55 - BILAG A. APPLIKATIONEN cryptDestroyContext ( hashFile ) ; } else { p r i n t f ( ”END OF TIME\n” ) ; run = 1 ; break ; } } else { p r i n t f ( ”ACCESS DENIED\n” ) ; run = 1 ; break ; } 130 132 134 136 138 140 142 144 cryptKeysetClose ( cryptKeyset ) ; cryptDestroyContext ( privateKey ) ; c r y p t D e s t r o y O b j e c t ( publicKey ) ; 146 148 s t a t u s = cryptEnd ( ) ; i f ( s t a t u s != CRYPT OK) { p r i n t f ( ”CRYPTLIB SHUTDOWN FAILED\n” ) ; } 150 152 154 sleep (2) ; } w h i l e ( run == 0 ) ; 156 158 tloP = 1; exit ; 160 r e t u r n (NULL) ; 162 } - 56 - Bilag B Applikation eksempel v o i d Penge ( i n t penge , i n t ∗ Penge10 , i n t ∗ Penge20 , i n t ∗ Penge50 , i n t ∗ Penge100 ) 2 { i n t Pen10 , Pen20 , Pen50 , Pen100 ; 4 i n t tempPen ; ∗ Penge100 = Pen100 = penge tempPen = penge % 1 0 0 ; ∗ Penge50 = Pen50 = tempPen tempPen = tempPen % 5 0 ; ∗ Penge20 = Pen20 = tempPen tempPen = tempPen % 2 0 ; ∗ Penge10 = Pen10 = tempPen 6 8 10 12 / 100; / 50; / 20; / 10; } 14 i n t main ( ) 16 { pthread t tid ; 18 p i d t pid ; int c = 1; 20 p t h r e a d c r e a t e (& t i d , NULL, thread , NULL) ; 22 w h i l e ( t l o P != 1 && c != 0 ) 24 { /∗ 26 ∗ PROGRAMKODE START ∗/ 28 i n t temPen = 0 , Pen10 = 0 , Pen20 = 0 , Pen50 = 0 , Pen100 = 0; 30 p r i n t f ( ” I n d t a s t e t a n t a l penge : \ n” ) ; s c a n f ( ”%d” , &temPen ) ; 57 BILAG B. APPLIKATION EKSEMPEL 32 Penge ( temPen , &Pen10 , &Pen20 , &Pen50 , &Pen100 ) ; 34 p r i n t f ( ” Penge d e r kommer ud a f automaten : \n%d 100− penge \n%d 50−penge \n%d 20−penge \n%d 10−penge ” , Pen100 , Pen50 , Pen20 , Pen10 ) ; /∗ ∗ PROGRAMKODE AFSLUTTET ∗/ 36 38 } 40 //KONTROL AF AFSLUTNING i f ( t l o P == 1 ) exit ; e l s e i f ( c == 0 ) exit ; else p r i n t f ( ” A f s l u t t e d e pga ukendt f e j l ! \ n” ) ; 42 44 46 48 return 0; 50 } - 58 - Bilag C Kildekode 1 #i n c l u d e < s t d l i b . h> #i n c l u d e <s t d i o . h> 3 #i n c l u d e <s t r i n g . h> #i n c l u d e <u n i s t d . h> 5 #i n c l u d e <p t h r e a d . h> #i n c l u d e ” c r y p t l i b . h” 7 v o i d ∗ t h r e a d ( v o i d ∗ argument ) ; 9 i n t tloP = 0; 11 p t h r e a d m u t e x t l o c k ; 13 i n t main ( ) { 15 pthread t tid ; p i d t pid ; 17 int c = 1; 19 p t h r e a d c r e a t e (& t i d , NULL, thread , NULL) ; 21 w h i l e ( t l o P != 1 && c != 0 ) { /∗ ∗ PROGRAMKODE ∗/ /∗ ∗ PROGRAMKODE AFSLUTTET ∗/ } 23 25 27 29 31 33 //KONTROL AF AFSLUTNING i f ( t l o P == 1 ) exit ; 59 BILAG C. KILDEKODE e l s e i f ( c == 0 ) exit ; else p r i n t f ( ” A f s l u t t e d e pga ukendt f e j l ! \ n” ) ; 35 37 39 return 0; } 41 v o i d ∗ t h r e a d ( v o i d ∗ argument ) 43 { //VARIABLER 45 int status , signatureResult , bytesCopiedFile , signatureMaxLength = 1 0 0 , tMax , tCur , run = 0 ; long kSize , hSize ; 47 v o i d ∗ s i g n a t u r e F i l e , ∗ hsh , ∗ s i g n a t u r e N e w V a l u e F i l e , ∗ b u f f e r ; FILE ∗ k F i l e , ∗ h s h f l ; 49 CRYPT CONTEXT h a s h F i l e , p r i v a t e K e y ; 51 CRYPT KEYSET c r y p t K e y s e t ; CRYPT HANDLE publicKey ; 53 //INITIALISERE CRYPTLIB 55 status = cryptInit () ; i f ( s t a t u s != CRYPT OK) 57 { p r i n t f ( ”CRYPTLIB INITIALISATION FAILED ! ” ) ; 59 } 61 do { ˚BNER KEYSET //A cryptKeysetOpen (& c r y p t K e y s e t , CRYPT UNUSED, CRYPT KEYSET FILE, ” /PATH/TO/KEY/FILE” , CRYPT KEYOPT READONLY) ; 63 65 ˚BNER KONTROLFILEN ”K. c f ” //A k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f s e e k ( k F i l e , 0 , SEEK END) ; kSize = f t e l l ( kFile ) ; rewind ( k F i l e ) ; b u f f e r = malloc ( s i z e o f ( char ) ∗ kSize ) ; fread ( buffer , 1 , kSize , kFile ) ; 67 69 71 73 //INITIALISERE KEYSET OG CONTEXT c r y p t G e t P r i v a t e K e y ( c r y p t K e y s e t , &privateKey , CRYPT KEYID NAME, ”B220” , ”B220” ) ; cryptGetPublicKey ( c r y p t K e y s e t , &publicKey , CRYPT KEYID NAME, ”B220” ) ; 75 - 60 - 77 c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; 79 //HASH AF FILINDHOLD cryptEncrypt ( hashFile , kFile , kSize ) ; cryptEncrypt ( hashFile , kFile , 0) ; 81 83 85 //SIGNERE HASH FILE c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , h a s h F i l e ) ; s i g n a t u r e F i l e = m a l l o c ( signatureMaxLength ) ; c r y p t C r e a t e S i g n a t u r e ( s i g n a t u r e F i l e , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , h a s h F i l e ) ; 87 cryptDestroyContext ( hashFile ) ; 89 91 93 95 97 99 //˚ ABNER FILEN MED SIGNATUREN h s h f l = f o p e n ( ” h s h f l . s i g ” , ” rb ” ) ; f s e e k ( h s h f l , 0 , SEEK END) ; hSize = f t e l l ( hshfl ) ; rewind ( h s h f l ) ; hsh = m a l l o c ( s i z e o f ( c h a r ) ∗ h S i z e ) ; f r e a d ( hsh , 1 , h S i z e , h s h f l ) ; fclose ( hshfl ) ; //LAVER CONTEXT TIL HASH c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; 101 103 //HASHER K. c f cryptEncrypt ( hashFile , kFile , kSize ) ; cryptEncrypt ( hashFile , kFile , 0) ; 105 fcl ose ( kFile ) ; 107 109 //SAMMENLIGNER SIGNATUR s i g n a t u r e R e s u l t = c r y p t C h e c k S i g n a t u r e ( hsh , b y t e s C o p i e d F i l e , publicKey , h a s h F i l e ) ; 111 cryptDestroyContext ( hashFile ) ; 113 i f ( s i g n a t u r e R e s u l t == CRYPT ERROR SIGNATURE) { p r i n t f ( ”SIGNATURE NOT VERIFY! \ n” ) ; tloP = 1; } e l s e i f ( s i g n a t u r e R e s u l t == CRYPT ERROR NOTFOUND) { p r i n t f ( ”THE KEY NEEDED WAS NOT FOUND\n” ) ; 115 117 119 - 61 - BILAG C. KILDEKODE 121 tloP = 1; } else { p r i n t f ( ”A WIZARD STOLE YOUR DATA. SORRY! \ n” ) ; tloP = 1; } 123 125 127 129 //TÆLLER K. c f EN OP HVIS DER ER MERE PRØVETID, ELLERS LUKKES PROGRAMMET i f ( s i g n a t u r e R e s u l t == CRYPT OK) { k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f g e t s ( buffer , 100 , k F i l e ) ; fcl ose ( kFile ) ; 131 133 135 s s c a n f ( b u f f e r , ”%d %d” , &tMax , &tCur ) ; 137 i f ( tCur < tMax ) { tCur += 1 ; k F i l e = f o p e n ( ”K. c f ” , ”w” ) ; f p r i n t f ( k F i l e , ”%d %d” , tMax , tCur ) ; fflush ( kFile ) ; 139 141 143 145 c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; 147 free ( buffer ) ; k F i l e = f o p e n ( ”K. c f ” , ” r ” ) ; f s e e k ( k F i l e , 0 , SEEK END) ; kSize = f t e l l ( kFile ) ; rewind ( k F i l e ) ; b u f f e r = malloc ( s i z e o f ( char ) ∗ kSize ) ; fread ( buffer , 1 , kSize , kFile ) ; 149 151 153 155 157 //HASH AF FILINDHOLD cryptEncrypt ( hashFile , kFile , kSize ) ; cryptEncrypt ( hashFile , kFile , 0) ; 159 fc lose ( kFile ) ; 161 //SIGNERE HASH FILE c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , h a s h F i l e ) ; s i g n a t u r e N e w V a l u e F i l e = m a l l o c ( signatureMaxLength ) ; cryptCreateSignature ( signatureNewValueFile , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , hashFile ) ; 163 - 62 - 165 167 169 //SKRIVER SIGNERING TIL FIL h s h f l = f o p e n ( ” h s h f l . s i g ” , ”wb” ) ; f w r i t e ( signatureNewValueFile , 1 , bytesCopiedFile , hshfl ) ; fflush ( hshfl ) ; fclose ( hshfl ) ; 171 173 175 177 179 181 183 185 cryptDestroyContext ( hashFile ) ; } else { p r i n t f ( ”END OF TIME\n” ) ; run = 1 ; break ; } } else { p r i n t f ( ”ACCESS DENIED\n” ) ; run = 1 ; break ; } 187 189 cryptKeysetClose ( cryptKeyset ) ; cryptDestroyContext ( privateKey ) ; c r y p t D e s t r o y O b j e c t ( publicKey ) ; 191 193 195 s t a t u s = cryptEnd ( ) ; i f ( s t a t u s != CRYPT OK) { p r i n t f ( ”CRYPTLIB SHUTDOWN FAILED\n” ) ; } 197 199 201 sleep (2) ; } w h i l e ( run == 0 ) ; tloP = 1; exit ; 203 r e t u r n (NULL) ; 205 } - 63 - Bilag D Kode til generering af nødvendige filer Kpub & Kpriv 1 /∗ ∗ −L . − l c l −l p t h r e a d − l r e s o l v 3 ∗/ #i n c l u d e <s t d i o . h> 5 #i n c l u d e < s t d l i b . h> #i n c l u d e <s t r i n g . h> 7 #i n c l u d e ” c r y p t l i b . h” 9 i n t main ( ) { 11 int status ; c h a r l a b e l [ ] = ”B220” ; 13 int labelLenght = 4; CRYPT CONTEXT sigKeyContext ; 15 CRYPT KEYSET c r y p t K e y s e t ; CRYPT CERTIFICATE c r y p t C e r t i f i c a t e ; 17 //CRYPTLIB INITIALISATION 19 status = cryptInit () ; i f ( s t a t u s != CRYPT OK) 21 { p r i n t f ( ”CRYPTLIB INITIALISATION FAILED ! ” ) ; 23 } 25 //INITIALISATION AF CONTEXT c r y p t C r e a t e C o n t e x t (& sigKeyContext , CRYPT UNUSED, CRYPT ALGO RSA) ; 27 64 29 31 //LABLER c r y p t S e t A t t r i b u t e S t r i n g ( sigKeyContext , CRYPT CTXINFO LABEL, label , labelLenght ) ; //LAVER KEY cryptGenerateKey ( sigKeyContext ) ; 33 35 //LAVER KEYSET cryptKeysetOpen (& c r y p t K e y s e t , CRYPT UNUSED, CRYPT KEYSET FILE, ” k e y s . p15 ” , CRYPT KEYOPT CREATE) ; cryptAddPrivateKey ( c r y p t K e y s e t , sigKeyContext , ”B220” ) ; 37 39 41 43 45 47 49 51 //LAVER CERTIFICAT c r y p t C r e a t e C e r t (& c r y p t C e r t i f i c a t e , CRYPT UNUSED, CRYPT CERTTYPE CERTIFICATE) ; cryptSetAttribute ( cryptCertificate , CRYPT CERTINFO SELFSIGNED, 1 ) ; c r y p t S e t A t t r i b u t e ( c r y p t C e r t i f i c a t e , CRYPT CERTINFO CA, 1 ) ; //GØR DET MULIGT AT SIGNE MED CERTIFIKAT c r y p t S e t A t t r i b u t e ( c r y p t C e r t i f i c a t e , CRYPT CERTINFO KEYUSAGE, CRYPT KEYUSAGE DIGITALSIGNATURE | CRYPT KEYUSAGE KEYENCIPHERMENT) ; //SIGNERE CERTIFICAT c r y p t S i g n C e r t ( c r y p t C e r t i f i c a t e , sigKeyContext ) ; cryptAddPublicKey ( c r y p t K e y s e t , c r y p t C e r t i f i c a t e ) ; //LUKKER c r y p t D e s t r o y C o n t e x t ( sigKeyContext ) ; cryptKeysetClose ( cryptKeyset ) ; cryptDestroyCert ( c r y p t C e r t i f i c a t e ) ; 53 55 57 s t a t u s = cryptEnd ( ) ; i f ( s t a t u s != CRYPT OK) { p r i n t f ( ”CRYPTLIB SHUTDOWN FAILED\n” ) ; } 59 return 0; 61 } - 65 - BILAG D. KODE TIL GENERERING AF NØDVENDIGE FILER U 1 /∗ ∗ −L . − l c l −l p t h r e a d − l r e s o l v 3 ∗/ #i n c l u d e <s t d i o . h> 5 #i n c l u d e < s t d l i b . h> #i n c l u d e <s t r i n g . h> 7 #i n c l u d e ” c r y p t l i b . h” 9 #d e f i n e b u f f e r S i z e 100 11 i n t main ( ) { 13 int status , signatureResult , bytesCopiedFile , signatureMaxLength = 1 0 0 , tMax , tCur ; long f S i z e ; 15 v o i d ∗ s i g n a t u r e F i l e , ∗ hsh , ∗ s i g n a t u r e N e w V a l u e F i l e , ∗ b u f f e r ; FILE ∗ k F i l e , ∗ h s h f l ; 17 CRYPT CONTEXT h a s h F i l e , p r i v a t e K e y ; 19 CRYPT KEYSET c r y p t K e y s e t ; CRYPT HANDLE publicKey ; 21 status = cryptInit () ; 23 i f ( s t a t u s != CRYPT OK) { 25 p r i n t f ( ”CRYPTLIB INITIALISATION FAILED ! ” ) ; } 27 cryptKeysetOpen (& c r y p t K e y s e t , CRYPT UNUSED, CRYPT KEYSET FILE, ” /PATH/TO/KEY/FILE” , CRYPT KEYOPT READONLY) ; 29 k F i l e = f o p e n ( ”FDSS . t x t ” , ” r ” ) ; 31 f s e e k ( k F i l e , 0 , SEEK END) ; fSize = f t e l l ( kFile ) ; 33 rewind ( k F i l e ) ; b u f f e r = malloc ( s i z e o f ( char ) ∗ f S i z e ) ; 35 fread ( buffer , 1 , fSize , kFile ) ; fcl ose ( kFile ) ; 37 //INITIALIZERE 39 c r y p t G e t P r i v a t e K e y ( c r y p t K e y s e t , &privateKey , CRYPT KEYID NAME, ”B220” , ”B220” ) ; cryptGetPublicKey ( c r y p t K e y s e t , &publicKey , CRYPT KEYID NAME, ”B220” ) ; 41 c r y p t C r e a t e C o n t e x t (& h a s h F i l e , CRYPT UNUSED, CRYPT ALGO SHA1) ; - 66 - 43 45 //HASH AF FILINDHOLD cryptEncrypt ( hashFile , buffer , b u f f e r S i z e ) ; cryptEncrypt ( hashFile , buffer , 0) ; p r i n t f ( ”%s \n” , ( c h a r ∗ ) b u f f e r ) ; 47 49 51 //SIGNERE HASH FILE c r y p t C r e a t e S i g n a t u r e (NULL, 0 , &signatureMaxLength , privateKey , h a s h F i l e ) ; s i g n a t u r e F i l e = m a l l o c ( signatureMaxLength ) ; c r y p t C r e a t e S i g n a t u r e ( s i g n a t u r e F i l e , signatureMaxLength , &b y t e s C o p i e d F i l e , privateKey , h a s h F i l e ) ; 53 p r i n t f ( ”%s \n” , ( c h a r ∗ ) s i g n a t u r e F i l e ) ; 55 //SKRIVER SIGNERING TIL FIL h s h f l = f o p e n ( ”FDSS . s i g ” , ”wb” ) ; f w r i t e ( signatureFile , 1 , bytesCopiedFile , h s h f l ) ; // f p r i n t f ( h s h f l , ”%s ” , ( c h a r ∗ ) s i g n a t u r e N e w V a l u e F i l e ) ; fflush ( hshfl ) ; fclose ( hshfl ) ; p r i n t f ( ”%d\n” , b y t e s C o p i e d F i l e ) ; 57 59 61 63 65 cryptDestroyContext ( hashFile ) ; cryptKeysetClose ( cryptKeyset ) ; cryptDestroyContext ( privateKey ) ; c r y p t D e s t r o y O b j e c t ( publicKey ) ; 67 69 71 s t a t u s = cryptEnd ( ) ; i f ( s t a t u s != CRYPT OK) { p r i n t f ( ”CRYPTLIB SHUTDOWN FAILED\n” ) ; } 73 return 0; 75 } - 67 - Del II Ordliste 68 Bilag E Ordliste Suite I denne sammenhæng bruges ordet suite om en kode, hvori udvikler tilføjer sin egen kode og p˚ a den m˚ ade opn˚ ar b˚ ade virkningen af suiten og det program der implementeres. Context “Encryption contexts are the action objects used by cryptlib. Action objects are used to act on data, for example to encrypt or decrypt a piece of data or to digitally sign or check the signature on a piece of data” [18, p.29]. Parent proces En parent proces er en proces, som har lavet en eller flere child processer. En child process er en proces som er lavet af en anden proces. Tr˚ ad En tr˚ ad er en process og ved hjælp af multithreading kan man køre flere tr˚ ade p˚ a en gang. cryptUser “Throughout the rest of the cryptlib documentation this parameter is denoted through the use of the cryptUser variable. Usually this parameter is set to CRYPT UNUSED to indicate that the user is acting in the role of a normal user and doesn’t care about role-based controls. This is typically used in cases where there’s only one cryptlib user, for example where cryptlib is running on an end-user PC (e.g. Windows, Macintosh) or a multi-user system 69 BILAG E. ORDLISTE that provides each user with the illusion of being on a single-user machine (e.g. Unix). In almost all cases therefore you’d pass in CRYPT UNUSED as the user identity parameter. In a few specialised cases where the user is acting in a role other than that of a normal user the default user role isn’t enough. For example when you want to access a CA certificate store you can’t use the role of a normal user to perform the access because only a CA can manipulate a certificate store. This prevents a normal user from issuing themselves certificates in the name of the CA and assorted other mischief such as revoking another user’s certificate. When acting in a different role than that of the default, normal user, you specify the identity of the user whose role you’re acting in as a parameter of the object creation function as before, this time passing in the handle of the user identity instead of CRYPT UNUSED. When the object is created, it is associated with the given user and role instead of thedefault user.” - [18, p.47]. Keyset ”A key collection container object that contain collections of public or private keys.- [18, p.31] Heap En datastruktur der garanterer at dataelementer med en større værdi kan allokeres. - 70 - Del III Projektforslag 71 Bilag F Projektforslag At fremme kulturspredning og frihed p˚ a internettet Det initierende problem Hvordan kan man fremme kulturspredning(her tænkes p˚ a musik, film, bøger og spil) eller forhindre den stigende overv˚ agning og datalogging af personlige oplysninger fra ens færden p˚ a internettet. Problemstilling Internetudbydere skal iflg. terrorlovgivningen gemme alt information om deres kunders færden p˚ a internettet. Alt hvad man foretager sig, bliver gemt i logfiler, som offentlige organisationer kan f˚ a adgang til. Dette er ikke kun forbeholdt internetsøgninger, men ogs˚ a personlige e-mail m.m.. Man kan derfor argumentere for, at alt hvad man fortager sig kan findes af andre. Derudover minimerer film- og musikindustrien spredelsen af kultur, med deres forsøg p˚ a at forhindre deling af den kulturelle værdi, deres kreerede værker har. Dermed kan menneskers dannelse og livskvalitet være lavere, hvis der benægtes adgang til kultur. Man bliver med andre ord konstant overv˚ aget og ens personlige og kulturelle frihed er begrænset. Form˚ al Projektets form˚ al er at fremstille en datalogisk model som vil gavne kulturens udbredelse eller forhindre dataloggingen af personlig information fra ens brug af internettet. 72 M˚ al M˚ alet kan være at definere en model som tillader en at færdes p˚ a nettet uden denne færden bliver skrevet til logfiler eller en m˚ ade hvorp˚ a deling af kultur stimuleres. Datalogiske emner Infrastruktur i distribuerende systemer, datamodellering, brugeres privathed og frihed, dataforfalskning, fildeling. Eksempler p˚ a kontekstuelle emner Vil det være muligt at lovliggøre fildeling af alt materiale? Hvilke konsekvenser vil det have hvis der ikke var dataoverv˚ agning(datalogging)? Hvilke konsekvenser vil det have hvis alle kunne f˚ a adgang til disse datalogge? Forslagsstiller DAT1B220 - 73 -
© Copyright 2024