Herzlich willkommen nochmal am 26.
Juli im BERG hier.
Für unsere sicherheitslastigen Vorlesung heute.
Also wir werden diese Woche und nächste Woche über Sicherheitsaspekte
reden, im verteilten System allgemein.
Aber an dem Beispiel dieses AdTagsystems, was zwei von euch
wahrscheinlich besser kennen als ich eigentlich, aber die Sachen, die
jetzt für uns wichtig sind, die sind so weit allgemein, dass sie auch
in dem AdTagsystem so sind.
Also ich werde wahrscheinlich, wenn ich irgendwelche Beispiele erzähle
aus dem System, wahrscheinlich nicht so weit weg von der Realität mich
bewegen.
Ja, also dieses System ist halt so ein E-Learning-System.
Und was für uns jetzt eher wichtiger ist, dass es so eine
Mehrschichtenarchitektur realisiert.
Also da gibt es Kommunikationsaspekte, das zeigen wir dann noch
später.
Und wir werden in der Vorlesung eben zwei Teile haben.
Heute werden wir diese Aspekte der Entwicklung sozusagen, habe ich es
so genannt, über die sichere Kommunikation und die Authentifizierung
kennenlernen.
Und dann zeigen wir auch noch, wie diese zwei Aspekte mit anderen
Aspekten verknüpft sind.
Und beim nächsten Mal, wenn wir heute das alles schaffen, dann haben
wir eine ganze Vorlesung für Sicherheitsmanagement, wo wir dann
wirklich solche Aspekte betrachten oder Eigenschaften eines Systems,
die unabhängig sind von der Kryptographie zum Beispiel, die nur
sozusagen Managementmaßnahmen sind.
Und da sieht man, wie diese beiden Sachen zusammenwirken und
funktionieren müssen in einem System.
Und das wird anhand einer BKI vorgestellt, was vielleicht für euch
schon ein bekannter Begriff ist an sich, aber vielleicht hört ihr dann
doch noch einige Neuigkeiten, weil wir werden da die Interna von
diesem System kennenlernen.
Gut.
Die erste Folie ist eigentlich nochmal diese EdTech-Architektur, was
die Funktionalität angeht.
Also wie man sieht, da werden unterschiedliche Prozesse abgebildet,
die in diesem E-Learning-Szenario identifiziert worden sind.
Und was man hier merken muss, ist, dass hier diese unterschiedlichen
Aufgaben, die das System erfüllt und zum Beispiel dieser
Autorenprozess, macht immer wieder irgendwelche Spezialitäten, die
auch was mit der Sicherheit zu tun haben.
Also da unterschiedliche Werkzeuge zum Beispiel funktionieren anders
und haben andere Sicherheitsprobleme, die man lösen muss.
Hier ist schon ein besseres Bild, glaube ich, über die Architektur,
wie diese Prozesse dann technisch realisiert werden.
Wir sehen hier jetzt eigentlich vier Schichten, wobei man kann sagen,
dass diese oberen zwei Schichten, die sind sozusagen lokale Schichten,
was den Anwender angeht.
Also aus Sicht des Anwenders ist das eine lokale Schicht.
Das heißt, eine lokale Sicherheitsdomäne gehören sie da.
Zum Beispiel diese Tools, die laufen auf dem Rechner des Benutzers im
wie auch immer implementierten Modus.
Also es können auch Web-Anwendungen sein oder irgendwelche anderen
Standalone -Applikationen.
Und irgendein Teil, also wenn das zum Beispiel ein Web-Browser ist,
dann ist dieser HTTP-Konnektor in dem Fall integriert in den Web
-Browser natürlich.
Wichtig ist an der Stelle, dass hier eine sogenannte Inter-Prozess
-Kommunikation stattfindet.
Und wir werden dann sehen, welche Sicherheitsmaßnahmen da notwendig
sind.
Und wichtiger ist jetzt für uns diese Internet-basierte Kommunikation
zwischen diesem Specific-Mediaware und diesem Basic-Mediaware.
Wo man eben über so ein HTTP die Kommunikation abwickelt und Anfragen
stellt an diesen Information-Broker, der dann die entsprechenden
Anfragen bearbeitet.
Und dazu nutzt er eben Daten, die aus dieser Datenbank ebenfalls
verteilt sein kann und vielleicht auch über das Internet zugreifbar
ist oder halt wieder auf demselben Rechner läuft.
Aus diesen Daten heraus generiert er irgendein Ergebnis und schickt
das Ergebnis zu dem Benutzer über das Internet wieder.
Dann schauen wir mal ein bisschen detaillierter an, beziehungsweise
die rechte Seite des Bildes zeigt dann, habe ich auch versucht, diese
ganzen Sicherheitsaspekte zu schichten, wobei diese Schichten also
jetzt nicht eins zu eins stimmen natürlich, aber ich habe versucht,
die so zuzuordnen, die mir am wichtigsten erscheinen.
Also zum Beispiel dieser Schutz von dem Code und irgendwelche Daten
jetzt vor Manipulation, das ist sehr wichtig, an der Stelle von dem
Client, wo der zum Beispiel irgendein unsicheres Betriebssystem hat,
will ich jetzt keine Markennamen nennen, und wo man halt mit Viren
rechnen muss zum Beispiel und muss man halt entsprechend was dagegen
tun.
Und dann unsere zwei Aspekte, die wir betrachten, die sind am
einfachsten hier zu erkennen, die sichere Kommunikation.
Über das Internet wird das so richtig interessant und auch die
Authentifizierung natürlich an dieser Stelle, wo man als Benutzer zu
dem System kommt und muss sich jetzt sozusagen ausweisen und sagen,
wer man ist.
Und dann gibt es noch andere Aspekte, die man so System Security zu
nennen pflegt.
Das sind die Firewalls, dazu gehören zum Beispiel, also das ist so ein
Allgemeinbegriff eigentlich, was gehört zu einem Firewall-System
eigentlich?
Hat jemand eine Ahnung?
Welche Komponenten hat ein Firewall-System?
Wir werden das hier jetzt nicht behandeln, deswegen wollte ich das
jetzt kurz mal erwähnen.
Weiß jemand was?
Ja, bitte.
Ja genau, zum Beispiel ein Paketfilter, noch jemand was?
Oder du, wenn du noch mehr erkennst?
Wozu ist ein Paketfilter dann gut?
Warum wird das eingesetzt?
Ja genau, sehr wichtig in dem TCP-Umfeld, dass die Ports eben die
geschlossen sind, die geschlossen sein müssen und nur die offen sind,
die offen sein müssen wegen der Funktionalität.
Genau, und das sind jetzt sozusagen diese Protokoll-lastigen
Funktionalitäten, aber es gibt ja auch die, zum Beispiel so
Application -Gateways, habt ihr auch wahrscheinlich von dem Begriff
gehört, die dann meinetwegen für ein bestimmtes Anwendungsprotokoll so
eine Art Paketfilter-Rolle spielen, wo sie gucken, ob zum Beispiel ein
Core -Bar-Kommunikation dem entspricht, wie das definiert ist.
Und dann man kann erkennen, zum Beispiel mit einem
Mustererkennungsverfahren, ob jemand zum Beispiel ein Paket so
manipuliert hatte oder versucht hat zu manipulieren, damit das ganze
Ding dann abstürzt.
Also gegen solche Attacken schützen dann solche Application-Gateways.
Und man kann auch Versuche erkennen, dass man zum Beispiel versucht,
in einer E-Mail irgendwelche extra Dateien reinzuspielen in das
System.
Also da muss man so eine SMTP-Application-Gateway an der Stelle
einsetzen und gucken, ob da alles in Ordnung ist, was die Inhalte
angeht.
Dann haben wir hier noch einen weiteren Punkt, nämlich Logging und
Auditing.
Es geht hier hauptsächlich darum, um festzustellen, wer was wann in
dem System gemacht hat.
Also zum Beispiel, wir haben jetzt den Information-Broker habe ich
jetzt verteilt dargestellt und meinetwegen die ganzen Zugriffe, die
irgendwie dann abgewickelt werden durch das System, das ist jetzt kein
realer Weg, irgendeiner halt.
Es wird auf jedem Rechner zum Beispiel aufgeschrieben, ja der HTTP
-Server hat mich an dem Tag um das und das und das gebeten und ich
habe das so und so erfüllt, nämlich ich habe diesen Aufruf
weitergeleitet an den Rechner und so weiter.
Also ganz die Sachen um folgen zu können, wirklich wer was in dem
verteilten großen System gemacht hat.
Aus dem Grund, dass man später feststellen kann, wie das System
funktioniert.
Kann man auch sehr gut zum Beispiel Missbrauch dadurch erkennen.
Diese Throat Protection, das steht für dass man nicht nur externen
Missbrauch zum Beispiel, sondern internen Missbrauch erkennt.
Und da gibt es auch sehr gute ausgefeilte Verfahren, die zum Beispiel
mit Data Mining Methoden aus diesen Log-Dateien versuchen,
irgendwelche Angriffe zu erkennen.
Das ist halt sehr kompliziert und manchmal auch halt gefährlich, wenn
man plötzlich einen Unschuldigen versucht zu sagen, du warst das und
hast das und das in meinem System gemacht.
Also da muss man halt sehr aufpassen und die Provider zum Beispiel
eine Telekommunikationsfirma muss damit sehr sehr vorsichtig umgehen
mit diesen Throat-Sachen, was Richtung Kunden angeht.
Und intern natürlich müssen die Firmen dann immer gucken, welche
Mitarbeiter ist wirklich vertrauenswürdig und welche nicht.
Und genau das gucken, ob die Leute, die vertrauenswürdig sind, dass
sie wirklich vertrauenswürdig sind und nur das tun, was sie wirklich
tun dürfen in dem System.
Das ist die Aufgabe von diesen Throat Protection.
Klar, zu dem Accounting gehören solche Bezahlungsmaßnahmen, dass man
für das, was man gemacht hat in dem System, zum Beispiel Geld fordert
oder so und dann muss halt der Benutzer nach jeder Anfrage an diese
Datenbank zum Beispiel 5 Mark zahlen, dass man das wirklich nachweisen
kann.
Du hast das gemacht an dem Tag und musst jetzt dafür 5 Mark bezahlen
und ich habe das schon über dein Bank-Account also Konto abgebucht.
Ein wichtiger weiterer Punkt, das kann auch wieder anderswo natürlich
erscheinen in dem System, also auch schon an dem HTTP-Server zum
Beispiel kann das platziert werden diese Zugriffskontrolle bzw.
die Vergabe der Rechte, also der englische Begriff Access-Control
steht für Zugriffskontrolle und das ist eben dieser operativer
Prozess, wo man entscheidet, ob anhand der vorhandenen Rechte und
Vorschriften irgendjemand zugreifen darf auf die Daten, auf die
Zieldaten oder Ressourcen, wie man das schön nennt.
Und die Autorisierung, also das hier unten beschäftigt sich eben
damit, diese Rechte so zu organisieren, dass sie eindeutig sind und
dass sie zum Beispiel geschützt sind vor Manipulationen und dass sie
effizient auszuwerten sind und diese Aspekte.
Das ist dann also reines Management sozusagen, wobei die
Zugriffskontrolle, die ist mehr so Mathematik und so Auswertung von
logischen Regeln im Prinzip.
Also irgendjemand darf was schreiben an dem Objekt und so.
Und das ist zum Beispiel eine Regel, die man dann auch verknüpfen kann
miteinander und entsprechend auswerten.
Gut, gibt es Fragen zu dieser Folie oder dieser Darstellung?
Und wie gesagt, wir werden jetzt heute diese zwei Aspekte hier
betrachten.
Okay.
Nämlich, das war der dicke Pfeil eben auf dem Bild vorhin, ein
bisschen vergrößert.
Jetzt ist in unserem Fall, das kennt man aus den Büchern eigentlich,
dieses Szenario, wo der Student Alice heißt und das Zielobjekt in
unserem Fall oder der andere Kommunikationspartner Bob, das ist jetzt
in unserem Fall ein Student und ein Server, nämlich dieses Ad-Learn
-Server -System, die halt versuchen, miteinander sozusagen sicher zu
kommunizieren und dabei gibt es zwei wichtige Angaben im Prinzip, dass
dieses Ad-Learn-System eben die Skripten, die man runterladen kann von
dem Server für immatrikulierten Studenten eben umsonst, also nicht
gegen Bezahlung bereitstellt und aber anderen Studenten eben den
Zugang sperrt oder eben sagt, ihr müsst dann noch zahlen.
Und dann muss man halt feststellen natürlich, ob der Student in dem
Fall ein Berechtigter ist.
Und dann noch, was dann passiert eben, dass der Student das einfach
herunterlädt und dann will das in seiner Web-Applikation, wie vorhin
gesagt, sich anschauen und dann hoffentlich mal lernen, was da drin
steht.
Ja, das ist das sehr einfache Szenario.
Und welche Sicherheitsprobleme lassen sich hier jetzt erkennen?
Im Prinzip haben wir hier drei Aspekte aufgelistet.
Einmal die Abhörsicherheit dieser Kommunikation, die du schon letztes
Mal erwähnt hast, wo ich gefragt habe, was Sicherheit so ist.
Und eben, dass man hier feststellen muss, ob der Student ein
Immatrikulierter ist.
Und dann vielleicht auch sehr oft wichtig, jetzt nicht so wild wichtig
in diesem Szenario, aber in anderen ist halt sehr, sehr wichtig oft,
dass man wirklich sicher sein kann, dass man das richtige Skript bzw.
eine richtige Kopie von einem digitalen Content bekommt.
Und dass es halt nicht eben manipuliert wurde von irgendeinem
Unbekannten oder Bekannten, egal.
Und an der Stelle wollte ich auch noch fragen, da steht noch Punkt,
Punkt, Punkt, also wer könnte noch irgendwelche Aspekte nennen in
diesem Umfeld, die schützenswert erscheinen oder irgendwie wichtig
sind.
Hat jemand eine Idee, was an der Stelle noch wichtig ist?
Also wir wollen jetzt gegen Abhören schützen und dann gegen
Manipulation.
Was ist dann noch wichtig an der Stelle zum Beispiel?
Und wir wollen feststellen, wer der Student ist.
Was erscheint da noch wichtig zu sein?
Ja, das ist auch ein Punkt, genau.
Das ist ganz gut, dass man nicht monitoren kann zum Beispiel, wie die
Studenten agieren im System.
Das ist dann schon ein Punkt, genau.
Bei so einem Einkaufsportal zum Beispiel kommt das noch stärker
hervor, dass man feststellt, wer hat immer das und das gekauft.
Das ist ein guter Punkt.
Ich habe hier noch vermerkt, dass es nicht immer nur wichtig ist, im
Zielsystem festzustellen, wer derjenige ist, der kommt, sondern auch
umgekehrt.
Diese bidirektionale Authentifizierung, dass man auch sicher sein
kann, ich rede jetzt mit dem richtigen Server.
Nicht, dass jemand die Webseite, das ganze Layout kopiert hat,
eingestellt hat im Netz und dann mit manipulierten, ein bisschen
anders aussehenden URLs zum Beispiel eine Bank vorspielt im Netz und
dann die ganzen Kontodaten und meine Erkennungen schützt damit gar
nichts mehr.
Einfach alles klaut und die Meinungen haben später wirklich bei der
Bank agiert.
Wie nennen wir das jetzt?
Beidseitige oder beide Richtungen authentifizieren.
Ich glaube, das war es, was ich an der Stelle wollte.
Dann gehen wir noch ein bisschen konkreter rein, was sind jetzt die
Anforderungen, die man erkennt, wie man sie offiziell nennt, eben
diese Authentifizierung ist der erste Punkt.
Letztes Mal haben wir schon geklärt, was das ist.
Es ist eigentlich festzustellen, nämlich die digitale Identität von
jemand.
Also mit den richtigen Identitäten, da muss man vorsichtig sein in der
elektronischen Welt.
Das geht nämlich eigentlich nicht.
Das ist wichtig zu wissen, welche Person jetzt tatsächlich vor einem
Rechner sitzt.
Was geht?
Seine elektronische Identität festzustellen.
Das ist sozusagen eine parallele Welt und deine Darstellung in dieser
Welt, ob die stimmt, das kann man vielleicht noch gut erreichen und
die andere, diese Kupplung zwischen diesen beiden Welten, schwierig.
Wir werden sehen, wie man das versucht und eben mit diesen
Managementmaßnahmen kann man das irgendwie gebacken kriegen, aber auch
nicht so richtig.
Und diese Authentifizierungsmethoden lassen sich, also wie stelle ich
jetzt das fest, eben in drei Klassen einzustufen.
Einmal, was der Benutzer weiß.
Also wüsste jemand jetzt ein Verfahren, ganz einfach, was so
funktioniert, nach diesem Prinzip.
Genau, das Einfachste ist ein Passwort.
Authentifizierung.
Und dann gibt es noch andere, dieses, was man so hat.
Hätte man dazu ein Beispiel?
Muss nicht elektronisches Beispiel sein.
Was man so hat.
Einen Schlüssel zu einer Tür oder auch einen kryptographischen
Schlüssel, an der Stelle ist es egal.
Nämlich, was hier wichtig ist natürlich immer, what you know, also was
nur du weißt oder was nur du hast.
Das ist der Punkt an der Stelle.
Und dann, nächste Kategorie, habe ich jetzt so genannt, wie man
aussieht, also diese ganzen biometrischen Geschichten, vielleicht
kennt ihr dann auch ein paar Beispiele, zum biometrischen Verfahren.
Bitte?
Genau, oder?
Fingerabdruck.
Die Techniken, die Prinzipien sind sehr schön.
Die sind wirklich eindeutige Merkmale eines biologischen Objektes.
Aber die Abbildung in die elektronische, dieses Shiften, ist verdammt
schwierig.
Und es gibt halt sehr viele Probleme mit solchen Systemen, dass man
zum Beispiel nach einem Abend in einem Bierkeller, dann nimmt man
einfach einen Fingerabdruck von der Kollegin vom Krug ab und gießt das
irgendwie rein in so ein Plastik- oder Silikonteil.
Und am nächsten Tag geht er mit dem shoppen.
Kann man auch noch vorwerfen, damit zum Beispiel die Temperatur von
den Fingern stimmt, 37 Grad ist auch nicht so das Problem.
Und die sind halt auszutricksen, diese ganzen Systeme.
Wobei die anderen auch.
Und mit dem Passwort-System ist das Problem, die Passwörter sind
schlecht, meistens.
Benutzerwählen, Geburtstagsdatum oder Namen des Geliebten und so
weiter.
Und das einzige ist vielleicht, was an der Stelle hilft, wenn man
diese miteinander kombiniert.
Wenn man versucht zum Beispiel kryptografische Schlüssel auf dem
Smartcard zu brennen, da kombiniert man zwei Sachen.
Und dann den Zugang regelt man zu dieser Smartcard eben über so einen
Fingerprint.
Dann hat man schon drei Aspekte miteinander kombiniert.
Was natürlich nicht heißt, dass man die nicht knacken kann, diese
Hardware -Maßnahmen sozusagen.
Aber man hat halt bessere Chancen, dass wenn die Karte gestohlen wird,
da hat man immer noch zwei Sachen, die man über den regulären Weg
zumindest wissen müsste beziehungsweise präsentieren müsste.
Und es ist eine andere Sache natürlich, wie man die Informationen aus
der geklauten Karte herausgewinnt.
Also nicht über den regulären Weg sozusagen.
Zu dem werden wir auch ein Beispiel sehen später.
Dann, diese sichere Internetkommunikation habe ich jetzt genannt.
Das sind zwei Aspekte.
Die Integrität der Daten und die Vertraulichkeit.
Die muss man schützen, also sehr oft.
Und was ist die Integrität eigentlich?
Dieses Wort, was bedeutet das?
Oder was würde ich damit hier sagen?
Also die Integrität heißt, dass man nicht unbemerkt verändern kann.
Dass die Daten so ankommen, wie sie weggeschickt worden sind.
Und wenn nicht, dann merkt man das irgendwie.
Die Vertraulichkeit ist eben, dass ein unautorisierter Dritter eben
nicht abhören kann.
Das sind zwei Sachen.
Einmal während der Kommunikation.
Es muss das System abhörsicher sein.
Und auch danach müssen die Daten so abgelegt werden, oder davor so
abgelegt werden, dass Unbefugte da keinen Zugang dazu haben.
Das sind andere Probleme.
Und wir werden dann sehen, wie die Kryptografie dagegen gut ist.
Also diese Maßnahmen zu erfüllen.
Und in diesem Bereich gibt es aber noch eine schöne Wissenschaft, die
auch diese zwei Ziele hauptsächlich erzielt.
Weiß jemand, wie die heißt?
Wie kann man noch Daten gegen jemand schützen?
Außerdem, dass wir die irgendwie verändern.
Genau.
Richtig.
Das kann man hier vermerken.
Wenn man das lesen könnte.
Es geht halt darum, dass die Daten einfach versteckt sind.
Vielleicht sogar verschlüsselt versteckt.
Dass man überhaupt nicht weiß, da ist was zu brechen.
Das ist das Schöne daran.
Der nächste Punkt, was wir vorhin genannt haben, ist die
Authentifizierung bzw.
die Zugriffskontrolle.
Wir wissen schon, was die sind.
Einmal das Management.
Und dann die Prüfung, ob die Daten das ergeben, dass jemand Zugriff
hat zu dem System.
Und dabei gibt es ein paar Ansätze, die ich auch in dem Skript erwähnt
habe.
Also vor allem, was die Verwaltung der Daten angeht.
Das werde ich jetzt einfach mal stichwortartig aufmalen.
Man kann im Wesentlichen drei Systeme unterscheiden.
Einmal diese diskrete Zugriffskontrolle.
Sogenannte Skript.
Und es geht darum, dass man die Rechte zu den Objekten hin definiert.
Also die Zielobjekte haben irgendwelche Metadaten oder irgendwelche
Listen, die man auch Access-Control-Lists sehr oft nennt.
Wo die ganzen Zugangsrechten von den einzelnen Benutzern zu diesem
Objekt definiert sind und aufgelistet in einer Liste.
Und dann gibt es eine andere Sorte.
Das sind diese Mandatory-Access-Control-Sachen.
Da ist es sehr einfach, die Verwaltung von den Daten.
Weil man einfach Stufen feststellt.
Man sagt, das Objekt so und so, zum Beispiel ein Skript, ist Stufe Top
Secret.
Und man sagt, ein Student XY bekommt die Stufung auch Top Secret.
Dann, wenn dieser Student sich bei dem System anmeldet, dann wird so
ein Matching stattfinden.
Und man feststellt, ob der Student auch Top Secret ist.
Also wenn der Student Top Secret ist, dann darf er zum Beispiel alle
Daten lesen mit der Stufe Top Secret.
Und zum Beispiel darf sie aber nicht schreiben.
Solche Policies kann man zu diesen Stufen sehr einfach definieren.
Weiß jemand vielleicht ein System, was so funktioniert?
Es gibt immer noch solche.
Es ist ein ziemlich altes Konzept.
Vor allem im Militärbereich gibt es so etwas.
Mittlerweile hat das eine...
Das sind zwei Wissenschaftler.
Zum Beispiel Solaris gibt es noch.
Es gibt so eine Trusted Solaris.
Und da wird das so verwendet.
Kann jemand ein Beispiel für DAC nennen?
Ganz einfach.
Also alle Betriebssysteme, die man sonst kennt, werden so organisiert.
Und dann haben wir noch einen weiteren Ansatz.
Dieses Rollenbasierte Zugriffskontrolle, wo man die Daten
personorientiert speichert.
Letztendlich, dass man feststellt, meine Besitzer haben in dem System
verschiedene Rollen, die sie aufnehmen können.
Zum Beispiel der eine ist Oberarzt, der andere ist ein normaler Arzt,
der andere ist eine Krankenschwester, ein Portier usw.
Und die Benutzer werden dann zu diesen Rollen zugeordnet.
Und wenn jemand sich anmeldet und sagt, ich bin Benutzer X, das kann
er dann auch nachweisen, zum Beispiel durch das, was er weiß, dann
wird man feststellen müssen, welche Rechte hat er nun?
Welche Rollen hat er im System?
Und dann hat man sehr schnell die Rechte zusammen, die er hat.
Und kann man anhand dessen die Entscheidung treffen.
Der weitere Punkt, also diese beiden Punkte erzähle ich nur deswegen,
weil wir die nicht behandeln werden in der Vorlesung detaillierter.
Eben diese ganzen Systemsicherheitssachen, Trojanische Pferde,
Virusgeschichten und Würmer, hauptsächlich, die man so kennt, wusste
eigentlich jemand, was ist der Unterschied zwischen diesen dreien?
Was zum Beispiel ein Trojanisches Pferd ausmacht, gegenüber einem
Virus zum Beispiel.
Genau.
Also der Punkt ist da, dass dieses Pferd eben irgendwelche Ressourcen
in dem Rechner oder in dem ganzen System dahinter oder wie auch immer,
unberechtigter Weise nutzt.
Und auch zum Beispiel das Netz dazu nutzt, sich zu verbreiten oder
eben einen Wurm über das Netz auf das nächste System zu schicken.
Dazu kennt ihr auch bestimmt ein Beispiel, was in der jüngeren
Vergangenheit große Schaden verursachte.
Richtig, zum Beispiel in ihm da.
War so ein Teil.
Und was ein Virus halt macht, ist mehr, was jeder wahrscheinlich, der
versucht sich halt zu kopieren und wirklich wie so ein Virus
funktionieren im System und macht die lokalen Daten sozusagen kaputt.
Und dann, wenn er sich verbreiten kann, dieses Stück Programm, wenn es
sich verbreiten kann, dann kann man auch die beiden kombiniert
betrachten sozusagen.
Hat ein Wurm auf Funktionalität, ein Virus.
Das kann man so sagen.
Und das Ganze wird mit einem treuartigen Pferd auf das System
gespielt.
Genau wie die Gegenmaßnahmen sind auch die Angriffsmaßnahmen natürlich
miteinander immer zu kombinieren.
Das wollte ich nur damit sagen.
Fragen dazu?
Dann habe ich eine Frage.
Jetzt haben wir ein bisschen gesagt und jetzt habe ich hier eine Frage
gestellt.
Was denkt ihr, ob sich das lohnt, irgendwelche Daten zu verschlüsseln?
Das heißt, gegen Abhören zu schützen, wenn man nicht festgestellt hat,
wer auf der anderen Seite sitzt.
Was denkt ihr grundsätzlich?
Eigentlich egal, wer auf welcher Seite sitzt, nur dass man das andere
Leute nicht erkennt.
Du hast recht.
Aber das macht sehr wenig Sinn.
Beziehungsweise keinen.
Weil ich muss feststellen, bevor ich etwas verschlüssele, muss ich
irgendwie eine Gegenpartie haben, der das verschlüsseln kann.
Und nun er.
Wenn das noch andere können, dann kann ich das gleich unverschlüsselt
wegschicken.
Dann kommen wir jetzt in die Problematik der Verschlüsselung.
Wie ist die schöne Aussage oben?
Man muss die Daten, die man wegschickt, transformieren, die man
Verschlüsselung nennt.
Und dazu gibt es zwei wesentliche Richtungen in der heutigen Welt.
Nämlich dieses symmetrische Verfahren.
Oder man nennt sie auch Verschlüsselung.
Oder Verschlüsselung.
Secret Key Verfahren.
Man sagt auch nur Private Key Verfahren.
Aber jetzt werden wir sehen, dass das falsch ist.
Und dann diese asymmetrische Verfahren, die man auch Public Key
Verfahren bezeichnet.
Oder Public Key Kryptosysteme.
Wenn diese Schlüsselworte vorkommen, dann wisst ihr, worum es geht.
Und zunächst werden wir diese symmetrische anschauen.
Und dann werden wir einige Schwachstellen feststellen.
Und dann gehen wir über die asymmetrische.
Und dann gibt es auch Schwachstellen.
Und dann werden wir sehen, wie die Lösung in den heutigen
Implementierungen aussieht.
Nämlich, dass man hybride Verfahren verwendet.
Wo die Vorteile von den beiden kombiniert werden.
Und gleichzeitig die Nachteile eliminiert.
Ganz interessant.
Okay.
Also bei den symmetrischen Verfahren.
Was war da früher das Problem immer?
Wüsste das jemand?
Diese Verschlüsselung ist eine ganz alte Geschichte.
Die Römer und der Cäsar haben schon verschlüsselt.
Da gibt es auch immer noch eine Cäsar-Verschlüsselung.
Wobei sie eigentlich noch nicht erkannt haben.
Oder auch scheinen immer noch einige das nicht einzusehen.
Dass halt wirklich die Sicherheit ist besser, wenn das nicht von der
Geheimhaltung des Algorithmus abhängt.
Wenn ich dann irgendwie was verschlüssele und dann sage, dieser
Algorithmus ist toll, kennt keiner.
Nur mein Kommunikationspartner.
Dann ist das nicht so.
Und dann kommunizieren wir mal ewig so, weil keiner weiß, wie wir das
verschlüsselt haben.
Und dieser Ansatz ist falsch.
Das hat auch zum Beispiel der Zweite Weltkrieg sehr schön gezeigt.
Also klar, für diese Partei war das nicht so erfreulich.
Aber für die Alliierten war das sehr günstig zum Beispiel.
Also man soll halt versuchen, solche Verfahren zu entwickeln, wo die
Sicherheit von einer einmaligen Geheimhaltung heimlich sozusagen
abhängt und nicht der Algorithmus selbst ist geheim.
Das ist jetzt die heutige Stoßrichtung.
Und das aus dem Grund, weil dann man sagt, ich habe einen neuen
Algorithmus und dann sagen, da gehen 80 Wissenschaftler rein,
Mathematiker, und versuchen das zu knacken.
Und wenn das ihnen gelingt, dann veröffentlichen sie das und sind sie
berühmt.
Der Algorithmus wurde geknackt.
Und dann weiß man aber, wenn diese 80 Leute oder 100 oder 200 oder
2000 Wissenschaftler über 10 Jahre kein Ergebnis erreichen, wo man
denkt, die hätten das veröffentlicht, wenn sie was gefunden hätten,
das ist auch wieder ein Punkt, dann geht man davon aus, mein Verfahren
ist doch sicher, hängt nur von dem Schlüssel ab.
Und wo der Schlüssel wirklich so eine große Rolle spielt, oder am
größten Rolle spielt, sind diese symmetrischen Verfahren, wo man
einfach versucht, irgendeine geheime Zahl auszutauschen.
Zum Beispiel in unserem Fall diese Adler und der Benutzer, die zwei,
tauschen so eine geheime Zahl aus, die man dann Schlüssel nennt, wobei
das nicht ganz stimmt, weil bis aus einer geheimen Zahl Schlüssel
wird, das ist immer abhängig, zum Beispiel von den Verfahren, die sie
verwenden wollen, muss man halt unterschiedliche Merkmale haben, diese
geheime Zahlen, die man da nutzen kann, zum Beispiel die
Schlüssellänge, also wie lange ein Schlüssel sein kann und so weiter.
Und wie das dann abläuft schematisch, also jetzt haben wir hier diese
Skripten, also irgendwelche Daten, mit diesem Schlüssel wird das von
dem Server, in diesem Fall verschlüsselt, also mit diesem gemeinsamen
Schlüssel verschlüsselt, dann entsteht eine Chiffre, das wird über das
Netz gesendet und gehofft, dass es niemand knacken kann, weil dieses
Geheimnis hier wirklich ein Geheimnis ist.
Und dann auf der anderen Seite mit dem gleichen Verfahren, mit dem
gleichen Schlüssel entschlüsselt und dann wieder gewinnt man daraus
die Nutzdaten, also in unserem Fall dieses Skript.
Okay, ich glaube das ist ein ganz einfaches Schema.
Wüsste jemand irgendwelche Beispiele für solche Verfahren?
Also symmetrische Verschlüsselungsverfahren?
Bitte?
DES, genau.
Welche Schlüssellänge hat DES?
Genau.
Ist das noch sicher heutzutage?
Was ist die Abhilfe an der Stelle?
Was ist die Abhilfe?
Weißt du wie das funktioniert?
Also man kombiniert eigentlich den gleichen Schlüssel, man hat immer
noch diese 56-Bit-Schlüssel, was man so hat, und wiederholt das ganze
Ding dreimal, und zwar so, dass man einmal verschlüsselt, dann
entschlüsselt, dann wieder verschlüsselt und die Schlüssel immer
wieder transformiert.
Und die effektive Sicherheit ist aber nicht dreimal 56 an dieser
Stelle, das wurde auch nachgewiesen, sondern höchstens 112.
Aber das reicht dann schon aus.
Also bisher ist es ganz gut.
Wobei DES als ehemaliger Standard jetzt abgelöst wird von IES.
Das ist dieser Rheindale-Algorithmus, wenn jemand schon davon gehört
hat.
Das hat dann auch variabler Schlüssellänge und scheint eben ziemlich
sicher zu sein, weil das so eine 2- oder 3-jährige intensive Analyse
von mehreren Wissenschaftlern eben ausgehalten hatte.
Wobei man nicht weiß, was sie bei NSA gefunden haben wieder.
Also diese amerikanische Sicherheitsabteilung da.
Vielleicht sagen sie nämlich nicht, was sie alles wissen.
Zum Beispiel bei DES war das auch der Fall.
DES wurde so entwickelt in den 70er Jahren, dass sie ein
kryptografisches Analyseverfahren schon damals kannten, was die ganze
Welt noch nicht kannte.
Und DES war interessanterweise sicher gegen dieses neue Verfahren, was
man Ende der 80er veröffentlicht hatte.
Und dann genau festgestellt hatte, dieses Verfahren funktioniert gegen
DES nicht.
Das hat man festgestellt, weil diese Amistan, diese Institution, das
schon vor 15 Jahren wusste von dieser Analyse, aber einfach nicht
veröffentlicht haben.
Jetzt ist die Frage, was wissen sie bei den anderen Verfahren.
Also, das weiß man nicht.
Okay, gehen wir weiter.
Ich habe hier jetzt so ein Beispiel gemacht, oder reingekopiert
eigentlich aus einem Querkode von so einem Programm, wo man dann mal
anschauen kann, wie aufwendig ist das für die Entwickler, das richtig
zu implementieren.
Das war so ein ganz einfaches Blockschema vorhin.
Und die Implementierung eines, wirklich nur einer Verschlüsselung mit
dem Verfahren RC2, also RC steht für RIVEST Cipher, das ist auch der
Erfinder von RSA, werden wir später sehen.
Und was man hier einfach davon mitnehmen muss, ist, dass jetzt
Verschlüsselung, es gibt halt in seltensten Fällen in irgendwelchen
Entwicklungssystemen so einen Befehl, verschlüssel mir den Text und
gib mir das Ergebnis und dann sind wir glücklich.
Sondern man muss da noch ewig Sachen vorbereiten, meistens, das ist
jetzt ein C-Sharp, könnt ihr wahrscheinlich schon erkennen, aus den
vorherigen Vorlesungen.
Man muss halt eben entsprechend initialisieren und dann in diesem Fall
wird halt kein Schlüssel ausgestauscht, sondern lokal generiert und
verwendet.
Und unterschiedliche Sachen unternehmen, zum Beispiel hier, was ich
erwähnen wollte auf jeden Fall, sich gegen Buffer-Overrun und sowas
schützen.
Das ist immer ein Problem, was gerade bei diesem Hersteller hier oft
vorkam in der Vergangenheit, was halt nicht unbedingt an dem
Hersteller liegt.
Also die Systeme bieten das schon an, das zu machen.
Aber das ist genau die Verantwortung des Entwicklers, ob er diese
Sachen immer nutzt.
Overflow, genau.
Und das ist genau...
Der Entwickler muss damit irgendwie klarkommen, dass man das immer so
machen muss und nicht anders.
Und dann ganz zum Schluss irgendwo in einer Zeile wird eigentlich
dieser verschlüsselte Text entstehen.
Also eine Zeile ist dieser Nutzcode und der Rest ist das genau, was
die Sicherheitslösungen immer so langsam macht.
Das muss man immer in Kauf nehmen sozusagen.
Wenn man was absichert, wird das ganze System entsprechend langsamer.
Hauptsächlich deswegen, weil man solche Codes nochmal einfügen muss in
sein System.
Also neben Nutzcode sozusagen Unnutzcode daneben.
Okay, damit wollte ich euch jetzt nicht aufhalten länger.
Aber wir wollten jetzt eigentliche grundsätzliche Probleme dieses
symmetrischen Verfahren betrachten.
Nämlich, man muss halt irgendwie dieses Geheimnis austauschen.
Über einen sicheren Kanal, das ist ja klar, oder?
Wenn ich will, dass nur zwei Parteien irgendeine Zahl kennen, dann
muss ich irgendwie diese Zahl kommunizieren.
Irgendwie diese Zahl austauschen oder generieren oder sonst wie.
Und das ist genau der Punkt, dass es an sich ein Gefahr ist, das ist
klar.
Aber wenn man das irgendwie löst, ich kann also sicher Schlüssel
austauschen, dann warum kann ich nicht gleich die ganze Kommunikation
über diesen Kanal abwickeln?
Wenn ich eben einen Kanal hätte, wo ich die Schlüssel sicher
austauschen könnte, dann könnte ich auch meine ganzen Nutzdaten über
diesen Kanal austauschen, oder?
Das ist, ja?
Wenn ich meine Sicherkommunikation zeitmäßig hätte, jetzt habe ich
eine Sicherkommunikation, ich sehe nicht, ich gebe das Kettchen weg,
und dann muss ich mit Worten kommunizieren.
Genau, zum Beispiel das ist so ein Fall, wo das eine Berechtigung hat,
das zu machen.
Und dann ist aber die Sache, wie lange ist dieser Schlüssel noch gut?
Man muss auch immer wieder diese Schlüssel wechseln, muss man wieder
treffen.
Das ist halt manchmal ein Problem.
Und es gibt Verfahren, die sogar, die zum Beispiel bombensichere
Sicherheit anbieten, diese One-Time-Pads, vielleicht habt ihr da schon
diesen Begriff gehört, wo man eben einen Schlüssel nur für eine
Nachricht verwendet.
Aber da muss man halt verdammt viele Schlüssel in einem Koffer haben,
oder so.
Und man muss immer wissen, dass die Reihenfolge auch richtig ist,
sonst hat man keine Chance, das zu entschlüsseln.
Und wenn man zweimal einen Schlüssel verwendet, dann kann man das
Ganze haken.
Das ist auch interessant.
Und noch ein Problem, so grundsätzlich ist, man hat ein Geheimnis bei
zwei Leuten.
Da gibt es ja den Spruch, was mehr als ein Mensch weiß, ist kein
Geheimnis mehr.
Und so ist das auch.
Und eigentlich, ja, also daraus resultiert sich ein Problem, das
vielleicht jetzt euch dann auch aufgefallen ist.
Was ist das Problem, wenn zwei dieses Geheimnis kennen?
Das Problem ist an der Stelle...
Ein Schlüsselwort.
Kennt jemand diesen Begriff?
Dieses Unabstreitbarkeit, auf gut Deutsch.
Dass wenn nämlich zwei dieselbe geheime Zahl kennen und jemand etwas
verschlüsselt, wie kann ich dann sicher sein, dass er das war und
nicht der andere?
Da gibt es mindestens zwei Leute, die den selben Text entweder
erstellt haben oder gesendet haben und wenn es darum geht, zum
Beispiel, irgendein Schriftwort wurde gesendet an den Präsidenten und
man will das dann zurückverfolgen, da hat man gleich zwei
Möglichkeiten, wer das war.
Und man hat nichts in der Hand, das eindeutig zu entscheiden, wer der
Absender war.
Jeder kann sagen, er war das, er hat den Schlüssel auch.
Nein, er war das, er hat den Schlüssel auch.
Man muss die beiden in den Knast schmeißen.
Und noch ein Problem an der Stelle.
Wie ist die Anzahl der Schlüssel, die man braucht?
Insgesamt.
Also da gibt es ein großes Problem aus dem Management, wenn man mal so
will.
Nämlich, ich muss ja mit allen, wenn ich N Teilnehmer in einem
Netzwerk habe und ich will mit allen sicher kommunizieren, so, dass
die anderen in dem Kreis und auch die ganze Außenwelt das nicht
abhören kann, dann brauche ich von jedem jeweils einen Schlüssel.
Das will ein jeder so haben.
Wie viele Schlüssel gibt es dann insgesamt im System, bei N Benutzern?
Ja, richtig.
Gut erkannt.
Und das ist ein Problem.
Wenn man eine Million Teilnehmer hat, kann man gleich haken, dass man
eine Schlüsselzentrale aufbaut.
Für diese Verfahren kann man gleich vergessen.
Und im Wesentlichen sind das die Probleme, die dazu geführt haben bzw.
die Notwendigkeit der asymmetrischen Verfahren begründen.
Und deswegen hat das eben diese Diffie und Herrmann publiziert.
An den 70ern, wobei sie auch wieder zu spät waren, weil Geheimdienste
bei den Briten in diesem Fall dieses Verfahren schon früher
wiedererkannten, weil sie es nicht veröffentlicht haben.
Also das Grundprinzip.
Aber in der Fachliteratur findet man immer, Erfinder sind Diffie und
Herrmann.
Für die offizielle Welt ist es so, aber für den Rest eben in Grauzone
ist es halt nicht so.
Gut, das Prinzip ist so, dass jeder Teilnehmer eben zwei Schlüssel
hat, die miteinander zusammenhängen, voneinander abzuleiten sind.
Wobei, nee, nicht abzuleiten, sondern die passen zusammen.
Das wäre schlecht, wenn sie abzuleiten wären.
Einmal hat dann jeder einen privaten Schlüssel und einen öffentlichen
Schlüssel, so genannten.
Und die werden halt genauso generiert, dass man die nicht ableiten
kann voneinander.
Aber trotzdem haben sie diese Eigenschaft, diese Schöne, dass wenn man
mit dem Public Key von jemandem irgendwas verschlüsselt, das kann nur
diese Zielperson mit seinem privaten Schlüssel entschlüsseln.
Ganz einfach.
Und es gibt Verfahren, wo man deshalb umgekehrt geht, wo man was mit
dem privaten Schlüssel verschlüsselt, das kann man mit dem
öffentlichen entschlüsseln.
Beziehungsweise, das ist nur eine Sichtweise.
Welche Schlüssel will ich veröffentlichen von den beiden, welche halte
ich geheim.
Es gibt momentan nur ein Verfahren, was bekannt ist und wirklich diese
beiden kann.
Wie heißt das?
Richtig, RSA.
Das kann diese beiden und für die, das kann man vielleicht so, es kann
beide Aspekte und kennt jemand vielleicht ein anderes Verfahren, das
zum Beispiel 0.2 kann.
Also ein anderes symmetrisches Verfahren, mit dem man diese
Eigenschaft erfüllen kann.
Also zum Beispiel ein Beispiel ist dieses DSS.
Das ist offizieller Signaturalgorithmus.
Also Digital Signature Standard.
Oder dieses Algamal Verfahren.
Also in die Eigenschaften von RSA und wie man das jetzt schön aufbaut,
können wir jetzt leider nicht reingehen, so gerne ich das machen
würde.
Ihr könnt aber sehr gerne nachlesen.
Ich habe in dem Skript dann auch dieses Papel reingehängt, wo sie RSA
1978 veröffentlicht haben.
Seitdem nicht geknackt.
Und ist wirklich wunderschön beschrieben und man kann einfach auch so
verstehen, wenn man nicht so viel von der Mathematik weiß.
Also man wird natürlich nicht wissen, warum RSA sicher ist.
Das ist immer noch eine offene Frage, ob RSA überhaupt sicher ist.
Aber bisher konnte keiner beweisen, dass sie nicht sicher ist.
Auch ganz interessant.
Gut.
Also das war jetzt klar, dieses Prinzip.
Was ich mit dem privaten Schlüssel verschlüssele, kann man mit dem
öffentlichen Schlüssel oder umgekehrt.
Das wird jetzt hier nochmal dargestellt in dem Szenario.
Wenn man jetzt dieses Verfahren einsetzt, dann hätte man diese Server,
will jetzt was verschlüsselt an den Benutzer schicken.
Was macht er?
Er nimmt den öffentlichen Schlüssel von dem Benutzer, verschlüsselt
damit das Skript, entsteht dann wieder ein verschlüsselter Text,
schickt über das Netz und der Benutzer nutzt seinen privaten
Schlüssel, was nur er hat und gewinnt daraus die Nutzdaten wieder.
Okay.
Das glaube ich ist klar, oder?
Wie das prinzipiell funktioniert.
Dann...
Gut.
Jetzt haben wir dann ein paar Vorteile dieses Verfahrens.
Grundsätzlicher eben, dass man eben den Schlüssel, mit dem man
verschlüsseln kann, veröffentlichen kann.
Alles kein Thema.
Hauptsache man kann das nicht entschlüsseln.
Das ist der Punkt bei der Verschlüsselung, haben Biffi und Hermann
erkannt.
Und ich brauche eben nicht den sicheren Kanal, diese Schlüssel
auszutauschen.
Superklasse für mich im Internet.
Und eben diese Gefahr, dass der Schlüssel bekannt wird für anderen,
ist auch schon dadurch reduziert, dass er grundsätzlich nur einer
Person gehört.
Und das reduziert auch eben diese Gefahren, dass jemand die klaut,
diesen Schlüssel.
Eben weil das nur eine Person kennt.
Und welche zwei Vorteile kennt man noch, oder die eben vorhin
eigentlich nachteilig waren, sind das jetzt ausgebügelt worden.
Nämlich, weil ich nur den privaten Schlüssel kenne, dann kann man über
non -repudiation, wieder dieses schöne Wort, reden, werden wir sehen
später wie.
Und die Anzahl der Schlüssel in dem ganzen System reduziert sich auf
N.
Das ist auch sehr schön für mich.
Also ich brauche nur N Schlüsselpaare insgesamt.
Ich kann dann sehr schön Schlüsselzentrale oder Public Key
Infrastruktur oder was auch immer, wie man sie nennt, aufbauen.
Und dann sehen wir jetzt die Vorteile.
Aber ein Problem mit diesem Asymmetrischen ist, dass sie wegen der
aufwendigen Mathematik, also die Operationen, die dort verwendet
werden, so potenzieren, gut Modulo ist nicht so, aber weil sie
riesengroße Zahlen brauchen zum Beispiel, brauchen die auch verdammt
lange, bis sie irgendwas ausgerechnet haben.
Ist zwar sicher, was entsteht, aber für die Nutzung in der Welt ist es
unerträglich langsam.
Also wenn ich jetzt ein Dokument einfach so verschlüsseln will, mit
einem asymmetrischen Verfahren, kann ich gleich schlafen gehen und
dann morgens wiederkommen.
Ungefähr.
Also mit einem normalen Rechner.
Und deswegen hat man das erfunden oder eingeführt, diese hybride
Verfahren, die einfach diese beiden Sachen kombinieren, nämlich ein
sogenannter Session Key wird mit einem Public Key Verfahren
ausgetauscht.
Also ein Session Key ist dann wie lang?
Ein paar hundert Bit, oder?
Je nachdem, was diese symmetrischen Verfahren an Schlüsseln brauchen.
Also meinetwegen 128 Bit oder so.
Das wird mit diesem Verfahren sehr schnell verschlüsselt,
rübergesendet, entschlüsselt und dann, ab dann, für die eigentliche
Nutzkommunikation wird dann ein symmetrisches Verfahren eingesetzt.
Und eben mit diesem Session Key, was man über diesen sicheren Kanal,
was man mit dem Public Key Verfahren geschaffen hatte, wird das
ausgetauscht und dann ein ganz normaler symmetrischer Algorithmus wird
verwendet und dann die ganze Kommunikation geht sehr flott.
Der Faktor ist ungefähr 1.000 bis 10.000 fache Beschleunigung ist
damit zu erreichen.
Das ist auch eine interessante Sache, weil eben diese symmetrischen
Verfahren sehr oft so realisiert sind, dass sie einfach XO-Operationen
verwenden.
Also du schmeißt deinen Text rein und den Schlüssel, die werden dann
ordentlich durcheinander gewühlt und gewurfelt, aber diese
einheitlichen Operationen, die kleinsten Operationen, sind meistens
sehr einfache hardware-nahe Operationen, die man auch wirklich als
Zielhardware realisieren kann.
Und dadurch erreicht man eben eine brutale Beschleunigung.
Wobei es gibt jetzt auch Hardware-Elemente, die zum Beispiel RSA
unterstützen.
Also nur ein Hardware-Ding, was nur RSA-Verschlüsselung macht.
Und da kann man auch Optimierungen machen, wir werden dazu ein
Beispiel sehen später.
Und meine Frage wäre, löst da jemand ein Beispiel-Protokoll zum
Beispiel, das so aufgebaut ist auf diesem Prinzip?
Zum Beispiel SSL, genau.
Sehr gut.
Zum Beispiel SSL.
Okay.
Dann haben wir hier so ein zusammenfassendes Bild, es ist nochmal die
beiden aufeinander, übereinander gestellt, dass man nochmal zeigt,
dass dieser Session-Key ausgestauscht wird mit dem öffentlichen und
privaten Schlüssel und dann mit Hilfe dieses Session-Keys wird dann
die Kommunikation verschlüsselt.
Ja, schönes Bild, aber sagt keine zusätzliche Information mehr, glaube
ich.
Gibt es jetzt Fragen zu den bisherigen Sachen?
Gut, wenn nicht, dann gehen wir weiter.
So, jetzt haben wir ja irgendwas erreicht gegen diese Abhörer, die
dann sozusagen passiv bei einer Leitung irgendwie abhören können.
Wie auch immer sie das schaffen.
Aber wir haben ja auch nichts darüber gesprochen, wie man zum Beispiel
die Identität der Kommunikationspartner hier in Sender und Empfänger
feststellt und wir haben auch noch nicht darüber geredet, wie man
diese Integrität dann tatsächlich schützt während der Übertragung.
Und ein Mittel zum Zweck an dieser Stelle sind die digitalen
Signaturen, die einen mittlerweile sehr breiten Einsatz in der Welt
gefunden haben.
Es gibt ja auch Signaturgesetz mittlerweile und all diese Sachen, das
kommt so langsam rein in das alltägliche Leben und deswegen haben wir
jetzt das gewählt als Feststellung dieser Identität.
Das war unser erstes Ziel eigentlich, diese Authentifizierung
irgendwie hinzubekommen.
Und an der Stelle, was die digitale Signatur für mich sichert,
elektronische Sicherheit bietet sie ja natürlich.
Also wieder diese meine Darstellung in der elektronischen Welt, also
nicht die Person, wer die tatsächlich war.
Also diese Identität wird sehr gut dargestellt dadurch oder
sichergestellt und die Integrität des gesendeten Dokuments, in diesem
Fall jetzt des Skripts.
Und auch weil die Identität so sicher ist, kann man über
Nichtabstreitbarkeit der ganzen Aktion, die man durchgeführt hat, also
alles was mit digital signiert war, ist irgendwie personengebunden.
Und ja, das ist eigentlich, was hier diese komplizierte Definition
sagen will.
Okay, an der Stelle wollte ich nichts mehr erzählen, glaube ich.
Gehen wir weiter.
Wie entsteht eine digitale Signatur?
Das ist das, was uns jetzt eigentlich interessiert.
Wir nutzen zuerst, in dem ersten Schritt, über Rechnen und im
Dokument, was wir digital signieren wollen, einen Hashwert.
Und dieser Hashwert entsteht als Output einer Hashfunktion, einer
sogenannten Hashfunktion, die schlampig formuliert zwei wichtige
Eigenschaften hat.
Nämlich, dieser Hashwert ist eindeutig zu diesem Eingabewert und dass
man aus dem gewonnenen Output dieses Input nicht feststellen kann.
Dass wirklich diese Eindeutigkeit sozusagen in beide Richtungen
entsteht und wie man das dann schöner formuliert, das findet ihr in
dem Skript und das solltet ihr auch dann lernen.
Wann nennen wir eine Hashfunktion?
Kollisionsresistent sozusagen.
Das ist ein wichtiger Begriff.
Okay, jetzt haben wir ein eindeutiges Merkmal über unser Dokument mit
Hilfe der Hashfunktion erstellt.
Und jetzt wollen wir eigentlich die digitale Signatur erstellen.
Was machen wir dann?
Wir verschlüsseln mit unserem privaten Schlüssel diesen Hashwert,
dieses Digest auf Englisch und hängen das Ganze an die Nachricht dran
oder an dieses Dokument dran.
Also die Nachricht an sich bleibt im Klartext, also es wird nicht
verschlüsselt oder irgendwie geändert, es wird ergänzt.
So ähnlich wie ein Dokument, was man manuell unterschreibt.
Das Dokument ist da und in irgendeiner Ecke mache ich meine
Unterschrift rein.
Und das ist genau der Punkt, was auch hier passiert.
Die Nachricht oder das Dokument bleibt unverändert und dahinter
erscheint eben eine ziemlich kryptisch aussehende Zahl.
Und das ist die digitale Signatur, was mit diesem Dokument und mit der
Person, der das erstellt hatte, zusammenhängt.
Also noch einmal, man nimmt die Hash-Funktion, die funktionieren dann
irgendwie, rödel, rödel.
Die machen daraus ein Digest.
Dieser Digest ist wie eine Hash-Funktion, wie von einer Hash-Funktion
zu erwarten ist.
Es ist ganz kurz, also z.B.
wieviel Bits kennt jemand eine Hash-Funktion?
Ja,
es gibt z.B.
160, die jetzt als sicher gilt ungefähr, weil, naja, ist egal warum,
steht auch im Skript dazu was.
Aber es gibt ja auch welche, die z.B.
128 Output produzieren.
Aber man sollte grundsätzlich bei 160 so anfangen heutzutage.
Und das ist dann so lang und wird wieder dieser kurze Digest mit
meinem langsamen, genau asymmetrischem Verfahren, mit Hilfe meines
privaten Schlüssels, verschlüsselt im Prinzip, also signiert, sagt
man.
Und das Ergebnis, dieser Digest, verschlüsselt mit dem privaten
Schlüssel, wird an die Nachricht gehängt.
Und damit ist die Signatur erstellt und kann man es das Ganze rüber
senden.
Und durch die Eigenschaften wird das, wie gesagt, sichergestellt, dass
ich das gemacht habe, weil ich den privaten Schlüssel habe.
Und dass ich diese Nachricht unterschrieben habe, weil der Hash wert,
weil die Hash-Funktion mir das garantiert.
Die Integrität schaffe ich mit der Hash-Funktion.
Die Authentizität und diese ganzen Unabstreitbarkeit-Geschichten
schaffe ich mit der Nutzung des privaten Schlüssels.
Wenn ich das eine oder das andere weglasse, dann fällt auch die eine
oder die andere Eigenschaft automatisch weg.
Gut, jetzt ist die Frage, steht auch nicht in dem Skript drin, was
fange ich jetzt mit einer Signatur an?
Angenommen ist ein Dokument angekommen bei mir, da hängt eine Signatur
dran.
Das steht ja immer drauf, Achtung, signierte Nachricht, in irgendeinem
Format, je nachdem, welches Programm das gemacht hat.
Und hinten dran ist ein Feld, die Signatur.
Jetzt muss ich feststellen irgendwie, ob das Ding stimmt.
Was muss ich da feststellen?
Die Signatur will ja zwei Sachen sichern, wie gesagt, die
Authentizität des Senders und die Integrität.
Das sind die zwei Sachen, die ich prüfen muss.
Jetzt ist die Frage, wie?
Wie gehe ich vor?
Was sind die drei Schritte, habe ich schon aufgelistet, die man hier
machen muss?
Weiß jemand?
Was nutze ich dazu?
Zweiter Schritt.
Dann mache ich A-Dokument sozusagen.
Achso, hier bekomme ich, warte mal, hier bekomme ich dann HD.
Genau, dann berechne ich, weil ich das Ganze im Klartext habe, ich
kann auch den gleichen Hash-Wert nochmal berechnen.
Was ist der nächste Schritt?
Richtig.
Und dann diese zwei Werte, A-Dokument, was ich berechnet, was ich
bekommen habe, ob das gleich ist mit dem vorher entschlüsselten HD.
Wenn das stimmt, dann ist die Signatur in Ordnung.
Wenn das nicht stimmt, dann hat jemand irgendwas gefälscht unterwegs
oder es ist ein Übertragungsfehler aufgetreten.
Beides kann sein.
Dankeschön.
Welche Probleme, wenn man jetzt als Entwickler denkt, auf was muss man
hier dann achten?
In so einem Szenario, wenn ich jetzt signiere und wieder prüfen will
und so.
Ich muss ja immer zum Beispiel sicherstellen, dass die andere Seite
die gleiche Hash-Funktion hat.
Und dass die andere Seite die gleiche Hash-Funktion so implementiert
hat wie ich.
Sehr wichtig.
Also genau dieselbe Implementierung sozusagen muss auf der anderen
Seite vorhanden sein.
Sonst stimmen diese ganzen Bit-Folgen nicht mehr und die ganze
Signatur wird wertlos.
Ich kann das nicht mehr prüfen.
Und auch in dem Dokument, weil es gibt so viele Verfahren, muss ich in
dem Dokument schon festlegen oder sagen, diese Nachricht wurde mit
diesem, meinetwegen MD5, ist ein bekannter Algorithmus.
Das ist die Hash-Funktion, die hier verwendet wurde.
Und ich habe mit RSA 1024 gearbeitet.
Liebe Verifizierer, bitte haltet das vor Augen und verwendet dieselbe
Verfahren, damit du das selbe Ergebnis überhaupt rausbekommen kannst.
Wenn das nicht der Fall ist, dann stimmt das Ganze nicht.
Das muss halt immer so integriert sein in das Protokoll, wo man dieses
nutzen will, dass genau diese Daten auch immer klar sind.
Und das ist auch ein Problem, was in SSL eben die Verbindungsaufbau so
langsam macht.
Da muss man sich erstmal über die ganzen Verfahren einigen, die
eingesetzt werden später und dann erst anfangen mit
Schüsselaustauschen und so weiter.
Gut.
Und jetzt haben wir das Problem.
Jetzt wissen wir ja sehr schön, man hat jetzt eine digitale Signatur.
Jetzt weiß ich, welcher privater Schlüssel das signiert hatte, aber
ich habe keine Ahnung, wem dieser privater Schlüssel gehört.
Jetzt kommen wir zu diesem Schritt, zu der Person hin.
Wer sitzt jetzt vor dem Rechner mit dem privaten Schlüssel?
Beziehungsweise den öffentlichen Schlüssel, den ich kenne.
Wem gehört dieser Schlüssel?
Wie kann ich sicher sein, dass es wirklich zu der Person gehört?
Und wie gesagt, dieses Problem ist schwierig zu lösen.
Und es gibt halt einen Ansatz, was man als Lösung nennen kann, aber
die Frage ist halt nur eine Lösung.
Zum Beispiel mit Zertifikaten.
Das kennt ihr bestimmt schon, dieses Wort.
Dabei gibt es in der Kommunikation, angeschaltet, aktiv, einen
sogenannten Trust-Center, der dann die Identitäten sozusagen
bestätigt.
Beziehungsweise bestätigt, dass Identität X Schlüssel Y besitzt.
Und diese Information schreibt er in sogenannten Zertifikaten rein.
Die in unserem Fall, zum Beispiel für den Studenten, wird so ein
Zertifikat ausgestellt.
Student XY hat öffentlichen Schlüssel Z oder was.
Und das ist gültig bis so und so.
Es gibt ganz viele Felder eines Zertifikats.
Und genauso für AdLearn wird man auch sowas brauchen.
Und diese Trust-Center sind an der Stelle deswegen Trust, weil man,
wenn man so ein Zertifikat bekommt, dann geht man davon aus, dass
diese Stelle nicht geschummelt hat.
Dass diese Stelle genau das bestätigt, was die Wahrheit ist.
Und es ist die Frage, ob das wirklich so ist oder nicht.
Und das ist genau das Problem mit diesem ganzen Vertrauen.
Ich vertraue das, weil keine Ahnung warum.
Also manchmal gibt es solche Bedingungen, unter denen man jemandem
vertraut.
Und andere Menschen finden das ganz anders.
Es gibt keine eindeutige Definition zum Beispiel für Vertrauen.
Das ist eine schwierige Frage.
Aber auf jeden Fall, dass ein Zertifikat an der Stelle sozusagen
technisch erfüllen muss, dass sie eindeutig sind.
Klar, die Schlüssel sind ja auch eindeutig und die Personen wohl auch.
Es gibt nur einmal Rudin und Steinwand.
Und das sind einmalige Leute.
Und der zweite ist, dass wirklich diese Trust Center die
Identifizierung der Benutzer wirklich gewissenshaft abwickelt.
Am besten so, dass man persönlich vorbeikommt.
Dazu sagen wir dann später noch was bei der BKI.
Und wirklich man vertraut, dass diese Trust Center geprüft hatte, ob
der private Schlüssel, mit dem man dann später signiert und wirklich
dem Benutzer gehört, der auch diesen Public Key vorgezeigt hatte.
Also man zeigt seinen Public Key und dann muss diese Trust Center
irgendwie feststellen, er hat wirklich den Private Key dazu.
Weil dann weiß ich, okay, ihm gehört dieser Public Key und er kann
dann auch signieren mit diesem Schlüsselpaar.
Okay, gibt es Fragen dazu?
Ja.
Okay.
Ja, also es gibt zum Beispiel...
Achso, das steht hier nicht drauf.
Also Testmethoden, die man verwendet.
Man gibt zum Beispiel eine Methode, die sehr bekannt ist oder immer
verwendet wird als erstes bei dem Testen.
Du gibst eine Bitfolge, eine ziemlich lange und dann änderst du
meinetwegen ein Bit und schaust, wie weit hat sich dieses Output
geändert.
Und dann änderst du halt wegen 50 Bit weiter auch ein Bit und guckst,
wie sich diese Ausgabe sich verhält.
Und wenn du irgendwelche Regelmäßigkeiten schon feststellen kannst und
dann auch noch den Algorithmus scannst.
Also viele testen das dann so, die sich auskennen in dem Bereich, dass
sie gewohnt an der Stelle was ändern, wo das kritisch sein kann.
Vielleicht stellen sie fest, die Hashfunktion würfelt eine Menge, also
macht erstmal so komprimieren, ähnlich wie tippen oder was.
Du kriegst am Ende komprimierte Daten heraus, das heißt der Raum der
möglichen Outputs wird beschränkt.
Und es gibt im Prinzip unendlich viele Eingabewerte, die derselbe
Output produzieren.
Aber zwei zu finden, die auch wirklich das tun, ist halt schwierig.
Und wenn das nicht der Fall ist, wenn dir das gelingt, auch nur
zufällig, dann ist die Hashfunktion wertlos.
Natürlich, wenn du sagst, ich habe eine systematische Methode
angegeben, wie die Hashfunktion zu brechen ist, dann ist sie natürlich
vollständig gebrochen.
Aber auch schon dann, wenn du zwei Eingabewerte findest, irgendwie die
gleiche Ausgabewerte produzieren, dann ist auch schon wertlos.
Weil dann kannst du zum Beispiel nicht mehr sicherstellen, ob zwei
Verträge jetzt oder ein Vertrag wirklich von dir kommt oder von jemand
anderem manipuliert wurde.
Wobei, in solchen Fällen, wo auch noch Semantik mit den ganzen Sachen
ins Spiel kommt, da wird es noch schwieriger.
Aber im technischen Sinne, also für die ganzen Krypto-Gemeinschaften
reicht das schon aus, wenn du zwei irgendwie findest.
Und Methoden gibt es zahlreiche.
Du kannst im Internet ganz gut nachschauen oder in dem Schneier-Buch.
In dem Schneier-Buch habe ich auch in dem Skript referenziert, diese
Applied Cryptography.
Da gibt es eine Menge Papers referenziert, die sich damit
beschäftigen.
Und er erwähnt das dann so in der Ecke irgendwo.
Das gibt es so verfahren.
Und dann gibt es halt dazu fünf oder sechs Papers, die hauptsächlich
aus Belgien kommen.
Da gibt es einen Guru, der das kann.
Und der auch schon oder halt in seinem Beruf fällt, die Leute dieses
MD5 zum Beispiel unsicher gemacht haben.
MD5 gilt jetzt als unsicher seit zwei Jahren oder so.
Okay, noch Fragen?
Hat jemand schon ein Zertifikat gesehen?
An den Webbrowsern, oder?
Und wie entsteht dadurch das Vertrauen?
Es entsteht so, dass Microsoft denkt, wir haben gute
Geschäftsverbindungen zu irgendwelchen Trust-Centern.
Verisign oder ähnliche.
Und wir schmeißen defaultmäßig ihre öffentlichen Schlüssel rein in den
Browser.
Und wenn irgendjemand was verschlüsselt mit so einem Schlüssel, was
durch Verisign zertifiziert ist, dann glaubt der Browser einfach ohne
Prüfung, dass das alles schön ist.
Und diese Zertifikate kann man sich anschauen.
Und dann stellt man fest, welche Felder die haben.
Meistens folgen sie dem Standard AMS X509.
Das ist so eine umfassende Beschreibung von den ganzen Feldern, was
sie bedeuten und wie auszusehen haben.
Und da steht eben die Benutzernahme drin.
Dann der öffentliche Schlüssel, selbstverständlich.
Dann Gültigkeitsperiode.
Und dann, wie der Trust-Center heißt.
Und dann so eine Serial Number, damit der Trust-Center die Zertifikate
auseinander erhalten kann.
Und eben die Unterschrift von diesem Trust-Center.
Also das Zertifikat entsteht dann so, dass der Trust-Center selbst mit
seinem privaten Schlüssel alle Zertifikate, die er ausstellt,
unterschreibt.
Und dadurch sagt, ich war das und ich habe dieses Zertifikat
ausgestellt.
Und da steht drin, der öffentliche Schlüssel dieses Benutzers.
Also ich habe jetzt Public-Key-Verfahren mit Public-Key-Verfahren
abgesichert.
Und das ist auch so ein prinzipielles Problem in der Geschichte.
Ich habe versucht, irgendwelche Maßnahmen mit dem problematischen
Verfahren zu schaffen gegen das Problem.
Schön und praktikabel, aber wahrscheinlich doch nicht so der Renner.
Aber es gibt momentan keine bessere Lösung, als praktikabel wäre.
Wie sieht das dann aus mit diesem CA hier genannt?
Also CA steht dann für Certification Authority.
Das ist der Name, was auch noch öfter vorkommt.
Also Trust-Center, Certification Authority.
Dann PKI, das ist alles im Prinzip das gleiche irgendwo.
Der Unterschied ist vielleicht, für mich ist die PKI die technische
Realisierung eines Trust-Centers.
Das werden wir in der nächsten Vorlesungsstunde sehen.
Aber wie geht jetzt so eine Zertifikats-Ausstellung dann?
Wie sieht das aus?
Zuerst, zum Beispiel, wollen wir jetzt diesen Server mit einem
Schlüssel versorgen.
Schlüsselbar, dazu generiert er selber diese Schlüsselbar mit
entsprechender Software.
In diesem Fall behält er den privaten Schlüssel bei sich und sendet
den öffentlichen Schlüssel, ist ja öffentlich, an so eine
Registrierungsstelle.
Also Registration Authority heißt das.
Und diese Nachricht, wo dieser Schlüssel drin steht, signiert er
einfach mit dem privaten Schlüssel.
Also er sagt, signiert mit dem privaten den Public Key und dann seinen
Namen, die Zeit und so weiter.
Und er schickt das an diese RA.
Und der dann stellt fest, okay, dieser Name ist eine E-Mail-Adresse,
sendet eine E-Mail, schickt mir eine Response.
Okay, haben wir festgestellt, die E-Mail-Adresse existiert.
Oder diese Domain-Name, was in diesem Fall ein SSL-Zertifikat wäre,
probiert diese RA einfach aus.
Ob wirklich ein Server kommt und dann ruft den Betreiber an.
Unter der Adresse denk.irgendwas.com ist also ein Server zu finden.
Auf der Seite in der vierten Position steht ein Buchstabe A.
Bist du das?
Ja, das bin ich.
Okay, wurde es bestätigt?
Dann guckt er.
Okay, der öffentliche Schlüssel hat auch gepasst.
Man kann die Signatur damit verifizieren.
Man geht davon aus, dass der Betreiber, also jetzt entfernt, also hat
sich nicht gezeigt, aber elektronisch seine Identität bestätigt.
Dann sagt diese Registrierungsstelle, die zum Beispiel vom Verisign
gibt es ein paar in der Welt so verteilt.
Aber die haben irgendwo eine sichere Stelle, eine CA, die dann die
Zertifikate tatsächlich ausstellt.
Und dort geht die ganze Management ab eigentlich.
Und da arbeitet im Hintergrund eine PKI oder wie man das auch nennen
mag, das System.
Und nachdem diese CA Bescheid weiß, wieder über digitale Signatur von
der RA, dass jemand mit diesen Daten ein Zertifikat beantragt hatte
und ich habe das geprüft, dann erstellt diese CA eben ein digital
signiertes Zertifikat und sendet sie dieses Zertifikat an den
Betreiber des Webservers.
Und so würde das dann genauso aussehen in diesem Fall für den
Studenten.
Wenn man diese beidseitige Authentifizierung auch mit digitalen
Signaturen lösen wollte, also mit dem SSL zum Beispiel, gibt es die
Möglichkeit kleinseitige Zertifikate zu verwenden.
Dann müsste ein jeder Student natürlich an dieser Registrierungsstelle
und sich selber Schlüssel generieren und dann den privaten Schlüssel
irgendwie sicher halten und so weiter.
Und weil das so aufwendig ist, nutzt man meistens nur bei den Servern
im Fall von SSL Zertifikate und die Benutzer werden mehr über
Passwörter identifiziert.
Man baut einen sicheren Kanal auf, also einseitig sicher
authentifiziert zu dem Server und schickt über diesen Kanal
Benutzernamen und Passwort.
Und da ist natürlich das Problem, wie bekommt der Benutzer das erste
Passwort?
Das ist schwierig.
Muss man wahrscheinlich persönlich vorbeikommen wieder.
Okay, im Prinzip hier steht es nochmal, dieser Prozess erklärt.
Deswegen ist das auch gar nicht so interessant.
Aber gibt es Fragen dazu bisher?
Nein?
Dann gehen wir weiter.
Ja, man kann diese Trust-Center in Hierarchien organisieren.
Also ihr könnt euch ja vorstellen, dass jemand hat dieses Vertrauen.
Zum Beispiel ein französischer Student sagt, also liebe deutsche
Kollegen, ihr braucht mir gar nicht zu kommen in so einen deutschen
Trust -Center.
Da geht alles schief, denkt er.
Wobei in Frankreich wahrscheinlich das eher schief geht.
Aber er denkt, in Frankreich wäre alles in Ordnung und vertraut eben
so einem französischen Vertrauensstelle.
Und sagt, ich akzeptiere nur Sachen, die irgendwie durch diese
Vertrauensstelle funktionieren.
Und dann sagt die Vertrauensstelle, ja, die Deutschen vertrauen mir
nicht.
Die wollen nur den Trust-Center Germany vertrauen.
Aus dem Grund, weil du auch nur Trust-Center Franz vertraust.
Was machen wir denn jetzt?
Wir suchen, man kann auch diese Trust-Center sozusagen ähnlich
betrachten wie einzelne Benutzer.
Und die Cross-Zertifizieren heißen, also Kreuz-Zertifizieren oder
Cross -Certification.
Durch ein Trust-Center, den man irgendwo aufbaut.
Weit wegen diesem Fall habe ich das genannt.
Es gibt nicht diese Vertrauensstelle, diese Learning Europe.
Was dann in dem Fall neutral in England stehen würde.
Bei den Franzosen ist es natürlich kritisch, aber gehen wir mal davon
aus.
Könnte auch in Norwegen dastehen.
An dieser Stelle würde dieser Trust-Center in England den öffentlichen
Schlüssel von dem Trust-Center in Frankreich bestätigen durch ein
Zertifikat.
Und auch den öffentlichen Schlüssel von dem Trust-Center Germany über
ein Zertifikat bestätigen.
Und wenn jetzt jemand, zum Beispiel dieser Student, dadurch dass sie
eine gemeinsame Vertrauensstelle haben, so eine Hierarchie, wird eben
indirekt doch diesem Server vertrauen können.
Ohne dass er jetzt irgendwie den Vertrauenssteller in Deutschland
vertraut hätte.
Nur die Prüfung wird komplizierter.
Jetzt muss ich nicht nur ein Zertifikat von einer Vertrauensstelle
prüfen, sondern eine Kette.
Bis hin, bis ich eine gemeinsame vertraute Stelle finde.
Und das einmal hoch und dann wieder runter.
Und dann stelle ich fest, okay, dieser Trust-Center England, dem mein
Trust -Center vertraut, vertraut dem deutschen Trust-Center, dem
wiederum dieser deutsche Server vertraut.
Das heißt, ich habe gewonnen, wir können miteinander sicher
kommunizieren.
Also wir können sicher sein, dass der öffentliche Schlüssel des
anderen wirklich diesen, in diesem Fall, Ad-Tag-Web-Service gehört.
Das irgendwo in Deutschland läuft und einen Domain-Namen DE hat.
Und es gibt natürlich auch andere Topologien.
Nicht nur diese Baumartigen, die man sich vorstellt, in diesem Fall,
die hier dargestellt ist.
Es kann halt beliebig aussehen.
Zum Beispiel, wenn man PGP, kennt ihr wahrscheinlich.
Das ist so eine andere Strategie, dieses Web of Trust.
Da kann halt jeder jedem was signieren.
Sagen, dieser Benutzer hat diesen öffentlichen Schlüssel und das
bestätige ich.
Und alle, die mich kennen, wissen und mir vertrauen, die wissen,
dieser Mensch hat bestätigt, dass der andere Benutzer einen Schlüssel
hat.
Dann glaube ich das auch.
Und weiß, dass dieser Benutzer mit der Mail-Adresse diesen Schlüssel
hat.
Und umgekehrt.
Ich kann mit dem auch verschlüsselt kommunizieren und sehe ich
irgendwie bestätigt, dass der Schlüssel wirklich ihm gehört.
Und akzeptiere das als gültiger Schlüssel.
Also dieser andere PGP Web of Trust.
In diesem Fall ist das so eine Art Baum.
So ein gerichteter Baum, wenn man das will.
Wie lange geht die Vorlesung?
Bis 15, oder?
Gibt es Fragen zu diesem Punkt?
Gut.
Dann haben wir hier noch ein Problem, was in diesem Hierarchie zum
Beispiel sehr schlecht wird.
Woher weiß man, dass ein Zertifikat, was ausgestellt war, das besagt
natürlich, wie gesagt, dass der private Schlüssel jemand gehört.
Was passiert, wenn jemand diesen Schlüssel verliert?
Und das Zertifikat war gültig für ein Jahr oder 10 Jahre oder 20 Jahre
oder 50 Jahre.
Also 50 Jahre hat zum Beispiel der rote Schlüssel von Verisign.
Wenn das jemand vor diesem Ablaufdatum irgendwie klaut, sei das ein
interner Mitarbeiter oder extern jemand, wäre ein Skandal.
Aber auch die CA ging kaputt.
Aber in unserem Fall betrachten wir jetzt einfach den
wahrscheinlicheren Fall, wo der Benutzer das Zertifikat verliert.
Den Schlüssel verliert.
Entweder wird geklaut oder verliert er das.
In diesem Fall muss die CA benachrichtigt werden.
Da muss sagen, das Zertifikat wäre zwar noch gültig, zwei Jahre lang,
aber ich muss das jetzt sperren.
Das ist dieser Begriff, dieser Revocation.
Und genau das Problem, was für diese CA ein großes Problem ist, das
irgendwie zu kommunizieren, ob das Zertifikat immer noch gültig ist.
Es war in dem Moment der Ausstellung gültig.
Und jetzt muss man feststellen können, ob das Zertifikat jetzt gültig
ist.
Das heißt, die CA muss irgendwie Gültigkeitsinformationen
bereitstellen.
Und jetzt kommen wir so langsam in dieses Management und in diese
Problematik rein.
Was kann die CA dann machen?
Der übliche Weg, sie kann solche Revocation-Listen veröffentlichen.
Das heißt, in der Datenbank, da wo die Zertifikate auch gespeichert
sind, muss die CA eine Sperrliste, also CRL, Revocation-List,
bereitstellen, das auch eben digital signiert ist von der CA, was ein
jeder im Prinzip bei jeder Zertifikatsprüfung herunterladen müsste und
durchsuchen müsste, z.B.
nach der Seriennummer, was ich erwähnt habe bei den
Zertifikatsfeldern, ob die gegebene Seriennummer in dieser Revocation
-Liste drin ist.
Wenn das der Fall ist, dann wurde das Zertifikat irgendwie, oder das
Schlüssel nur kompromittiert z.B.
und das Zertifikat gesperrt.
Und deswegen müsste man die periodisch herunterladen, damit man sicher
sein kann, dass diese lange, lange Lebensdauer immer noch gültig ist.
Dass wirklich das Zertifikat noch gültig ist.
Und das ist genau, was in den heutigen Browsern z.B.
nicht passiert.
Da gibt es ein Zertifikat, gültig für 10 Jahre, meinetwegen so eine
kleine Ruze ja, und man weiß gar nicht, was da seit 86 oder wann das
ausgestellt war, was da passiert.
Oder 96.
Und das Problem ist da, wenn man zu lange Gültigkeitsperioden wählt,
dass natürlich auch die Schlüssel z.B.
in der Zeit kompromittiert werden können.
Weil die z.B.
zu kurz sind.
Wenn jemand jetzt ein CA aufgestellt hat vor ein paar Jahren mit 512
Bitlänge von RSA, das ist ja unsicher.
Das kann man jetzt ziemlich schnell knacken.
In 5 Tagen ungefähr mit einem gescheiten Rechner.
Und dann hat man das Problem mit dieser CRL.
Aber wenn man das immer wieder prüft und immer wieder ordentlich
veröffentlicht, dann ergibt sich so ein Szenario für unser Fall.
Das könnt ihr dann selber zu Hause studieren.
Im Prinzip ist das nochmal zusammengefasst, dieses hybride Verfahren
mit Zertifikatsprüfung.
Was diese Folie hier besagen will.
Also einmal wird die Verbindung aufgebaut, dann die Zertifikate
ausgetauscht, damit man den öffentlichen Schlüssel hat.
Die werden verifiziert und dann geprüft, ob sie noch gültig sind, mit
Hilfe dieser CRL.
Die CRL können verdammt lang werden, wenn viele Benutzer die CA hat.
Und man muss halt durchsuchen, ob die Seriennummer des Zertifikats
drauf ist.
Wenn nicht, dann kann man anfangen mit dem Session Key auszutauschen.
Und so weiter, die ganze Kommunikation abzuwickeln.
Okay, ich bin fertig für heute.
Und das nächste Mal werden wir die interne Struktur und Funktionsweise
und Komponenten und so weiter von einer PKI kennenlernen.
Im Prinzip die technische Realisierung einer CA.
Das war's.
Ich.
Tschüss.