-
Notifications
You must be signed in to change notification settings - Fork 0
/
bijlagen.tex
232 lines (192 loc) · 12.2 KB
/
bijlagen.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
\chapter{Bijlagen}
\section{Opmerkingen cryptografisch expert}
\label{sec:opmerkingen-cryptografisch-expert}
"Dit bleek uiterst gevaarlijk toen de NSA een met opzet gebrekkige random
number generator publiceerde genaamd Dual\_EC\_DRBG. -> referentie nodig.
Daarnaast zou je hierover ook eventueel nog iets kunnen zeggen:
\url{http://www.reuters.com/article/us-usa-security-rsa-idUSBRE9BJ1C220131220}
I.v.m. keysterkte, RNG, hashing, kan je met volgende referentie ook helpen:
\url{http://dx.doi.org/10.6028/NIST.SP.800-131Ar1}
Je punt van snelheidsverlies tegenover securitywinst komt duidelijk over. Je
kan echter best wel vermelden welke hardware (op zijn minst het model van de
CPU en het type RAM vermelden) je bij de metingen gebruikt hebt. Dat kan een
rol spelen in verband van reproduceerbaarheid van de resultaten. Tevens ook
vermelden of je een VM gebruikt hebt. VMs hebben namelijk typisch een slechtere
performance op vlak van crypto dan echte hardware.
Ik mis op het einde nog een stukje conclusie m.b.t. de grootte van de sleutels
die je wil gaan gebruiken. Bij \ref{sec:gebruikte-algoritmes} gaf je duidlijk
aan dat "We kunnen concluderen dat tot ECC-implementaties verder uitgewerkt en
gestandaardiseerd zijn, het best is om RSA te gebruiken.". Zoiets zou hier ook
meerwaarde hebben. Zie bijvoorbeeld opensslspeedtest.txt, waar mijn oude Intel
Core 2 Duo FTPServer het opneemt tegen een mijn Intel Xeon VPS.
Inleiding: hier zou je nog kunnen bijschrijven waarom key distribution zo
kritisch is (MitM natuurlijk).
Inleiding: "Om te zorgen dat elke nieuwe werknemer niet moet persoonlijk zich
identificeren met elke andere werknemer [...]". Ik weet wel dat dat een gevolg
zou zijn van de keuze die je gemaakt hebt voor Web Of Trust, maar dat is voor
de lezer niet direct duidelijk. Ik zou het er expliciet bijzetten.
\subsection{\fullref{subsec:aankomst-nieuwe-werknemer}}
Ik zou hier ook even een kort overzichtje geven met de stappen waardoor een
nieuwe werknemen zal moeten gaan:
1. Keypair genereren;
2. Centrale public key tekenen;
3. Eigen public key naar de server verzenden.
Tim zijn sleutel moet nog gevalideerd worden. Vermeld erbij vanwaar de
centrale sleutel komt. Wie genereert hem? Waar staat hij opgeslagen? Hoe
verifiëren werknemers dat de cetnrale sleutel die zij op hun scherm zien de
juiste is? Welk medium is het meest betrouwbaar? USB? Misschien hangt de
publieke sleutel ergens op een prikbord? Of misschien kan internal IT de
sleutel mee voorinstalleren bij het prepareren van het werkstation van de
werknemer? Welk medium is praktisch het meest haalbaar? Welke afwegingen maak
je hierbij? Security vs convenience. Ongebruiksvriendelijke security is in de
echte wereld een reëel risico. Tegelijkertijd is gebruiksvriendelijke zwakke
security ook niet optimaal.
Geeft deze het juiste vertrouwensniveau -> Verwijs misschien ook naar hoofdstuk
6, voor meer informatie rond vertrouwensniveau's.
"Het proces dat zojuist werd beschreven waarin Tim de centrale sleutel(s)
importeert, kan automatisch gedaan worden door een intern programma." Tot op
zeker niveau wel. De publieke sleutel zal ofwel in de software ingebakken zijn
(in dat geval verifieert Tim best de hash van de software voor hij die
uitvoert), ofwel zal Tim de fingerprint manueel nog moeten ingeven/verifiëren.
"De publieke sleutel van Tim moet nu nog geïmporteerd worden in het netwerk van
het bedrijf en ondertekend worden door de centrale sleutel." Hierbij vermelden
waarom dat nog moet.
" Tim importeert zijn sleutel van de private keyserver [..]" -> Tim
importeert zijn *publieke* sleutel
Waarom moet Tim lokaal een kopie hebben van
zijn door de server ondertekende sleutel? Volgens mij is dat niet echt
noodzakelijk? Iemand die met Tim wil communiceren kan toch evengoed Tim's
sleutel van de private keyserver afhalen? Zal Tim altijd zijn USB stick moeten
bovenhalen om zijn sleutel te delen? Is het zo onredelijk dat een interne
private keyserver minder te vertrouwen dan een USB stick?
"Het is daarom een goed idee om twee USB-apparaten te maken." Het zou in
ieder geval nuttig zijn om een backup te voorzien. Misschien is het zelfs
handiger om het geëncrypteerde volume van de USB stick binnen het
bedrijfsnetwerk ergens te backuppen? Zo vermijd je de risico's en extra vereise
veiligheidsmaatregelen van de volgende subsection.
\subsection{\fullref{subsec:online-opslag-van-de-private-sleutel}}
"De cloud omgeving moet zero knowledge zijn." Een redelijk grote sprong
tussen dit en de vorige paragraaf. Je zou dat kunnen oplossen door iets hoger:
"private sleutel online op te slaan" -> "private sleutel online (i.e. cloud) op
te slaan". Druk "zero knowledge" best ook cursief.
De term "container" komt hier plotseling op de proppen en wordt vanaf dit
punt nog vaak gebruikt. Deze term heb je nergens geïntroduceerd. Daardoor
onstaat verwarring bij de lezer. Ik zou tussen de eerste en tweede paragraaf
een nieuw paragraafje (of twee) schrijven met wat uitleg in logische volgorde:
- Dat je plant om keypairs in de cloud op te slaan.
- Dat je hiervoor cloud zou kunnen gebruiken of eigen infrastructuur.
- Dat cloud eigenlijk toch wel gemakkelijk is omdat je dan zelf geen
infrastructuur moet aanleggen.
- Het kiezen voor cloud komt met bepaalde risico's: je moet de cloud provider
wel ten zeerste vertrouwen.
- Is er geen andere oplossing dan de cloudprovider te vertrouwen?
- Er bestaat zoiets als encrypted containers, die in principe doen wat Fig 7.2
uitbeeldt (bijv. VeraCrypt).
- Die encrypted containers zou je wel veilig in de cloud kunnen uploaden, mits
Zero Knowledge.
- Wat is zero knowledge?
-> De cloud omgeving moet zero knowledge zijn.
De term "hash" heb je ook nog niet geïntroduceerd. Mogelijk past er wel nog
een kort stukje over one-way functions en hashing in Hoofdstuk
\ref{ch:methodologie}? In dat geval
zou ik hier ook zeker naar H\ref{ch:methodologie} refereren. In dat stukje kan
je bijvoorbeeld de
belangrijkste eigenschappen van goeie hashing functies vermelden (met "voor
meer informatie <literatuur referentie>"). Alsook preimage resistance,
second-preimage resistance, collision attack,...
Merk ook op dat je best ook salt wanneer je hasht.
Ah, nu zie ik waarom je een tweede keer dacht te hashen langs de kant van de
server. Is m.i. nog steeds niet nodig hoor :-) Beschouw bijvoorbeeld een
succesvolle MitM. De aanvaller heeft in dit geval de username en H(p). Stel dat
hij erin slaagt om, op een voor de server legitieme wijze, de gebruikersnaam
van het slachtoffer en H(p) aan te bieden. Dan zal de server de versleutelde
container van de user terugsturen. En wat dan nog? Als H een goede hashing
functie is, en er gesalt is geweest, is de kans dat de aanvaller het wachtwoord
van de user kan berekenen astronomisch klein.
En dan nog... zelfs bij slechtere hashing functies is de kans nog steeds klein.
Beeld je bijvoorbeeld in dat we MD5 zouden gebruiken. De kans op een collision
is hierbij enorm groot. Maar, aangezien de container die je opslaat encrypted
is met AES, ben je met een collision niet veel.
Een voorbeeld: stel, ik versleutel mijn container met AES-128 en beveilig met
de passphrase "mysecretpassword". Veronderstel ook dat MD5("mysecretpassword")
= MD5("md5sucks"). Een aanvaller kan vinden dat MD5("md5sucks") dezelfde MD5
hash geeft als de hash die hij heeft afgeluisterd. Echter, geeft "md5sucks"
geen toegang tot de versleutelde container. Daarvoor heb je "mysecretpassword"
nodig.
Ik zou zeggen, hou beide verhalen in je paper! Wat je al hebt en wat ik hier
zojuist heb neergeschreven biedt zeker een toegevoegde waarde voor een
geïnteresseerde lezer!
Let wel, jouw voorbeeld met een extra hashing biedt geen extra beveiliging in
geval van MitM; enkel wanneer de aanvaller niet weet welke hash je serverside
gebruikt. Dat laatste als assumptie nemen, is tegen het Kerckhoffs principe.
Geen goed idee dus :-)
\subsection{\fullref{sec:wachtwoordsterkte}}
"Wachtwoordzinnen zijn een goede oplossing voor het onthouden van langere
wachtwoorden" -> [...], wat de XKCD comic ook aangeeft.
"Het laten vervallen van wachtwoorden is afgeraden[...]". Hier neem je een
minder conventionele stand in. Voor mij is dat ok, maar je stelt het toch best
iets genuanceerder. Het is nog altijd zo dat eens per 90-180 dagen veranderen
van wachtwoord aanbevolen is en technisch gezien extra beveiliging met zich
meebrengt. Daarentegen is het ook waar dat gebruikers echt niet elke 90-180
dagen moeite willen doen om wachtwoorden van 16 of meer karakters van buiten
leren, en er dan weggetjes rond gaan vinden, zoals je al schrijft. Indien ik de
beslissing moest maken, zou ik eens per jaar van wachtwoord veranderen een
acceptabel compromis vinden.
\subsection{\fullref{sec:verlies-wachtwoord-of-private-sleutel}}
"Om de werknemer verder te kunnen laten werken moeten de stappen van een
nieuwe werknemer opnieuw uitgevoerd worden." -> hier zou ik refereren naar
Sectie \ref{subsec:aankomst-nieuwe-werknemer}
"UTF-16 is 1 112 064" -> realistisch gezien gaan gebruikers maximum 95
verschillende karakters gebruiken (ascii tabel - controle characters), dwz
2\textasciicircum95 (ongeveer 4*10\textasciicircum28) mogelijkheden
\section{Opmerkingen cryptografisch expert na aanpassingen}
> > * " Tim importeert zijn sleutel van de private keyserver [..]" -> \\
> > Tim importeert zijn *publieke* sleutel \\
> > -> Je gaat hier de vraag krijgen: waarom moet Tim lokaal een kopie \\
> > hebben van zijn door de server ondertekende sleutel? Volgens mij is \\
> > dat niet echt noodzakelijk? Iemand die met Tim wil communiceren kan \\
> > toch evengoed Tim's sleutel van de private keyserver afhalen? Zal \\
> > Tim altijd zijn USB stick moeten bovenhalen om zijn sleutel te \\
> > delen? Is het zo onredelijk dat een interne private keyserver \\
> > minder te vertrouwen dan een USB stick? \\
> \\
> De reden dat ik dit doet is bijvoorbeeld als Tim zijn public key \\
> bevestigt aan een e-mail, dat de ondertekening door de centrale \\
> sleutel dan al meekomt zonder nog een gpg --refresh-keys uit te \\
> voeren. Alhoewel het refreshen van de sleutel misschien altijd moet \\
> gebeuren om key revocations te controleren. \\
Ah, dus dan gaat iemand die Tim's publieke sleutel vanaf Tim's USB stick \\
afhaalt meteen al zien dat de centrale key server hem al heeft gesignd. \\
Dat kan je er misschien nog wel bij vermelden. \\
Ik vraag me wel af: wanneer de centrale key server Tim's sleutel
ondertekent, kan de centrale keyserver dan meteen de gesignde publieke
sleutel niet aanbieden aan het hele bedrijf? Zodat, wanneer iemand met
Tim wil versleuteld emailen, hij gpg --recv-key <fingerprint> kan
uitvoeren, en niet moet wachten tot Tim eens op kantoor is met zijn USB
stick?
> Bij het voorbeeld \textit{H(H(p))} heb je gelijk dat Mallory niets is met de \\
> geëncrypteerde container. Dit was niet echt bedoeld als beveiliging \\
> tegen een MITM maar eerder in het geval dat er een database breach is \\
> en de inloggegevens lekken. In dat geval kan doorgeven van \textit{H(p)} \\
> toegang krijgt tot een interface die je in staat stelt tot het beheren \\
> van je containers (aanmaken, verwijderen, ...). Maar het doorgeven van \\
> \textit{H(H(p))} zou niets bereiken. \\
Hierin heb je volstrikt gelijk. Vermeld dat ook zeker in je bachelorpaper!
> Over het vervallen van wachtwoorden zeg je dat eens vervallen per jaar \\
> een acceptabel compromis is. Het NIST zegt echter (in de citering van \\
> de vorige paragraaf) dat dit niet meer aangeraden word. \\
Daarvan was ik niet op de hoogte. Misschien ook het vermelden waard
> Wat betreft de Apriv die tijdelijk gedecrypteerd, dit zou gebeuren op \\
> server niveau. Dus de private sleutel van de /access control/ server \\
> zou niet op kaart staan. Ik probeer eigenlijk te vermijden dat een \\
> kaart ongemerkt wordt uitgelezen en dan de PIN ge-bruteforced wordt. \\
> Jouw oplossing met het controleren van de sleutel op de kaartlezer zou \\
> ideaal zijn maar ik vrees ook dat dit soort kaart niet bestaat. \\
Er bestaan wel kaarten die blokkeren nadat driemaal een verkeerde PIN
code ingegeven wordt. Misschien is zo'n systeem ook een alternatief?
Schrijf in ieder geval ook op je scenario op. M.a.w. dat je je probeert
te beschermen tegen bruteforce op de PIN code wanneer iemand de kaart
onrechtmatig bemachtigd heeft en erin slaagt om de data die erop staat
met een third party kaartlezer uit te lezen.
\section{Bachelorproefvoorstel}
\includepdf[pages={-}]{kunnen-matthias-voorstel.pdf}