-
Notifications
You must be signed in to change notification settings - Fork 7
/
netzsicherheit.tex
1420 lines (1273 loc) · 85.3 KB
/
netzsicherheit.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
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\chapter{Netzsicherheit: Architekturen und Protokolle}
Zusammenfassung der Vorlesung "`Netzsicherheit: Architekturen und Protokolle"' aus dem Sommersemester 2017.\footnote{\url{https://telematics.tm.kit.edu/ss2017_3540.php}}
\section{Einführung}
\begin{itemize}
\item Smarte Welt - alles vernetzt. Vorteile beispielsweise: Bessere Integration erneuerbarer Energien, bessere Organisation des Verkehrs \(\rightarrow\) "`assistiertes Leben"'
\item Vernetzte Daten: Sensoren übermitteln die erfassten Daten via Internet an einen zentralen Datenspeicher
\item Problem: Systeme können (beispielsweise über das Internet) angegriffen werden, Daten können von unbefugten Dritten mitgelesen werden
\item Alternative (I): Vollständig verteiltes System. Probleme: Vertrauensbasis? Kontrolle? Nachvollziehbarkeit? Zuverlässigkeit?
\item Alternative (II): Vollständig isoliertes System? Kein Zugriff von außen, daher theoretisch sicher. Praktisch existiert immer eine Verbindung nach außen, z.B. zum Installieren von Updates
\item Randbedinungen bei Sicherheitsbetrachtungen: Technische Möglichkeiten; Kosten; Faktor Mensch
\end{itemize}
\subsection{Security vs. Safety}
\subsubsection{Begriffsdefinitionen}
\begin{itemize}
\item (IT-)System: Gesamtheit von Komponenten, die zusammenwirken, um eine bestimmte Funktionalität zu erfüllen
\item Komponente: Bestandteil eines Systems, das eine Teilfunktion dessen realisiert und über Schnittstellen mit anderen Komponenten kommuniziert
\item Güter: Ressourcen die für mindestens einen Akteur einen (subjektiven) Wert besitzen
\item Schutzziel: Anforderungen an eine Komponente oder ein System, um Güter vor Bedrohungen zu schützen
\item Bedrohung: Die Möglichkeit, Schutzziele \textit{gezielt} zu beeinträchtigen. Beispielsweise Abhören/Manipulieren von Daten, Sabotage, etc.
\item Angreifermodell: Beschreibt die Fähigkeiten eines Angreifers, Angriffe auf ein System durchzuführen (beispielsweise Lokalität, Werkzeuge, kryptografische Fähigkeiten)
\item \textbf{Safety}
\begin{itemize}
\item Zustand des Geschütztsein von schützenswerten Gütern vor bestimmten Gefahren. Beispielsweise Funktions- und Betriebssicherheit zum Schutz der Umgebung und Verhinderung von Personenschäden
\item Ist-Funktionalität von Komponenten stimmt mit der Soll-Funktionalität überein
\end{itemize}
\item \textbf{Security}
\begin{itemize}
\item Angriffssicherheit
\item Bedrohung durch böswilligen Angreifer
\item Beispielsweise Schutz der Integrität von Informationen
\end{itemize}
\end{itemize}
\subsection{Schutzziele}
\begin{itemize}
\item \textbf{Vertraulichkeit (Confidentiality)}
\begin{itemize}
\item Ein System bewahrt Vertraulichkeit, wenn es keine unautorisierte Informationsgewinnung ermöglicht
\item Bausteine: Symmetrische oder asymmetrische Verschlüsselung
\end{itemize}
\item \textbf{Integrität (Integrity)}
\begin{itemize}
\item Starke Integrität: Es ist nicht möglich, Daten unautorisiert zu manipulieren
\item Schwache Integrität: Es ist nicht möglich, Daten unautorisiert \textit{unbemerkt} zu manipulieren. Manipulation ist in vielen Fällen nicht verhinderbar, sollte dann aber nicht unbemerkt bleiben
\item Bausteine: Tamper proof Module, Message Authentication Codes (MAC)
\end{itemize}
\item \textbf{Authentizität}
\begin{itemize}
\item Echtheit von Subjekten und/oder Daten
\item Bausteine: Zertifikate, Signaturen, gemeinsames Geheimnis
\end{itemize}
\end{itemize}
\subsection{Typische Angriffe}
\begin{itemize}
\item \textbf{Angreifermodell}
\begin{itemize}
\item Idee: Klassifikation von Angreifern nach Ressourcen/Motivation/Fähigkeiten zur Bestimmung des Sicherheitsniveaus (Gegen welche Art von Angreifer will/kann ich mich schützen?)
\item Dolev-Yao-Angreifer: Angreifer ist omnipräsent, kann Dateneinheiten erzeugen/versenden/modifizieren, kann allerdings nicht ver- oder entschlüsseln ohne den Schlüssel zu kennen (Angreifer einspricht "`Outsider"')
\item "`Insider"': Angreifer analysiert/korrumpiert Protokollabläufe
\end{itemize}
\item \textbf{Systematische Einordnung von Angriffen}
\begin{itemize}
\item Passiv: Unautorisierte Informationsgewinnung \(\rightarrow\) Vertraulichkeit
\item Aktiv: Unautorisierte Manipulation \(\rightarrow\) Integrität/Verfügbarkeit
\item Typische Angriffstechniken: Abhören/Zwischenschalten (beispielsweise MitM)/Manipulieren/Unterdrücken/Einfügen (beispielsweise DoS)/Replay
\end{itemize}
\end{itemize}
\subsection{Schutzmechanismen und Bausteine}
\begin{itemize}
\item \textbf{Kryptografische Bausteine}
\begin{itemize}
\item Symmetrische oder asymmetrische Verschlüsselung
\item Integritätssicherung durch kryptografische Hashfunktion oder digitale Signatur
\begin{itemize}
\item Über die Nutzendaten wird ein Message Authentication Code (MAC) berechnet und an diese angehängt
\item Eigenschaften kryptografischer Hashfunktionen
\begin{itemize}
\item Einwegeigenschaft: Ist ist schwierig, das Urbild eines Hashes zu finden
\item Schwache Kollisionsresistenz: Es ist schwierig, eine Kollision zu einem gegebenen \(a\) zu finden
\item Starke Kollisionsresistenz: Ist ist schwierig, zwei beliebige, verschiedene Urbilder mit selbem Hash zu finden
\end{itemize}
\end{itemize}
\item Keyed-Hashing for Message Authentication (HMAC)
\begin{itemize}
\item Idee: Angreifer soll nach Verändern der Daten keine gültigen Hash berechnen können
\item Berechnung (\(opad\) und \(ipad\) sind fest definierte Konstante; Finalisierung der Merkle-Damgârd-Konstruktion wichtig, da sonst "`Verlängerung"' möglich)
\end{itemize}
\item Authenticated Encryption with Associated Data (Galois Counter Mode): Erst verschlüsseln und danach MAC berechnen, da sonst \textit{Chosen Ciphertext Attack} möglich
\end{itemize}
\item \textbf{Authentifizierung}
\begin{itemize}
\item Dient der Überprüfung, ob ein Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein
\item Möglichkeiten: (Kombination aus) Besitz/Wissen/Biometrisches Merkmal
\item Mechanismen und Bausteine
\begin{itemize}
\item Passwörter oder Passwort-Hashes: Authentifikation durch Nachweis eines Geheimnissen. Nachteile u.a.: Passwortliste notwendig (Ziel für Angreifer), Passwort muss übertragen werden (Vertraulichkeit eventuell gefährdet); oft schlechte Wahl der Passwörter
\item Challenge-Response-Authentifizierung: Vergleichbare Probleme wie bei Passwörtern
\end{itemize}
\end{itemize}
\item \textbf{Zertifikate}
\begin{itemize}
\item Authentifizierung eines Sachverhalts, den man nicht selbst überprüfen, kann durch vertrauenswürdige Dritte (CA)
\item Digitales Dokument, in dem eine Instanz einen bestimmten Sachverhalt mittels digitaler Signatur bestätigt
\end{itemize}
\end{itemize}
\section{Schlüsselaustausch}
\subsection{Problemstellung}
\begin{itemize}
\item Wie können Schlüssel sicher über einen ungesicherten Kanal ausgetauscht werden?
\item \textbf{Statische Ansätze}
\begin{itemize}
\item Persönliche Übergabe: Sehr einfach und mit automatischer Authentifizierung, allerdings persönliches Treffen notwendig und schlechte Skalierung
\item Statisch ohne persönliches Treffen: Hinterlegen des Schlüsselmaterials bei einer vertrauenswürdigen Instanz
\begin{itemize}
\item Vertrauenswürdige Verwaltung der Schlüssel; Herausgabe auf Anfrage der Kommunikationsteilnehmer
\item Vorteile: Einfaches Verfahren, kein persönliches Treffen notwendig, weniger Schlüssel bei den Kommunikationspartnern zu speichern
\item Nachteile: Sicherer Kanal erforderlich, Schlüssel nur indirekt authentifiziert, zentrale Infrastuktur notwendig (Gefahr durch Ausfälle oder Korruption)
\end{itemize}
\end{itemize}
\item \textbf{Dynamische Ansätze}
\begin{itemize}
\item Nutzung asymmetrischer Verfahren (beispielsweise RSA)
\item Austausch eines geheimen, symmetrischen Sitzungsschlüssels über einen nicht vertrauenswürdigen Kanal
\begin{itemize}
\item Verschlüsselung des Sitzungsschlüssel mit öffentlichem Schlüssel des Kommunikationspartners
\item Vorteile: Kein persönliches Treffen oder zentrale Infrastruktur notwendig, Sitzungsschlüssel sind nach Prüfung der öffentlichen Schlüssel authentifiziert
\item Nachteile: Sitzungsschlüssel an langlebiges Geheimnis gebunden (keine Perfect Forward Secrecy), rechenintensiv
\end{itemize}
\item Diffie-Hellman-Verfahren
\begin{itemize}
\item Vorteile: Kein persönliches Treffen oder zentrale Infrastruktur notwendig, dynamische Aushandlung \(\rightarrow\) Perfect Forward Secrecy durch Verwendung von kurzlebigen Sitzungsschlüsseln
\item Nachteile: Schlüssel nicht authentifiziert, sehr rechenintensiv
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Diffie-Hellman}
\begin{itemize}
\item Problemstellung: Wie können Schlüssel sicher über einen ungesicherten Kanal ausgetauscht werden?
\item Vorgehen: Alice und Bob einigen sich auf eine hinreichend große, zyklische Gruppe \(\mathbb{G} = \langle g \rangle\) mit Ordnung \(p\) (eine hinreichend große Primzahl) sowie einer jeweils individuellen Zufallszahl\footnote{Grafik entnommen aus \url{https://github.com/skript-sicherheit/skript}}
\begin{figure}[h]
\begin{center}
\begin{tikzpicture}[x=2em, y=2em]
\draw (-6,0) node (Alice) {\texttt{Alice}};
\draw (-6,-0.5) node (AliceSk) {Geheimnis: $x$};
\draw (6,0) node (Bob) {\texttt{Bob}};
\draw (6,-0.5) node (BobSk) {Geheimnis: $y$};
% Lebenslinien
\draw[dashed] (AliceSk) -- (-6,-3.25);
\draw[dashed] (BobSk) -- (6,-3.25);
% Pfeile fuer Nachrichten
\textbf{\draw[->, thick] (-5.7,-1) -- (5.7,-1.5) node[sloped,above,pos=0.5] {$g^x~mod~p$};}
\textbf{\draw[->, thick] (5.7,-2.5) -- (-5.7,-3) node[sloped,above,pos=0.5] {$g^y~mod~p$};}
% Beschriftung Ergebnis
\draw (-6, -3.75) node {$(g^y)^x~mod~p$};
\draw (-3, -3.75) node {$=$};
\draw (0, -3.75) node {$g^{xy}~mod~p$};
\draw (3, -3.75) node {$=$};
\draw (6, -3.75) node {$(g^x)^y~mod~p$};
\end{tikzpicture}
\end{center}
\end{figure}
\FloatBarrier
\item Sicherheit des Verfahrens: Es ist schwierig, den diskreten Logarithmus in einem Primzahlkörper zu berechnen
\item Vorteile: Keine Infrastruktur notwendig, geheime Zufallszahlen werden nach dem Schlüsselaustausch gelöscht \(\rightarrow\) \textit{Perfect Forward Secrecy}
\item Nachteile: Anonymer Schlüsselaustausch \(\rightarrow\) keine Authentifizierung der Teilnehmer, MitM-Angriffe möglich, rechenintensiv (und damit anfällig für DoS-Angriffe)
\end{itemize}
\subsection{Bausteine des Schlüsselaustauschs}
\subsubsection{Schlüsselaustauschprotokolle: Bedrohungen}
\begin{itemize}
\item Man-in-the-Middle-Angriffe: Schlüsselaustausch wird unwissentlich mit dem Angreifer ausgeführt
\item Replay-Attacken: Wiedereinspielungsangriff von zuvor aufgezeichneten Nachrichten
\item Denial-of-Service-Angriffen
\item Downgrade-Attacken: Löschen von starken Algorithmen aus Liste der unterstützten Verfahren zugunsten von veralteten (potentiell schwächeren) Verfahren
\item Missbräuchliche Schlüsselhinterlegung bei einer vertrauenswürdigen Organisation
\end{itemize}
\subsubsection{Bausteine}
\begin{itemize}
\item \textbf{Perfect Forward Secrecy}
\begin{itemize}
\item Authentifizierung mittels langlebigen Geheimnisses, danach Kommunikation über gesicherten Kanal mittels kurzlebigem Sitzungsschlüssel
\item Ziel: Angreifer kann die Kommunikation auch dann nicht entschlüsseln, wenn er die komplette Kommunikation aufgezeichnet hat und das langlebige Geheimnis kennt (Einbruch in Endsysteme)
\item Maßnahmen: Sitzungsschlüssel muss von langlebigem Geheimnis unabhängig sein, alle Sitzungsinformationen müssen nach Beendigung der Sitzung gelöscht werden, langlebiges Geheimnis muss periodisch erneuert werden
\item Beispiel: DH-Austausch mit Authentifizierung. Zusätzlich zu den DH-Parametern werden Signaturen über die Parameter ausgetauscht
\end{itemize}
\item \textbf{Schutz der Identitäten}
\begin{itemize}
\item Problem: Passiver Angreifer kann Identitäten der Kommunikationspartner abhören
\item Lösung: Zunächst anonymer DH-Schlüsselaustausch, danach Übertragung der signierten DH-Parameter (setzt vorherige Kenntnis der öffentlichen Schlüssel oder Zertifikate voraus)
\end{itemize}
\item \textbf{Dynamische Wahl der Verfahren}
\begin{itemize}
\item Dynamische Wahl der genutzten Sicherheitsmechanismen zur Verbesserung der Interoperabilität
\item Vorteile: Einfache Migration zu kryptographisch stärkeren Verfahren sowie Ausschluss gebrochener Verfahren
\item Probleme: Komplexität des Protokolls (Wie werden Sicherheitsmechanismen beschrieben und welche Kombinationen sind zulässig?), Downgrade-Angriff
\end{itemize}
\item \textbf{Verhinderung von Downgrade-Angriffen\footnote{\url{http://www.golem.de/news/browser-downgrade-angriffe-auf-tls-1309-101305.html}}}
\begin{itemize}
\item Ziel des Angreifers: Durch gezielte Verbindungsstörungen dafür sorgen, dass der Client eine Verbindung mit einer älteren Protokollversion durchführt
\item Anfällig sind beispielsweise Browser, die ältere Protokollversionen als Fallback nutzen: Fast alle gängigen Browser (Firefox, Chrome, Safari, Internet Explorer) führen bei Verbindungsabbrüchen ein Downgrade auf SSLv3 durch
\item Lösungsansatz: Erkennen von Manipulationsversuchen durch Integritätsschutz (beispielsweise HMAC) aller gesendeten Nachrichten \(\rightarrow\) Integritätsprüfung des gesamten Verlaufs
\end{itemize}
\item \textbf{Einschränkung von DoS-Angriffen}
\begin{itemize}
\item Ziel: Keine Durchführung von rechenintensiven Operationen, solange nicht klar ist, dass die Absenderadresse nicht gefälscht ist
\item Möglichkeiten zur Echtheitsprüfung des Anfragenden
\begin{itemize}
\item Token/Cookie: Enthält zufällige Informationen des Angefragten. Wird es zurückgesendet, ist mit hoher Wahrscheinlichkeit die Absenderadresse nicht gefälscht (beispielsweise durch IP-Spoofing)
\item Puzzle: Stellen einer rechenintensiven Aufgabe an den Anfragenden. Keine lokale Zustandshaltung beim Angefragten
\end{itemize}
\item Konzept: Tokens/Cookies
\begin{itemize}
\item Ziel: Serverzustand per Cookie auf Client auslagern \(\rightarrow\) Server muss keinen Zustand pro Anfrage speichern
\item Schutz der Integrität mittels lokalem Geheimnis. Beispielsweise \(HMAC_K\) über die Zustandsdaten
\item Anforderungen: Aktualität, Eindeutigkeit, Unverhersagbarkeit, einfache Erzeugung (hoher Aufwand würde DoS-Angriff begünstigen), leichte Verifikation
\item Erweiterung: Nonce zum Schutz vor Replay-Angriffen
\end{itemize}
\item Sitzungswiederaufnahme
\begin{itemize}
\item Problem: Initialer Schlüsselaufwand häufig teuer, Verbindungsabbruch bedingt erneuten Schlüsselaustausch
\item Zustandsbehafteter Ansatz: Zustand nach Schlüsselaustausch wird bei einem Kommunikationspartner gespeichert und kann wiederhergestellt werden (Vgl. TLS-Session-Resumption)
\item Zustandslos (für Bob): Zustand wird komplett in geschütztes Cookie kodiert und ausgelagert. Kann bei Wiederaufnahme der Sitzung vorgelegt werden (Vgl. Tickets bei Kerberos)
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Digitale Zertifikate}
\begin{itemize}
\item Idee: Authentifizierung von Sachverhalte, die man nicht selbst überprüfen kann, durch vertrauenswürdige Dritte
\item Sichere Zuordnung von öffentlichen Schlüsseln und Identitäten der Kommunikationspartner
\item Lösung: Verwendung von Zertifikaten. Authentifizierung hier durch vertrauenswürdige Dritte und Bestätigung durch digitale Signatur (Vgl. Personalauswand/Reisepass)
\item Probleme: Anbieter erfährt wer mit wem kommuniziert; Single-Point-of-Failure; schlechte Skalierung
\item \textbf{Klassifizierung von Zertifikaten}
\begin{itemize}
\item ID-Zertifikat: Bindet öffentlichen Schlüssel an eindeutige Identität (Verwendung beispielsweise bei S/MIME)
\item Attributzertifikat: Bindet Attribute an eindeutige Identität (Verwendung beispielsweise beim elektronischen Führerschein)
\end{itemize}
\end{itemize}
\section{Vertrauensmodelle}
\subsection{Motivation}
\begin{itemize}
\item Idee: Absichern von asymmetrisch verschlüsselter Kommunikation mit Hilfe von digitalen Zertifikaten. Zentrale Frage: Wer erstellt die vertrauenswürdige Instanz?
\item \textbf{Neue Probleme}
\begin{itemize}
\item Vertrauen in die CA, bzw. deren Integrität (und in die Gewissenhaftigkeit der Identitätsprüfung)
\item Gültigkeit der Zertifikate
\item Authentizität des öffentlichen Schlüssels der CA
\item Konflikte, wenn mehrere CAs die selbe Entität signieren
\item Wer steht an der Spitze der CA(-Kette)?
\end{itemize}
\item \textbf{Widerruf digitaler Zertifikate}
\begin{itemize}
\item Widerruf manchmal notwendig, beispielsweise wenn der private Schlüssel verloren gegangen oder korrumpiert worden ist
\item CA stellt signierte \textit{Certificate Revocation List} zur Verfügung
\end{itemize}
\end{itemize}
\subsection{Infrastrukturen}
\subsubsection{Public Key Infrastructure (PKI)}
\begin{itemize}
\item Zentrale Infrastruktur zum Management von ID-Zertifikaten \(\rightarrow\) ermöglicht Authentifizierung öffentlicher Schlüssel
\item \textbf{Anforderungen}
\begin{itemize}
\item Vertrauenswürdigkeit
\item Sicherheit interner Abläufe (Dokumentation soll Vertrauenswürdigkeit erhöhen) und der Signaturschlüssel der CA
\item Effizienz, Skalierbarkeit, Komfort für den Benutzer
\end{itemize}
\item \textbf{Elemente}
\begin{itemize}
\item Benutzer: Person oder Serverinstanz
\item Registration Authority (RA): Implementiert die administrativen Aspekte der PKI, Schnittstelle zwischen Benutzer und CA. I.d.R. offline
\item Certification Authority (CA): Führt die Zertifizierungen durch und ist für den Schutz der eigenen privaten Schlüssel zuständig
\item Verzeichnisdienst (Directory): Verwaltet die Zertifikate (beispielsweise LDAP) und publiziert die Widerrufslisten
\end{itemize}
\end{itemize}
\subsubsection{Privilege Management Infrastructure (PMI)}
\begin{itemize}
\item Access Control List (ACL): Definiert, wer auf eine Ressource zugreifen kann
\item \textbf{Methoden zur Autorisierung}
\begin{itemize}
\item Discretionary Access Control: Individuelle, feingranulare Rechtevergabe pro Benutzer
\item Mandantory Access Control: Benutzer werden klassifiziert und bekommen klassenbezogene Zugriffsrechte
\item (Hierachical) Role-based Access Control: Benutzer werden Rollen zugewiesen, die über entsprechende Rollen verfügen. Ggf. vererbt
\item Attributzertifikat: Attestieren Identitäten ein bestimmtes Privileg (als Attribut implementiert). Zeitlich beschränkt und kann per CRL zurückgerufen werden
\end{itemize}
\item PMIs realisieren Autorisierung auf Basis von Attributzertifikaten. Aufbau mit PKI vergleichbar
\item \textbf{Aufbau einer PMI}
\begin{itemize}
\item Attribute Authority (AA, vgl. CA): vergibt Zugriffsrechte und zertifiziert diese
\item Source of Authority (SOA, vgl. Root CA): Oberste Attribute Autority, zertifiziert alle weiteren Privilegien
\end{itemize}
\end{itemize}
\subsection{Vertrauen/Vertrauensmodelle}
\begin{itemize}
\item Vertrauen: Normal im Alltagsleben, subjektiv, unscharf, gerichtet, kontextgebunden, risikoabhängig, etc.
\item \textbf{Vertrauensmodell (Trust Model)}
\begin{itemize}
\item Beschreibt, welchen Zertifikaten ein Benutzer trauen kann;, wie Vertrauen hergestellt wird und wie dieses Verhalten eingeschränkt/kontrolliert werden kann
\item Vertrauensanker (Trust Anchor): Ausgangspunkt einer Zertifizierungskette (beispielsweise eine Root CA)
\item Modelle
\begin{itemize}
\item Single-CA
\begin{itemize}
\item Eine CA erstellt alle Zertifikate
\item Vorteil: Einzelner Vertrauensanker erleicht die Validierung
\item Nachteile: Globales Vertrauen notwendig, Monopolstellung, Kompromittierung des CA-Schlüssels hat globale Konsquenzen, Skalierung, Single-Point-of-Failure
\end{itemize}
\item Oligarchie von CAs
\begin{itemize}
\item Zertifizierung durch mehrere CAs (Distributed Trust Architecture)
\item Vorteile: Keine Monopolstellung, Kompromittierung hat begrenzte Auwirkung
\item Nachteile: Initiale Prüfung sowie Validierung durch mehrere CAs, mehrere CA-Schlüssel müssen geschützt werden
\end{itemize}
\end{itemize}
\item Transitivität von Vertrauen
\begin{itemize}
\item Notwendig für komplexere Vertrauensmodelle
\item Mathematische Definition: Wenn \(A\) Vertrauen in \(B\) (und dessen Zertifizierungen) hat und \(B\) Vertrauen in \(C\) (und dessen Zertifizierungen), so kann \(A\) auch Vertrauen in \(C\) (und dessen Zertifizierungen) haben
\item Anstatt einem einzigen Zertifikat zu vertrauen werden jetzt Zertifikatsketten zwischen Vertrauensanker und Endpunkt aufgebaut und jede Stufe separat validiert
\end{itemize}
\item Transitive Modelle
\begin{itemize}
\item Oligarchie von CAs mit Delegierung
\begin{itemize}
\item CAs können untergeordnete CAs (Sub-CAs) einsetzen. Dadurch ergeben sich Zertifikatsketten
\item Vorteile: Kompromittierung von CA-Schlüsseln hat begrenzten Wirkungsbereich, Skalierung
\item Nachteile: Höhere CA-Schlüsselzahl notwendig, Validierung aufwendiger
\end{itemize}
\item Top-Down
\begin{itemize}
\item Single-CA mit Delegation und Einschränkunge der Delegation auf Teilbereiche eines hierarchischen Namensraums (beispielsweise DNS oder X.500)
\item Vorteile: Kompromittierung von CA-Schlüsseln hat begrenzten Wirkungsbereich, Skalierung, kontrollierte Delegation
\item Nachteile: Höhere CA-Schlüsselzahl notwendig, Validierung aufwendiger, immer Validierung des ganzen Pfades
\end{itemize}
\item Anarchie
\begin{itemize}
\item Jeder Benutzer fungiert als CA und je nach Bedarf (transitiv) eingesetzt werden (beispielsweise PGP)
\item Vorteil: Auswirkung bei Kompromittierung beschränkt
\item Nachteile: Alle Schlüssel sind CA-Schlüssel, Skalierbarkeit (hohe Anzahl Schlüssel \(\rightarrow\) Pfadfindung schwer, da nicht eindeutig), keine einheitliche Zertifizierungspolitik (Transitivität von Vertrauen problematisch), Zertifizierungen schwer kontrollierbar/einschränkbar
\end{itemize}
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Beispielprotokolle}
\subsubsection{X.509}
\begin{itemize}
\item Bekanntester und verbreitetster Standard für Zertifikate
\item Erweiterungsmöglichkeit duch optionale Parameter; auch als Attributzertifikat verwendbar
\item Aktive Nutzung: SSL/TLS, S/MIME, IPsec, etc.
\item Hierarchisches Namensschema: \textit{Distinguished Name} setzt sich aus mehreren Attributen zusammen (beispielsweise Land, Bundestaat, Stadt, etc.)
\item \textbf{Aufbau}
\begin{itemize}
\item Subject: Besitzer des Zertifikats
\item Issuer: ID des Erzeugers des Zertifikats, nächster Schritt in der Zertifikatskette
\item Version/Seriennummer/Signaturalgorithmus/Gültigkeit
\item Erweiterungen
\end{itemize}
\item \textbf{Wichtige Erweiterungen}
\begin{itemize}
\item Verwendung mehrerer Schlüssel: Mehrere Erweiterungsmöglichkeiten zur Verwendung weiterer Schlüssel
\item Alternativnamen für Subjekte: X.500-Namen wenig verbreitet, daher Verwendung von \textit{Subject-Issuer Alternative Names}. So können auch beispielsweise IP-Adressen, E-Mail-Adressen, Domains, etc. verwendet werden
\end{itemize}
\item \textbf{Extended Validation}
\begin{itemize}
\item Ziel: Höheres Maß an Vertrauen durch erweiterte Überprüfung
\item Richtlinien mit technischen/organisatorischen Anforderungen
\item Zertifikate enthalten \textit{certificatePolicies}-Erweiterungen (\texttt{OID} der Policy für EV-Zertifikate sowie URL zum \textit{Certification Practice Statement})
\end{itemize}
\item \textbf{PKI-Unfälle}
\begin{itemize}
\item Immer wieder Einbrüche bei bekannten PKI-Betreibern
\item Microsoft Windows kann einige eigene Zertifikate nicht auf Widerruf prüfen (CRL nicht implementiert) \(\rightarrow\) schwächstes Glied in der Kette bestimmt die Gesamtsicherheit
\end{itemize}
\end{itemize}
\subsubsection{OCSP/SCVP}
\begin{itemize}
\item \textbf{Online Certificate Status protocol (OCSP)}
\begin{itemize}
\item Erster Ansatz zur Onlineprüfung von Zertifikaten auf Widerruf mittels einfachem Frage-Antwort-Schema
\item Erweiterung im Zertifikat zur Spezifizierung von Respondern und des zu verwendenden Protokolls (beispielsweise LDAP/HTTP). Responder wird ebenfalls signiert
\item Einschränkungen
\begin{itemize}
\item Antwortet nur in Bezug auf Widerruf. Keine Prüfung von Verwendungszweck oder zeitliche Gültigkeit
\item Schlechte Skalierung beim Responder, da Antwort immer signiert wird (Vgl.: Bei CRLs muss nur einmal signiert werden, bei OCSP bei jeder Anfrage)
\item Verringert Clientaufwand zur Zertifikatsprüfung kaum
\item Angreifer kann OSCP-Anfrage eventuell blockieren
\end{itemize}
\end{itemize}
\item \textbf{Server-based Certificate Validation Protocol (SCVP)}
\begin{itemize}
\item Soll Clients ein partielles bis vollständiges Auslagern der Zertifikatsprüfung ermöglichen
\item Teilweise Auslagerung
\begin{itemize}
\item Auslagerung des Aufbaus der Zertifikatskette (Delegated Path Discovery)
\item Client führt die Püfung der Zertifikatskette selbst durch \(\rightarrow\) kein vertrauenswürdiger Server erforderlich
\end{itemize}
\item Vollständige Auslagerung
\begin{itemize}
\item Auslagerung der kompletten Zertifikatsprüfung (Delegated Path Validation)
\item Vertrauenswürdiger Server erforderlich
\end{itemize}
\end{itemize}
\end{itemize}
\section{Authentifizierung}
\subsection{Authentifizierung von Nutzern}
\subsubsection{Password Authentication Protocol (PAP)}
\begin{itemize}
\item Idee: Nutzer authentifiziert sich mittels (zuvor ausgehandelter) Nutzerkennung und dazugehörigem Passwort bei Ressource
\item Schwächen: Übertragung im Klartext (MitM- oder Replay-Angriff möglich), Client ist Initiator (DoS-Angriff möglich), Ressource hat Zugriff auf das Klartext-Kennwort
\item Praktikabel über zuvor aufgebauten sicheren Kanal mit authentifizierung der Ressource
\end{itemize}
\subsubsection{Challenge Handshake Authentication Protocol (CHAP)}
\begin{itemize}
\item Client schickt gehashte Kombination aus Passwort und Challenge an den Server (Challenge davor von Server erhalten)
\item Vorteile gegenüber PAP: Passwort wird nicht im Klartext übertragen, bei guter Challenge kein Replay-Angriff möglich, Hash-Algorithmus frei wählbar
\item Nachteil: Passwort weiterhin im Klartext gespeichert
\item Paxisbeispiel MS-CHAPv2 von Microsoft: Client schickt mit Passworthash DES-verschlüsselte Challenge an den Server. DES allerdings gebrochen, daher MS-CHAPv2 nur noch über gesicherten Kanal verwendbar
\end{itemize}
\subsubsection{S/Key}
\begin{itemize}
\item Hashkette zur Verhinderung von Replay-Angriffen \(\rightarrow\) Vermeidung von Passwortspeicherung auf Ressourcen
\item \textbf{Vorbereitungen}
\begin{itemize}
\item Client generiert Einmal-Kennwörter nach dem Schema: \(S_0=H(Passwort+Seed),S_1=H(S_0),...,S_n=H(S_{n-1})\)
\item Ressource speichert das Paar \(\{n,S_n\}\), Client speichert alle Einmalkennwörter \(S_1,...S_n\)
\end{itemize}
\item \textbf{Ablauf}
\begin{itemize}
\item Server schickt Challenge \(n\) an den Client
\item Client sendet \(S_{n-1}\) an den Server
\item Server verifiziert mittels \(H(S_{n-1})=S_n\), bestätigt/lehnt ab und speichert \(\{n-1,S_{n-1}\}\) für die nächste Authentifizierung
\item Wiederhole bis alle Passwörter aufgebraucht sind, danach Neugeneration
\end{itemize}
\end{itemize}
\subsubsection{Extensible Authentication Protocol (EAP)}
\begin{itemize}
\item Idee: Generisches Protokoll mit Unterstützung beliebiger Module zur Authentifizierung
\item \textbf{Ablauf (dynamisch anpassbar)}
\begin{enumerate}
\item Client sendet Authentifizierungswunsch
\item Ressource sendet Antwort mit Liste unterstützter Verfahren
\item Client wählt ein Verfahren aus oder sendet Gegenvorschlag
\item Authentifizierung wird mit gewähltem Verfahren durchgeführt
\item Eventuell Wiederholung mit anderen Modulen
\end{enumerate}
\item Beispielmodule: MD5-Challenge, Generic Token Card (hardware-basiert, sonst wie CHAP), One-Time Passwort
\item Verpflichtende Module: Identity (ermittelt die ID des zu authentifizierdenden Clients), Notification (Übertragen einer Nachricht an den Client, welche dieser bestätigen muss), NAK (Ablehnung einer Antwort)
\item Viele (auch kommerzielle) Module standardisiert
\end{itemize}
\subsection{Authentifizierungsdienste}
\begin{itemize}
\item Zentraler Dienst zur Authentifizierung (AS) im Unternehmen gewünscht, um Mehrfachpflege von Benutzeraccounts zu vermeiden und Autorisierung und Accounting zu vereinfachen
\item Ressourcen leiten Anfragen an AS weiter \(\rightarrow\) weiterer Übertragungsweg, der geschützt werden muss
\end{itemize}
\subsubsection{RADIUS}
\begin{itemize}
\item Aufgaben: Transport von Authentifizierungsdaten, Proxyfunktion zum Weiterleiten an anderen AS (Roaming)
\item Ursprünglich nur Unterstützung von PAP und CHAP, mittlerweile auch von EAP
\item Klassisches Client-Server-Protokoll, arbeitet zwischen Ressource und AS in Anwendungungsschicht oberhalb von UDP
\item \textbf{Rollen}
\begin{itemize}
\item Client (Supplicant): Initiiert die Authentifizierung bei der Ressource
\item Ressource (RADIUS-Client): Handelt Authentifizierungsverfahren mit Client aus und kommuniziert mit AS
\item AS (RADIUS-Server): Nimmt die Authentifizierungsanfrage entgegen, authentifiziert und autorisiert den Benutzer und gibt die Antwort zurück. Leitet die Anfrage ggf. zu betreffendem AS weiter (Roaming)
\end{itemize}
\item \textbf{Authentifizierung mit EAP}
\begin{itemize}
\item Problemstellung: Ressource authentifiziert Client meist über EAP (beispielsweise PPP, PPPoE, 802.1X). Dazu müssen allerdings Daten aufwendig zwischen EAP-Paketen und RADIUS-Attributen kopiert/umgesetzt werden
\item Idee/Lösungsansatz: Verwenden von RADIUS-Attribut "`EAP-Message"' zur Übersetzungsvermeidung in einzelne RADIUS-Attribute
\end{itemize}
\item \textbf{Roaming}
\begin{itemize}
\item Betrieb von mehreren RADIUS-Servern
\item Erster AS fungiert als Proxy für weitere AS und leitet alle Nachrichten weiter
\end{itemize}
\item \textbf{Sicherheitsbetrachtungen}
\begin{itemize}
\item Schutzziele (Ressource \(\Leftrightarrow\) AS): Vertraulichkeit/Integrität/Authentizität der Nachrichten sowie Authentizität der Kommunikationspartner?
\item Umsetzung bei RADIUS: Gemeinsames (16 Byte langes) Geheimnis zwischen Ressource und AS zur Sicherstellung von Vertraulichkeit/Integrität/Authentizität
\item Fazit
\begin{itemize}
\item Sicherheit steht und fällt mit dem Shared Secret. Dieses muss manuell verteilt werden und fehlt beim Roaming \(\rightarrow\) nicht alle Daten sind auf dem Kommunikationsweg geschützt
\item Sicherheit allgemein unzureichend, schwache Sicherung der Schutzziele sowie schwacher Schutz gegen Wiederholungsangriffe (beispielsweise durch Verwendung von \texttt{MD5})
\item Lösung: Verwendung von TLS (oberhalb von \texttt{TCP}) statt \texttt{UDP} (keine Fragmentierung/Staukontrolle/Absicherung der Kommunikation)
\end{itemize}
\end{itemize}
\end{itemize}
\subsubsection{Diameter}
\begin{itemize}
\item Nachfolger von RADIUS, allerdings nicht vollständig abwärtskompatibel
\item Vorteile gegenüber RADIUS: Verlässliche Transportprotokolle (TCP oder SCTP), Fokus auf Sicherheit (verpflichtender Einsatz von IPsec oder TLS), bessere Roaming-Unterstützung, leichte Erweiterbarkeit, Basisunterstützung für Accounting
\item \textbf{Diameter Application}
\begin{itemize}
\item Spezifiziert Framework für Anwendungen: Dienste/Protokolle/Mobile IP/Accounting sowie Ressourcen und AS-Funktionalität
\item Applikationen können Diameter-Funktionalität nutzen, beispielsweise Server-/Proxykomponenten, Verbindungsaufbau, Sitzungsmanagement, Kommunikationssicherheit
\end{itemize}
\item \textbf{Sicherheitsbetrachtung}
\begin{itemize}
\item Sicherheit von Anfang an im Fokus: Verwendung von IPsec vorgeschrieben, Server muss zusätzlich TLS unterstützen
\item Hoher Schutz der Kommunikation zwischen Ressource und AS
\item Kommunikation zwischen Client und Ressource muss weiterhin zusätzlich gesichert werden
\end{itemize}
\end{itemize}
\section{Kerberos}
\subsection{Überblick}
\begin{itemize}
\item Verteilter Authentifizierungsdienst für Benutzer und Server in (un-)geschützten Netzwerken
\item SingleSignOn innerhalb der Domäne (Benutzer muss sich nur einmal anmelden)
\item \textbf{Komponenten}
\begin{itemize}
\item \textit{Key Distribution Center (KDC)}
\begin{itemize}
\item Trennung von Authentifizierung und Ressourcenzugang (Autorisierung)
\item Nachteile: Muss vertraut werden; Single-Point-of-Failure
\item Bestandteile
\begin{itemize}
\item Authentication Server (AS) zur Authentifizierung der Benutzer sowie zur Ausstellung von Authentifizierungstokens (\textit{Ticket-Granting-Ticket}: TGT)
\item Ticket Granting Server (TGS): Ressourcen-Zugangs-Server zur Autorisierung des Ressourcen-Zugriffs mit gültigem TGT. Ausstellung von Zugangsberechtigungen (\textit{Tickets})
\end{itemize}
\end{itemize}
\item Benutzerdaten zur Speicherung der \textit{Master-Secrets} aller Benutzer und Ressourcen
\end{itemize}
\item \textbf{Ablauf einer Anmeldung (Überblick)}
\begin{enumerate}
\item Anmeldung beim AS: Client erhält TGT von AS
\item Ressourcenanforderung: Autorisierung durch TGT. Client erhält Ticket für die entsprechende Ressource
\item Kommunikation mit der Ressource, nicht mehr Teil von Kerberos. Zugriffskontrolle erfolgt durch die Ressource
\end{enumerate}
\item \textbf{Grundprinzip Kerberos-Authentifizierung: Verwendete Schlüssel}
\begin{itemize}
\item Schlüsselüberblick
\begin{description}
\item[Master-Secret des Client (\(k_{Alice}\)):] Alice und dem KDC bekannt, wird aus Anmeldepasswort abgeleitet (\(SHA1(password_{Alice})\))
\item[Master-Secret des KDC (\(k_{KDC}\)):] Nur dem KDC bekannt
\item[Sitzungsschlüssel (\(k_S\)):] Sitzungsschlüssel. Vom KDC pro Sitzung zufällig gewählt und per TGT verteilt
\end{description}
\item Aussteller (AS oder TGS) erzeugt Sitzungsschlüssel \(k_S\), den Nutzer und Prüfer (TGS oder Ressource) erhalten. Ebenfalls Bestandteil des Tickets (mit \(k_{KDC}\) verschlüsselt)
\end{itemize}
\end{itemize}
\subsection{Schritt für Schritt}
\begin{itemize}
\item Anmeldung an der Workstation: Anmeldung per Benutzername und Passwort. Aus dem Passwort wird das Benutzer-Secret abgeleitet (\(SHA_1(Password_{Alice}) = secret_{Alice}\))
\item \textbf{Anmeldung am Netz}
\begin{itemize}
\item KDC authentifiziert Benutzer anhand Benutzername (im Klartext übertragen) und Benutzer-Secret \(rightarrow\) Angreifer kann Identität des Benutzers abhören
\item Antwort vom Server (\texttt{AS\_REP}) enthält TGT (mit \(k_{KDC}\) verschlüsselt) und Sitzungsdaten für den Benutzer (mit \(k_{Alice}\) verschlüsselt)
\item Schutz des langlebigen Geheimnisses durch Sitzungsschlüssel; Nonce in \(k_{Alice}\) zum Schutz vor Replay-Attacken
\end{itemize}
\item \textbf{Ressourcenanforderung}
\begin{itemize}
\item TGS für die Ausgabe von Ressourcen-Tickets verantwortlich
\item Zugangskontrolle durch jede Ressource (Erweiterung: Zugriffsbeschränkung durch KDC)
\item \texttt{TGS\_REQ} enthält TGT, Ressourcenname, Authenticator (verschlüsselt mit \(k_S\))
\item \texttt{TGS\_REP} enthält Sitzungsschlüssel mit der Ressource (\(k_{AR}\), mit \(k_S\) verschlüsselt) sowie Ticket für den Ressourcenzugriff (mit Ressourcenschlüssel \(k_R\) verschlüsselt)
\item Vorteil für TGT: Muss keinen Zustand halten
\end{itemize}
\item \textbf{Kommunikation mit der Ressource}
\begin{itemize}
\item Application Request (\texttt{APP\_REQ}) enthält Ticket und Authenticator
\item Danach ungeschützter Austausch von Anwendungsdaten
\end{itemize}
\end{itemize}
\subsection{Angriffe, Entwurfsentscheidungen, etc.}
\begin{itemize}
\item \textbf{Password-Guessing-Angriffe}
\begin{itemize}
\item Offline-Password-Guessing-Angriff: Abhören von \texttt{AS\_REQ} und \texttt{AS\_REP} mit anschließendem Wörtbuchangriff zur Ermittlung des Passworts (Benutzername im Klartext übertragen)
\item Aktive Password-Guessing-Angriffe
\begin{itemize}
\item Idee: Generierung gefälschter \texttt{AS\_REQ} für beliebige Nutzer
\item Preauthentication Data (optional in Kerberos v5)
\begin{itemize}
\item Aktueller Zeitstempel wird mit \(k_{Alice}\) verschlüsselt zusätzlich übertragen \(\rightarrow\) Server antwortet nur bei korrekt entschlüsselbarem Zeitstempel
\item Offline-Password-Guessing allerdings weiterhin möglich
\item Brute-Force-Angriff (Passwort raten und damit Preauthentication-Data verschlüsseln) ebenfalls weiterhin möglich, dauert allerdings lange und wird am KDC protokolliert
\end{itemize}
\end{itemize}
\end{itemize}
\item \textbf{Authenticator}
\begin{itemize}
\item Ziel: Verhinderung von Replay-Angriffen durch einmalig einsetzbares Token
\item Name und Zeitstempel werden mit Sitzungsschlüssel verschlüsselt; Token nur innerhalb Zeitfenster gültig
\item Bedingung: Synchronisation der Systemuhren
\end{itemize}
\item \textbf{Netzwerkadressen der Clients in jedem Ticket}
\begin{itemize}
\item Keine Weitergabe von Tickets \(\rightarrow\) schützt vor Ticketdiebstahl
\item Probleme: IP-Spoofing allerdings unkompliziert möglich; funktioniert nicht bei NAT
\end{itemize}
\item \textbf{Entwurfsentscheidungen}
\begin{itemize}
\item Trennung von Authentifizierung und Autorisierung
\begin{itemize}
\item Zweiteilung: Beantragen von TGTs beim AS, beantragen von Ressourcen-Tickets beim TGS
\item Vorteil: Master-Secret des Clients wird nur einmal benötigt; Mastersecret und Passwort des Clients müssen im PC gespeichert werden; Nutzer muss Passwort nur einmal eingeben
\end{itemize}
\item Keine Zustandshaltung beim KDC: Vermeidet Überlastung \(\rightarrow\) gute Skalierung sowie Schutz für DoS-Angriffen
\item Keine asymmetrische Kryptografie: Zum Entwurfszeitpunkt (1993) zu wenig Rechenleistung verfügbar
\end{itemize}
\end{itemize}
\subsection{Spezielle Eigenschaften}
\begin{itemize}
\item \textbf{Passwort-Änderung}
\begin{itemize}
\item Problem (I): Ausgestellte Tickets sind mit Mastersecret des Clients verschlüsselt \(\rightarrow\) Passwortänderung führt zu neuem Mastersecret des Clients
\item Lösung (I): Versionierung der Schlüssel, jedes Ticket enthält Schlüsselversion
\item Problem (II): Replizierung des KDC \(\rightarrow\) Login mit neuem Schlüssel eventuell noch nicht möglich (s.u.)
\end{itemize}
\item \textbf{Rechteübertragung}
\begin{itemize}
\item Kerberos v5 erlaubt das Übertragen von Tickets
\item Anforderungen: Zeitliche Beschränkung; Beschränkung der übertragenen Rechte; wer darf darüber entscheiden?
\item Nachteile: Mehr KDC-Anfragen; komplizierte Zugriffsbeschränkungsregeln in KDC und Anwendungen
\item Übertragene Tickets
\begin{itemize}
\item Forwardable TGT: Übertragenes TGT
\item Proxy Ticket: Übertragenes Ticket für genau eine Ressource
\item Signalisierung durch Flag; Sitzungsschlüssel wird mit dem Ticket übergeben
\item Einschränkung auf IP-Adresse(n) möglich (spoofbar)
\end{itemize}
\item Einschränkbar durch Sicherheitsrichtlinien des KDC oder individuell durch Ressourcen
\item \textbf{Lebenszeit von Tickets}
\begin{itemize}
\item Feste und begrenzte Lebenzeit in Kerberos v4
\item Langlebige Tickets generell gefährlich, da Widerrufen schwierig
\item Neue Ticketarten in Kerberos v5
\begin{description}
\item[Erneuerbare Tickets:] Langfristig gültige Tickets
\item[Zukünftige Tickets:] Gültigkeitsbeginn in der Zukunft
\end{description}
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Kerberos in großen Netzen}
Welche Probleme können in großen Netzen auftreten?
\begin{itemize}
\item \textbf{Schlüssel-Server für große Netze}
\begin{itemize}
\item Einzelner KDC ist Single-Point-of-Failure \(\rightarrow\) Replizieren des Schlüssel-Servers
\item Sicherheitproblem: KDC kennt alle Mastersecrets
\item Replizierte Schlüssel-Server
\begin{itemize}
\item Eine Master-Copy und mehrere read-only-Slaves der Benutzerdatenbank; alle KDCs benutzen das selbe Mastersecret
\item Alle Änderungen auf der Master-Copy, Slaves werden periodisch (oder explizit) synchronisiert. Updates werden mit KDC-Secret verschlüsselt sowie gehasht
\item Bei Masterausfall ist das Netz weiterhin nutzbar, allerdings sind keine KDC-Updates möglich
\end{itemize}
\item Domänen (Realms)
\begin{itemize}
\item Eigene Benutzerdatenbank pro Domäne; Replizierung möglich (KDCs nutzen dann das selbe Mastersecret)
\item Interdomänenauthentifizierung
\begin{itemize}
\item Ressourcenzugriff auf Ressource einer anderen Domäne: Autorisierung durch KDC der anderen Domänen
\item KDC der anderen Domäne wird dabei wie eine Ressource behandelt:
\begin{enumerate}
\item Alice beantragt zunächst Ressourcen-Ticket bei Heim-KDC für entfernte Domäne
\item Alice beantragt Ressourcen-Ticket für entfernte Ressource bei entferntem KDC
\end{enumerate}
\end{itemize}
\end{itemize}
\item Mehrstufige Domänen
\begin{itemize}
\item Verkettung von Inter-Domänen-Tickets möglich (neu in Kerberos v5)
\item Umgang über Sicherheitsrichtlinien in den Anwendungen geregelt
\item Hierarchische Domänen: KDC registriert sich als Client bei KDC der Vaterdomäne (Anhlehnung an \texttt{X.500}-Namen)
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Zusammenfassung}
\begin{itemize}
\item SSO-Netzwerk; Tickets mit Cookie-Prinzip; Übertragung von Rechten möglich; KDC als Single-Point-of-Failure (Replizierung, Mehrstufigkeit)
\item Vorteile: Nur ein Passwort; sichere, netzwerkweite Authentifizierung; basiert fast ausschließlich auf symmetrische Verfahren
\item Nachteile: Kompromittierung des Master-Secrets des KDC legt alle Master-Secrets der Clients offen; alle Ressourcen müssen angepasst sein ("`kerberized"'); enge Synchronisation der Systemuhren notwendig
\end{itemize}
\section{Zugangsschutz}
\subsubsection{Bestandteile}
\begin{itemize}
\item Network Access Server (NAS): Einwahl-/Verbindungspunkt für Nutzer. Blockiert zunächst Zugriffe der Nutzer und wartet auf Authentifizierung und Autorisierung
\item Authentication Server (AS): Speichert Informationen zum Nutzer und nimmt Authentifizierungsanfragen entgegen; kann weitere kundenspezifische Attribute verteilen (Nameserver, Gateway, etc.)
\end{itemize}
\subsection{Netzzugangstechniken}
\subsubsection{Einwahlverbindungen (DSL)}
\begin{itemize}
\item Hier direkte Punkt-zu-Punkt-Verbindungen wie POTS, ISDN oder LAN. Angriffe schwierig, physischen Zugriff notwendig
\item \textbf{Point-to-Point Protokoll (PPP)}
\begin{itemize}
\item Etabliertes Standardprotokoll der ISPs zum Aufbau von Punkt-zu-Punkt-Verbindungen oberhalb von \texttt{HDLC} (Schicht-2-Protokoll)
\item Bestandteile
\begin{description}
\item[Link Configuration Protocol (LCP:] zur Authentifizierung auf Schicht 2, beispielsweise mittels PAP
\item[Network Configuration Protocol (NPC):] zur Einrichtung von Schicht 3 (beispielsweise IP)
\end{description}
\item Sicherheit: Keinerlei Sicherheit bei Authentifizierung und anschließender Kommunikation. Annahme, dass Angreifer keinen phyischen Zugriff haben
\end{itemize}
\item \textbf{PPP over Ethernet (PPPoE)}
\begin{itemize}
\item Ethernet als Anschlusstechnologie zur Kosteneinsparung der Provider (geteiltes Medium: Punkt-zu-Multipunkt). Allerdings fehlende Funktionalität in Ethernet wie Authentifizierung, Aushandling von Optionen, Accounting, Finden der Gegenstelle etc. \(\rightarrow\) Kombinieren von Ethernet mit PPP
\item Auch PPPoE verwendet keine zusätzlichen Sicherheitsfeatures
\end{itemize}
\end{itemize}
\subsubsection{Virtual Private Networks (VPN)}
\begin{itemize}
\item Netzwerkübergreifend über (unsichere Netze) \(\rightarrow\) Angreifer ggf. in weitervermittelnden Netzen (beispielsweise dem Internet)
\item Ziele: Zugriff nur für legitimierte Benutzer; Schutz der Daten auf dem Transportweg
\item \textbf{PPP over IP (PPPoI)}
\begin{itemize}
\item Nutzung von PPP zur Authentifizierung über \texttt{IP}/\texttt{UDP}
\item Implementierungen
\begin{description}
\item[Point-Point-Tunneling-Protocol (PPTP):] Priorietär (Microsoft, später \texttt{IETF}); gilt als gebrochen (verwendet u.a. \texttt{MSCHAPv2})
\item[Layer-2-Tunneling-Protocol (L2TP):] Offener Standard (\texttt{IETF}); Aufbau eines \texttt{UDP}-Tunnels zum Transport
\end{description}
\end{itemize}
\item \textbf{Implementierungen}
\begin{itemize}
\item L2TP
\begin{itemize}
\item Virtuelle P2P-Verbindungen: Supplicant zu NAS
\item Nutzt \texttt{UDP}; bietet keine Vertraulichkeit \(\rightarrow\) muss zusätzlich realisiert werden (beispielsweise via \texttt{IPsec})
\end{itemize}
\item OpenVPN
\begin{itemize}
\item Ziele: OS-Unabhängigkeit; gute Konnektivität durch Firewalls und NATs
\item Verwendung von \texttt{TLS} zum gesicherten Zunnelaufbau zum NAS: Authentifizierung und Schicht-3-Aufbau über \texttt{TLS}-Tunnel
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Dedizierte, physische Medien}
\begin{itemize}
\item Port-based Network Access Control (PNAC) von Geräten (beispielsweise an Switches)
\item \textbf{Protokoll für PNAC: \texttt{IEEE 802.1X}}
\begin{itemize}
\item (Re-) Authentifizierung und Autorisierung von Switch-Ports via \texttt{EAP} over LAN auf Schicht 2
\item Zunächst lediglich Authentifizierungsverkehr zugelassen, nach Authentifizierung wird Netznutzung freigeschaltet
\item Kann zur Konnektivität zwischen Switches genutzt werden \(\rightarrow\) Switch kann auch Sublicant sein
\end{itemize}
\end{itemize}
\subsubsection{Wirless LAN}
\begin{itemize}
\item Besonderheiten: Broadcast-Medium \(\rightarrow\) Angriffe leicht möglich
\item \textbf{Wired Equivalent Privacy (WEP) ab 1999}
\begin{itemize}
\item Ziel: Authentifizierung von Nutzern ohne Fokus auf Vertraulichkeit/Integrität (PSK: Alle Nutzer teilen sich einen Schlüssel)
\item Authentifizierung per PSK: Challenge-Response-Verfahren. Nutzer verschlüsselt vom NAS gewählte Challenge mit \texttt{IV} und \texttt{K}
\item Sicherheitsprobleme
\begin{itemize}
\item Kein Schutz gegenüber Gruppenmitgliedern
\item Verwendete Stromchiffre \texttt{RC4} gilt als gebrochen \(\rightarrow\) anfällig für \texttt{XOR}-Replay-Angriffe
\item "`Integritätssicherung"' lediglich per \texttt{CRC}-Prüfsumme \(\rightarrow\) kann nach Datenmanipulation trivial neuberechnet und angehängt werden
\end{itemize}
\end{itemize}
\item \textbf{Wi-Fi Protected Access (WPA) ab 2003}
\begin{itemize}
\item Alternative zu WEP notwendig, ohne zusätzliche Anforderungen an bereits verwendete Hardware zu stellen
\item Implementiert Teilmenge von \texttt{IEEE 802.11i} (definiert verbesserte Algorithmen)
\item Authentifizierung via PSK oder \texttt{IEEE 802.1X}; Verschlüsselung mittels \texttt{TKIP} (basiert auf \texttt{RC4})
\item Sicherheitsprobleme
\begin{itemize}
\item Fehlende Unterstützung für starke Kryptomechanismen (\texttt{IEEE 802.11i} nur unvollständig umgesetzt)
\item \texttt{TKIP} (basiert auf \texttt{RC4}) gilt als gebrochen
\end{itemize}
\end{itemize}
\item \textbf{802.11i/Wi-Fi Protected Access (WPA2) ab 2004}
\begin{itemize}
\item \texttt{IEEE 802.11i} - Robust Security Network (RSN)
\begin{itemize}
\item Authentifizierung via PSK (Personal Mode) oder \texttt{IEEE 802.1X} (Enterprise Mode)
\item Verschlüsselung via \texttt{AES-CCMP}: Counter Mode with Cipher Block Chaining Message Authentication Code Protocol auf Schicht 2
\end{itemize}
\item Personal Mode
\begin{itemize}
\item Berechnung des \textit{Pairwise Master Key} aus \texttt{PSK} und \texttt{SSID} (\(PMK = \big(H(PSK+SSID)\big)^{4096}\))
\item 4-Wege-Handshake zum Authentifizieren und Aushandeln von Sitzungsschlüsseln
\item Verschlüsselung und Integritätsschutz bei Unicast-Kommunikation: Abgeleitet aus PMK
\item Verschlüsselung und Integritätsschutz bei Multicast-Kommunikation
\begin{itemize}
\item AP wählt zufälligen \textit{Group Master Key} und leitet darauß \textit{Group Transient Key} (GTK) ab, der an alle Gruppenmitglieder verteilt wird
\item Schlüssel müssen erneuert werden, wenn ein Mitglied die Gruppe verlässt
\end{itemize}
\item Sicherheitsbewertung: Erfüllt die Schutzziele; Authentifizierung nur auf Basis von Gruppenzugehörigkeit \(\rightarrow\) schwierig, einzelne Nutzer zu identifizieren (beispielsweise bei Rechtsstreitigkeiten)
\end{itemize}
\item Enterprise Mode
\begin{itemize}
\item Nutzt \texttt{IEEE 802.1X} zur Verwendung in "`Unternehmen"' \(\rightarrow\) ermöglicht Authentifizierung von Benutzern
\item Sicherheitsbewertung: Löst Probleme des Personal Mode; Wiederverwendung von Standards (\texttt{IEEE 802.1X} mit \texttt{EAP})
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Beispiel eduroam}
\begin{itemize}
\item Föderativer Ansatz für Internetzugang über Universitäten für globalen Internetzugang von Studenten/Mitarbeitern. Dezentrale Speicherung ermöglicht Authentifizierung der Nutzer über die jeweilige Universität
\item Schutzziele: Schutz auf Schicht 2 sowie gegenseitige Authentifizierung von Supplicant und AS
\item \textbf{Aufbau}
\begin{itemize}
\item Eindeutige, globale Identifikation der Benutzer (beispielsweise \texttt{[email protected]})
\item Aufteilung in Authentifizierungsdomänen (Realms): Jede teilnehmende Universität stellt eigenen AS (Identitätsprovider, RADIUS-Server) \(\rightarrow\) Roaming über hierarchisches RADIUS-Netzwerk
\item Hierarchischer Zusammenschluss je Land zu einer Föderation sowie Zusammenschloss der Föderationen zu entsprechenden Konföderationen (Europa, Asien-Pazifik, USA, Kanada, etc.)
\item Probleme bisher:
\begin{itemize}
\item Schutz nur jeweils zwischen Supplicant/NAS, NAS/AS, AS/AS. Zwischensysteme können Daten abhören/manipulieren \(\rightarrow\) kein Schutz auf dem kompletten Kommunikationsweg zwischen Supplicant und Heimat-AS
\item NAS erfährt den konkreten Benutzernamen \(\rightarrow\) kein Schutz der Identität
\item Keine Authentifizierung des Heimt-AS
\end{itemize}
\item Zusätzliche Probleme bei 802.1X und WLAN
\begin{itemize}
\item Passiver Angriff durch Mitschneiden der initialen Identitätsdaten immer möglich
\item Aktive Angriffe wie MitM-Angriffe während der Authentifizierung oder Fälschen von Dateneinheiten möglich
\end{itemize}
\item Ansätze zum Schutz des Authentifizierungsverkehrs:
\begin{itemize}
\item Protected-EAP (PEAP): Proprietäres Protokoll von Microsoft/Cisco
\item EAP-Tunneled-TLS (EAP-TTLS): IETF-standardisiert. Zunächst Aufbau einer gesicherten TLS-Verbindung mit anonymem Supplicant, danach Authentifizierung über sicheren Tunnel. Nachteile: Ob AS-Zertifikat validiert wird hängt vom Supplicant ab, problematisch bei zurückgerufenen Zertifikaten
\end{itemize}
\end{itemize}
\end{itemize}
\section{IPsec}
\subsection{Einführung}
\begin{itemize}
\item \textbf{Motivation}
\begin{itemize}
\item Internet-Protocol (IP) bietet einen nur unzuverlässigen Ende-zu-Ende Dienst (best-Effort)
\item Mögliche Angriffe: Eavesdropping, IP-Spoofing, MitM-Angriffe, Replay-Angriffe \(\rightarrow\) Schutzziele nicht gewährleistet
\end{itemize}
\item \textbf{Überblick}
\begin{itemize}
\item Ziel: Umsetzung von Schutzzielen für den Verkehr auf Schicht 3, unabhängig vom Transportprotokoll
\item Vorteile: Sicherheit unabhängig von Anwendungen; transparent; individuell konfigurierbar
\end{itemize}
\item \textbf{Einsatzszenario}
\begin{itemize}
\item Häufiger Einsatz als VPN, beispielsweise in Unternehmen mit verschiedenen Standorten, die über das Internet kommunizieren
\end{itemize}
\item \textbf{Grundlegender Aufbau}
\begin{itemize}
\item Wesentliche Komponenten: Schlüsselaustausch (Internet Key Exchange - IKE) und Protokolle zur sicheren Kommunikation (Authentication Header - AH oder Encapsulating Security Payload - ESP)
\item Entwurfsentscheidung: Entkopplung von Schlüsselaustausch (Kontrollebene) und Sicherung (Datenebene)
\end{itemize}
\end{itemize}
\subsection{Security Policy}
\begin{itemize}
\item \textbf{Sicherheitsassoziation}
\begin{itemize}
\item Flexibilität: Teilnehmer können entscheiden, welche Sicherheitsanforderungen an einen IP-Strom gestellt werden. Kommunikationspartner definieren \textit{Security Policy}, die für alle Pakete angewandt wird
\item Security-Association (SA): Unidirektionale Verbindung zwischen zwei IP-Instanzen. Generell zwischen allen Verbindungen möglich. \textbf{Lokal} eindeutig durch \textit{Security Parameter Index} (SPI) identifizierbar
\end{itemize}
\item \textbf{SAD und SPD}
\begin{description}
\item[Security Association Database (SAD):] Hält Parameter aktiver, gesicherter IP-Datenströme (\textit{Security Parameter Index, Sequenznummer, Fenster gegen Replay-Angriffe, Lebenszeit der SA etc.})
\item[Security Policy Database (SPD):] Enthält Richtlinien nach denen der Verkehr zu schützen ist. Zu sendende Dateneinheiten werden gemäß SPD auf SA abgebildet. Besteht aus einer Tabelle, die beschreibt, wie die einzelnen Verbindungen (Adressen, Ports, Protokoll) zu sichern sind. Dies kann auch bedeuten, dass manche Verbindugen gar nicht gesichert werden (\texttt{BYPASS}). Wird zu einer Verbindung keine Einstellung gefunden, so wird diese verworfen
\end{description}
\item \textbf{Bearbeiten von Dateneinheiten}
\begin{itemize}
\item Bearbeiten zu sendender IP-Dateneinheiten
\begin{itemize}
\item Gegeben: Zu sendende Dateneinheit
\item Zunächst Suche in der SPD. Wird kein Eintrag gefunden so wird die Dateneinheit verworden. Ansonsten wird die entsprechende Policy bestimmt
\item Bypass-Policy: Weiterleiten mittels IP
\item Protect-Policy: Suche in der SAD. Bei einem Match AH- oder ESP-Verarbeitung, ansonsten IKE
\end{itemize}
\item Bearbeiten empfangener IP-Dateneinheiten
\begin{itemize}
\item Gegeben: Empfangene Dateneinheit
\item Zunächst Bestimmung des Types
\item Typ IP: Suche in der SPD. Falls \texttt{BYPASS}, Weitergabe an höhere Schicht, ansonsten Verwerfen der Dateneinheit
\item Typ IPsec: Suche in der SAD. Falls enthalten, AH- oder ESP-Verarbeitung, ansonsten Verwerfen der Dateneinheit. Danach Weitergabe an höhere Schicht
\end{itemize}
\end{itemize}
\end{itemize}
\subsection{Architektur}
\begin{itemize}
\item \textbf{Endpunkttypen}
\begin{description}
\item[Kommunikationsendpunkt:]Endpunkte ausgetauschter Punkte
\item[Kryptografische Endpunkt:] Endpunkte der Sicherheitsprotokolle
\end{description}
\item \textbf{Übertragungsmodi}
\begin{description}
\item[Transport-Modus:] Einsatz zwischen Kommunikationsendpunkten, schützt die Nutzdaten. Zusätzlicher IPsec-Kopf im Paket enthalten
\item[Tunnel-Modus:] Einsatz zwischen beliebigen Systemen, oft ist ein Endpunkt kein Kommunikationsendpunkt. IP-in-IP-Kapselung, schützt die gesamte IP-Dateneinheit, Router auf dem Weg haben keinen Zugriff auf Orginal-IP-Kopf
\end{description}
\item \textbf{Schutz vor Replay-Attacken}
\begin{itemize}
\item Erster Ansatz: Verwenden von eindeutigen, monoton wachsenden Sequenznummern
\item Besser: Verwenden eines Sliding Window mit fester Fenstergröße \(W\). Pakete werden nur dann akzeptiert, wenn die neue Sequenznummer innerhalb des Fensters liegt oder größer ist als die höchste, bisher empfangene und noch nicht verwendet worden ist. Liegt die Sequenznummer außerhalb des Fensters, so wird dieses verschoben. Anonsten wird das Paket verworfen
\item Bisherige 32-Bit-Sequenznummer (reicht für etwa 4 Milliarden Dateneinheiten) für schnelle Netze zu wenig (bei ca. 1 Millionen Dateneinheiten pro Sekunde: Überlauf nach etwa 1,12 Stunden) \(\rightarrow\) \textit{Extended Sequence Number} (ESN) mit 64 Bit: Zum Erhalten der Abwärtskompatibilität werden nur die unteren 32 Bit übertragen, die oberen 32 Bit lediglich in der SA
\end{itemize}
\item \textbf{Schutz vor Verkehrsanalyse}
\begin{itemize}
\item Ziel: Keine Informationen durch Größe und Frequenz der Dateneinheiten verraten
\item Ansatz: Padding auf 64k Größe einer Dateneinheit sowie Einfügen von Dummy-Einheiten (gekennzeichnet durch Protokollnummer 59) zum Erzeugen eines stetigen Stroms an regelmäßigen und gleich großen Dateneinheiten
\end{itemize}
\end{itemize}
\subsection{Sicherheitsprotokolle}
\begin{itemize}
\item \textbf{AH-Protokoll}
\begin{itemize}
\item Bietet Integrität, Authentizität, Zugangskontrolle, Schutz gegen Replay-Angriffe
\item Zentrales Ziel: Abwehr von Address-Spoofing-Angriffen durch HMACs
\item Berechnung des MAC: \texttt{HMAC} über:
\begin{itemize}
\item Unveränderliche Felder des vorangegangenen IP-Kopf (veränderliche werden auf Null gesetzt)
\item \texttt{AH}-Kopf
\item Die Nutzdaten
\item Die oberen 32 Bits der erweiterten Sequenznummer
\end{itemize}
\end{itemize}
\item \textbf{ESP-Protokoll}
\begin{itemize}
\item Bietet Integrität, Authentizität, Zugangskontrolle, Schutz gegen Replay-Angriffe sowie Vertraulichkeit und Schutz vor Verkehrsanalysen
\item Umsetzung der Schutzziele abhängig von den ausgewählten Optionen bei Etablierung der SA sowie Lokation der Implementierung (beispielsweise in Endsystem oder Gateway)
\item Kryptografische Bausteine: MACs sowie symmetrische Chiffren (beispielsweise
3DES-CBC oder AES-128-CBC). Voraussetzung ist ein gemeinsamer, geheimer Schlüssel
\item Erst verschlüsseln oder Authentifizieren?
\begin{itemize}
\item Encrypt-then-MAC (EtM): Schränkt DoS-Angriffe ein (Authentizität kann vor Entschlüsselung geprüft werden); Authentifizierungsdaten allerdings unverschlüsselt \(\rightarrow\) Keyed Authentication Algorithm notwendig; in der Theorie besser
\item Mac-than-Encrypt (MtE): MAC nicht angreifbar; "`You should authenticate what you mean, not what you say"\footnote{Horton-Prinzip}
\end{itemize}