1. No category

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 -