MIT-Kurs "Computer Systems Security". Vorlesung 13: Netzwerkprotokolle, Teil 2

Massachusetts Institute of Technology. Vorlesung # 6.858. "Sicherheit von Computersystemen." Nikolai Zeldovich, James Mickens. 2014 Jahr

Computer Systems Security ist ein Kurs zur Entwicklung und Implementierung sicherer Computersysteme. Die Vorträge behandeln Bedrohungsmodelle, Angriffe, die die Sicherheit gefährden, und Sicherheitstechniken, die auf jüngsten wissenschaftlichen Arbeiten basieren. Zu den Themen gehören Betriebssystemsicherheit, Funktionen, Informationsflussmanagement, Sprachsicherheit, Netzwerkprotokolle, Hardwaresicherheit und Sicherheit von Webanwendungen.

Vorlesung 1: „Einführung: Bedrohungsmodelle“ Teil 1 / Teil 2 / Teil 3
Vorlesung 2: „Kontrolle von Hackerangriffen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 3: „Pufferüberläufe: Exploits und Schutz“ Teil 1 / Teil 2 / Teil 3
Vorlesung 4: „Trennung von Privilegien“ Teil 1 / Teil 2 / Teil 3
Vorlesung 5: „Woher kommen Sicherheitssysteme?“ Teil 1 / Teil 2
Vorlesung 6: „Chancen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 7: „Native Client Sandbox“ Teil 1 / Teil 2 / Teil 3
Vorlesung 8: „Netzwerksicherheitsmodell“ Teil 1 / Teil 2 / Teil 3
Vorlesung 9: „Sicherheit von Webanwendungen“ Teil 1 / Teil 2 / Teil 3
Vorlesung 10: „Symbolische Ausführung“ Teil 1 / Teil 2 / Teil 3
Vorlesung 11: „Ur / Web-Programmiersprache“ Teil 1 / Teil 2 / Teil 3
Vorlesung 12: Netzwerksicherheit Teil 1 / Teil 2 / Teil 3
Vorlesung 13: „Netzwerkprotokolle“ Teil 1 / Teil 2 / Teil 3

Student: Der Client kann dieses Ticket nicht entschlüsseln, da es mit dem Serviceschlüssel verschlüsselt ist.

Professor: Ja, das ist wirklich klug, nicht wahr? Wir haben den Schlüssel Kc, s, den der Client empfangen kann, aber hier auf dem Ticket Tc, s befindet sich eine weitere Kopie dieses Schlüssels, die mit Ks verschlüsselt ist.



Der Grund dafür ist, dass der Kerberos-Server tatsächlich versucht, die Kommunikation des Clients mit dem anderen Mann zu sichern. Daher erstellt Kerberos einen zufälligen Schlüssel Kc, s und gibt eine Kopie an den Client und eine weitere an den Server, mit dem der Client sprechen wird. Stellen Sie sich vor, Kerberos würde den Dienst nur mit den Worten anrufen: "Hey, Dienst, dieser Typ möchte mit Ihnen sprechen, das ist der Schlüssel dafür!" Dies wäre unglücklich, da der Kerberos-Server bei jeder Anforderung immer wieder auf den Dienst zugreifen würde. Daher erstellt KDS zwei Kopien des Sitzungsschlüssels: eine für den Client und eine für TGS.

Daher haben sich die Entwickler stattdessen einen guten Trick ausgedacht, bei dem sie dem Kunden dieses Ticket zur Verfügung stellen, und er kann nichts mit ihm tun, außer ihn mit dem richtigen Service zu kontaktieren. Und wenn dieser Dienst den richtigen Ks-Schlüssel hat, wird er entschlüsselt und sagt: "Ja, dies ist derselbe Schlüssel, den ich verwenden muss, um mit diesem Client zu sprechen." Somit legen beide Teilnehmer an der Verbindung, Client und Service, einen gemeinsamen Schlüssel zum Schutz ihrer Verbindung fest.

Student: Also, was ist TGS?

Professor: Es gibt zwei Ansichten darüber, was TGS ist. Aus Sicht des Kunden ist dies nur ein weiterer Service, für den Sie ein Ticket erhalten können. Je mehr Funktionen dieser Service bietet, desto mehr Tickets bietet er. Dies ist eigentlich ein Ticketservice.

Student: Entschuldigung, ich meinte, wir haben ein Ticket namens TGS.

Professor: Oh ja, sorry, die Inschrift tgs unter dem Pfeil in diesem Diagramm ist nur eine Abkürzung für den gesamten Aufzeichnungsblock, mit Ausnahme der Indizes s im Parameter Tc, s, was bedeutet, dass der tatsächliche Name dieses Dienstes TGS ist. Sie können sich vorstellen, dass wir einen Kerberos-Server haben, es gibt diesen TGS-Dienst und es gibt einen echten Dienst, den Sie erreichen möchten. Zuerst müssen Sie Kerberos bitten, Ihnen ein Ticket zu geben, um Zugang zu einem bestimmten Dienst zu erhalten.



Sie könnten Kerberos bitten, Ihnen ein Ticket direkt an den Dateiserver zu geben, und das könnte funktionieren. Dafür benötigen Sie jedoch Ihren Kc zur Entschlüsselung und für den Rest der Zeit über den Server. Stattdessen erhalten Sie ein Ticket für den speziellen TGS-Service. Es sieht genauso aus wie andere Dienste, nur dass es in einem separaten Feld abgelegt wird. Gerne gibt er Ihnen später weitere Tickets, ohne Ihren ursprünglichen Kc-Kundenschlüssel erneut bereitzustellen.

Student: Das heißt, seine Idee ist, dass Sie Ihren Kc-Schlüssel einfach loswerden können, sobald Sie ein TGS-Ticket erhalten?

Professor: Ja, das Coole daran ist, dass Sie das Passwort und den Schlüssel Kc loswerden, sobald Sie dieses Ticket Tc vom TGS-Dienst erhalten. Sobald Sie sich bei der Athena Workstation anmelden und nach einigen Sekunden ein Ticket T, s erhalten, wird Ihr Passwort aus dem Speicher gelöscht. Selbst wenn jemand Sie packt, den Computer auswählt und mit ihm davonläuft, hat er nur Ihr Ticket. Es ist gut, wenn er 10 Stunden lang oder für die Dauer des Tickets auf Ihre Informationen zugreifen kann, jedoch nicht länger, da das Passwort nicht gespeichert wurde und Sie es beim nächsten Betreten von Athena erneut eingeben müssen.

Sie benötigen nur dann ein Kennwort, wenn Sie eine Anfrage an den Kerberos-Server senden. Sie erhalten diese Antwort mit einem Ticket und entschlüsseln sie. Danach können Sie das Passwort vergessen. Natürlich können Sie das Passwort nicht löschen, bevor Sie es zum Entschlüsseln verwenden.
Somit wird die erste obere Schnittstelle C in unserem Schema verwendet, um ein Ticket mit dem Anfangsschlüssel Kc zu erhalten, und die zweite untere Schnittstelle S wird verwendet, um auf Dienste zuzugreifen, jedoch ohne dass der Anfangsschlüssel Kc erhalten werden muss.



Wir haben also bereits über zwei spezifische Probleme des Kerberos-Protokolls gesprochen, die sozusagen in das Kerberos-Protokoll eingebaut sind und einige Unannehmlichkeiten verursachten. Zunächst gingen die Ersteller davon aus, dass die Verschlüsselung auch Authentifizierung oder Nachrichtenintegrität bieten würde, dies geschah jedoch nicht. Dieser Fehler wurde in Kerberos Version 5 behoben, in der eine explizite Nachrichtenauthentifizierung durchgeführt wird. Zweitens hatten sie für beliebige Kunden die Möglichkeit, die Passwörter anderer Personen zu erraten.

Wie kann das behoben werden? Wie kann man Angriffe verhindern, indem man das Passwort in Protokollen dieser Art errät? Was können wir versuchen?

Student: Ich bin mir nicht sicher, aber Sie können versuchen, das Passwort zu "salzen".

Professor: „Salzen“ bedeutet einfach, dass der Kunde das Passwort möglicherweise auf verschiedene Arten hashen muss. Aber es tut nicht weh, zu versuchen, es aufzuheben. Es könnte also teurer sein, ein Wörterbuch zu erstellen.

Student: Sie können versuchen, die Berechnung des Passworts zu erschweren.

Professor: Ja, eine andere gute Idee ist es, den Hash-Prozess sehr teuer zu machen. Vielleicht ist das vernünftig. Wenn diese Hash-Funktion eine Sekunde Rechenzeit benötigt, wie Sie es im zweiten Labor getan haben, wäre die Auswahl von Passwörtern in diesem Fall eine sehr teure Aufgabe. Dies scheint also ein vernünftiger Plan zu sein - eine Kombination aus „Salzen“ und Komplizieren des Vermutungsprozesses zu verwenden.

Eine andere Verteidigung kann darin bestehen, die Reaktion zu erschweren. Sie haben gehört, dass der Kerberos-Server in den ersten Versionen des Protokolls keine Ahnung hatte, ob der richtige Client darauf zugreift oder nicht. Sie können den Nachweis erbringen, dass Sie der richtige Client sind, dh den aktuellen Zeitstempel mit einem Kennwort-Hash oder ähnlichem verschlüsseln. Dann könnte der Kerberos-Server einfach prüfen, ob diese Dinge korrekt sind, und Ihnen, falls sie übereinstimmen, ein Ticket zur Verfügung stellen.

Sie möchten wahrscheinlich keine weiteren Testschritte hinzufügen, aber das könnte funktionieren. Angenommen, Sie können vorerst einen Zeitstempel nehmen und ihn zusammen mit der Taste Kc hashen und auch nur einen Zeitstempel hinzufügen.



In diesem Fall kann der Server sehen, dass er Ihren Kc-Schlüssel hat, und er kann auch den aktuellen Zeitstempel hashen. Wenn es den gleichen Wert erhält, wird die Anfrage wahrscheinlich von dem richtigen Benutzer gestellt, an den das Ticket gesendet werden kann. Wenn nicht, war es das falsche Passwort.

Student: Sie können die Ausgabe von Tickets einfach einschränken, wenn die Server zu viele Anfragen für deren Bereitstellung aufzeichnen.

Professor: Ganz richtig, wir können eine Einschränkung einführen. Es gibt jedoch keinen Grund für einen Hacker, ein Ticket mehr als einmal auf dem Server anzufordern. Er fragt einfach nach einem bestimmten Benutzer, erhält diesen verschlüsselten Block von ihm und kann versuchen, ihn so oft offline zu entschlüsseln, wie er möchte, mit unterschiedlichen Passwörtern ohne eine zweite Anfrage. Daher denke ich, dass der ganze Schutzpunkt darin besteht, dass der Server irgendwie auf die Anzahl der Anrufe reagiert, wenn der Angreifer den Server wiederholt anfordert und versucht, unter verschiedenen Passwörtern in das System einzutreten. In diesem Fall kann das Abfragelimit erreicht werden, was einen besseren Schutz gegen Hacking bietet.

Student: Wie kann ein Angreifer eine Anfrage an den Kerberos-Server senden?

Professor: Ich denke, er könnte die Nachricht des richtigen Benutzers reproduzieren, dh sehen, kopieren, senden und auch eine Antwort vom Kerberos-Server erhalten. Wenn ein Hacker das Netzwerk scannt, kann er die Nachricht während der Übertragung abfangen. Die Begrenzung der Anzahl der Anforderungen ist daher eine vorübergehende Maßnahme, die die Sicherheit nur geringfügig erhöht. Wenn Sie sich jedoch das Netzwerk eines anderen Benutzers ansehen, werden Sie natürlich sehen, wie dieses Paket vom Server zurückgegeben wird, unabhängig davon, was zum Zeitpunkt der Bildung von Tc, s passiert ist. So kann der Hacker die Antwort des Servers auf den Client sehen und versuchen, ihn anzugreifen.

Es gibt wahrscheinlich komplexere Schemata, die Sie entwickeln könnten, aber ich glaube nicht, dass Kerberos 5 etwas Komplizierteres implementiert als den Plan, den wir überprüft haben. Dies scheint gut genug zu sein, um zu verhindern, dass zufällige Personen versuchen, etwas zu brechen oder Brute zu verwenden. zwingen, ein Passwort zu knacken.

Student: Angenommen, Sie können eine Authentifizierung oder etwas anderes bereitstellen, um einen gemeinsam genutzten Schlüssel einzurichten. Und dann können Sie dieses Ding und den gemeinsamen Schlüssel mit Kc verschlüsseln.

Professor: Ja, das ist es. Wenn Sie es wirklich richtig machen, gibt es dafür ein Protokoll namens PAKE (Password Authenticated Key Exchange), das die Kennwortauthentifizierung durchführt. Genau das passiert in Kerberos.



Sie können bei Google nachsehen, wozu die SRP- oder PAKE-Protokolle dienen. Diese Protokolle und die zugehörigen Elemente eignen sich viel besser für Ihre Aufgabe, bei der Sie beiden Parteien nachweisen müssen, dass Sie einen neuen Schlüssel installiert haben. In diesem Fall müssen beide Parteien davon überzeugt sein, dass sie sich gegenseitig korrekt sind und dass es keine Möglichkeit gibt, dieses Kennwort offline zu erraten und die beobachteten Netzwerkpakete usw. anzugreifen.

Dies sind Protokolle, die stark von Kryptografie abhängen. Daher ist es schwierig, an der Tafel zu erklären, warum sie funktionieren.

Student: Einer der Gründe, warum Entwickler dies taten, war, dass sie die Möglichkeit unterstützen wollten, nur ein Passwort zu senden. Mit den Protokollen können Sie nur eine Sache als Authentifikator senden.

Professor: Ja, es gibt viele seltsame Anforderungen, die diese Leute berücksichtigt haben. In der Praxis können diese Server natürlich sowohl Kerberos- als auch Nicht-Kerberos-Verbindungen akzeptieren. Bei Nicht-Kerberos-Verbindungen wird das Bild angezeigt, als würde jemand eine Verbindung zu einem Mailserver herstellen, jedoch keine Athena-Workstation verwenden. Er möchte nur sein Passwort senden.



Und dann wird der E-Mail-Client hier, sagen wir, dieses Passwort nehmen und in Ihrem Namen ein Ticket erhalten, um es zu überprüfen, damit Sie diesen E-Mail-Client verwenden können. Sie möchten also wahrscheinlich immer noch, dass Kerberos selbst Kerberos-Kennwörter überprüft. Ich denke nicht, dass dies nicht in Frage kommt, da Kerberos 5 natürlich diese Zeitstempel-Hashes und all das bereitstellt.

Ich denke, eine weitere Sache, auf die Sie in den Vorlesungsunterlagen achten sollten, ist, dass die Kerberos 4-Entwickler ein Verschlüsselungsschema gewählt haben - DES, den beliebtesten Verschlüsselungsalgorithmus der Zeit. Dies ist eine symmetrische Blockverschlüsselung, ziemlich schnell. Zu dieser Zeit bot es ausreichende Sicherheit und sie bauten es einfach in das Protokoll ein.

Alles in Kerberos sollte nur DES verwenden, oder zumindest alles in Kerberos Version 4. Dies ist problematisch geworden, da die DES-Verschlüsselung jetzt, 25 bis 30 Jahre später, mit der Brute-Force-Methode leicht geknackt werden kann, da die Verschlüsselungsschlüssel vorhanden sind sehr kleine Größe - nur 56 Bit.

Daher können Sie einfach eine Art Benutzergerät erstellen, das 2 bis 56 Grad Kombinationen berechnet und das tatsächliche Passwort ermittelt. Dies möchten Sie in jedem Protokoll vermeiden, das heutzutage entwickelt wird.

Kerberos Version 5 unterstützt verschiedene Verschlüsselungsschemata, einschließlich AES und anderer kryptografischer Algorithmen. Dies scheint also ein viel besserer Weg zu sein, um die Sicherheit zu gewährleisten. Auf der anderen Seite hat das MIT DES vor 2 Jahren weiterhin unterstützt, hat es aber jetzt abgelehnt, sodass Ihr Rektor heute zumindest vor dieser Art von Angriff geschützt ist. Schauen wir uns nun an, was im TGS-Dienst passiert, von dem Sie ein Ticket erhalten. Die Interaktion mit diesem Service sieht etwas anders aus.

Einerseits werden Sie als Client mit ihm sprechen, als würden Sie mit einem anderen Kerberos-fähigen Dienst sprechen. Überlegen Sie, wie Sie Ihre eigene Authentifizierung mit einem Ticket für einen Computer durchführen. Die Antwort, die Sie zurückgeben werden, ist jedoch nur ein Ticket für ein anderes Prinzip, auf dessen Grundlage Sie beispielsweise mit einem Dateiserver kommunizieren.

Daher sehen die Nachrichten auf Protokollebene folgendermaßen aus - rechts zeichne ich TGS und links den Client. Der Client hat bereits ein Ticket für TGS, das mit dem oben gezeigten Protokoll erhalten wurde.



Jetzt wird der Client eine Kombination von Nachrichten senden, die beweisen, dass er der richtige Client ist, und diese Nachrichten beziehen sich auf die Ausgabe einer Anfrage nach einem bestimmten Prinzip über TGS.

Der Client sendet also eine solche Nachricht an TGS: S ist der Dienst, mit dem er weiter kommunizieren wird. Es kann sich um einen Mail- oder Dateiserver handeln. Dazu gehört auch das Tc-Client-Ticket, das er für tgs erhalten hat und das mit dem Schlüssel K tgs und verschlüsselt wurde Ein Authentifikator, der mit dem Schlüssel Kc verschlüsselt ist, der dem Client und dem TGS-Dienst gemeinsam ist. So sieht die Nachricht aus, die Sie an TGS senden werden - sie lautet: "Sehen Sie sich diese Nachricht an, machen Sie etwas damit und antworten Sie mit einem Ticket für diesen neuen S-Dienst." Die Antwort hier sieht fast genauso aus wie in der obigen Abbildung, und tatsächlich ist es dieselbe - dies ist ein Ticket zwischen dem Client und diesem neuen Dienst, das mit Ks verschlüsselt wurde. Aber jetzt ist es ein bisschen anders geworden.



Anstelle der Verschlüsselung mit dem Kc-Schlüssel, die der Client seitdem vergessen haben muss, wird jetzt die Verschlüsselung mit dem gemeinsamen Schlüssel Kc, tgs zwischen dem Client und dem TGS-Dienst durchgeführt.

Wie findet der Server heraus, was der Client will und wie authentifiziert der Server den Client? Der TGS-Server kennt seinen eigenen Ktgs-Schlüssel. Daher entschlüsselt er zuerst diese Nachricht Tc, tgs, schaut in das Ticket und findet heraus, was passiert. Warum brauchen wir all diese Felder auf dem Ticket? Warum ist es wichtig, den Servernamen S im Ticket zu haben? Was würde schief gehen, wenn wir kein S hätten?

Student: Wenn dies nicht der Fall ist, können Sie möglicherweise die Berechtigung zur Verwendung eines beliebigen Servers erhalten.

Professor: Ja, das ist es. Im Allgemeinen ist es eine gute Idee, die Netzwerkprotokolle so zu erstellen, dass Sie genau sagen können, was diese Nachricht bedeutet. Wenn Sie S weglassen, können Sie sich darauf verlassen, dass Sie, wenn Sie ein Ticket für das falsche S verwenden, möglicherweise einen anderen Schlüssel Ks haben und dieser keine Entschlüsselung oder ähnliches durchführen kann. Es scheint also eine gute Idee zu sein, den Namen des Dienstes anzugeben, um sicherzustellen, dass der Server, der diese Tickets empfängt, sie entschlüsselt und prüft, ob dies ein Ticket für mich oder für eine andere Person ist.

Student: Was macht der Client mit dem erhaltenen Ktgs-Schlüssel?

Professor: gute Frage! Der Kunde hat keine Ahnung, was es ist. Weil es ein streng geheimer Schlüssel ist. Wenn Sie es wüssten, könnten Sie alle Kerberos knacken. Der Kunde hat also keine Ahnung, was Ktgs ist.

Student: Woher kommen diese Ktgs?

Professor: Der Kerberos-Server selbst generiert für Sie all diese Nachrichten, die bereits Tc, tgs und Ktgs enthalten. Sie erstellen sie nicht selbst, sondern kopieren sie einfach von hier.

Warum ist der Name des Kunden so wichtig? Das ist leicht herauszufinden. Wenn Sie den Namen des Kunden nicht in das Ticket eintragen, erhält der Server diese Nachricht, hat jedoch keine Ahnung, mit wem er zu sprechen versucht. Er weiß nicht, für wen er ein Ticket ausstellen soll - für Sie oder für jemand anderen.

Was ist mit den anderen Feldern? Warum fügen Entwickler die Adr-Adresse in das Ticket des Tc ein? Es ist nur die IP-Adresse des Kunden. Warum also nicht direkt verwenden?



Ich denke, dass die Bedeutung dieser Lösung der Wunsch der Entwickler ist, die Sicherheit zu erhöhen. Sie wollten sicherstellen, dass, wenn sich der Client von einer IP-Adresse aus anmeldet, alles andere auf demselben Ticket von derselben IP-Adresse stammt. Wenn Sie beispielsweise von einer IP-Adresse aus angemeldet sind, z. B. 18.26.4.9, sollte jede Verbindung zu einer Datei oder einem Mailserver von derselben IP-Adresse stammen. Andernfalls sollte der Server Ihre Verbindung ablehnen, da dies darauf hindeuten könnte, dass jemand Ihr Ticket gestohlen hat. So schützen wir uns hier vor der Verwendung gestohlener Tickets. Wenn Sie immer noch das gleiche Ticket haben - in Ordnung, aber wenn Sie nicht die gleiche IP-Adresse verwenden, werden Sie keinen Erfolg haben.

Dies scheint derzeit ein Missverständnis zu sein, und Kerberos 5 verwendet immer noch einen ähnlichen Ansatz, obwohl dies nicht erforderlich ist. In der Tat sollten Sie sich einfach auf Kryptografie verlassen, anstatt die IP-Adresse zu sichern.

Aber was bedeuten der Zeitstempel und der Lebenszeitstempel im Ticket? Wofür sind sie und wofür sind sie nützlich?

Student: Sie werden benötigt, um Wiederholungsangriffe zu verhindern.
Professor: Wiederholungsangriffe verhindern den Authentifikator, da dieses Element jedes Mal generiert wird, wenn Sie eine neue Anfrage stellen. Auf der anderen Seite bleibt das Ticket das gleiche, so dass dies natürlich die Wiederholungsangriffe nicht beeinträchtigt.

Student: Dies verhindert, dass jemand Ihr Ticket stiehlt und es dann für seine eigenen Zwecke verwendet.
Professor: Ja, dies begrenzt einfach die Zeit, in der das Ticket gültig ist, so dass der Schaden durch den Diebstahl verringert wird. Der Zeitstempel ist die Zeit, zu der Sie das Ticket erhalten haben, und die Lebensdauer zeigt an, wie viele Stunden dieses Ticket ab dem ersten Zeitstempel gültig ist. Wenn Sie versuchen, es zu früh oder zu spät zu verwenden, sollte jeder Server ein solches Ticket mithilfe des Kerberos-Protokolls ablehnen. Dies bedeutet, dass jeder Server seine Uhr synchronisieren muss.

Student: Sie haben vorhin gesagt, dass ein Client seinen Anfangsschlüssel wegwerfen und Kc verwerfen kann, aber die von TGS erhaltenen Kc speichern muss.

Professor: Ja, der Kunde lässt Kc nach dem Einloggen fallen, muss aber Kc, s behalten.

Student: Wenn also jemand Kc, s stiehlt, hat er Zugang ...

Professor: Ja, schauen wir uns an, wie schlimm das ist. Warum ist es für einen Hacker besser, dieses Kc, tgs, zu enthüllen als Kc?

Student: Wenn Sie Kc, s erhalten, können Sie einfach eine Sitzung zwischen diesen beiden Gesprächspartnern stehlen. Wenn Sie jedoch Kc stehlen, können Sie sich als Client ausgeben.



Professor: . , Kc,s — , , . , Tc,tgs, . , 56 Kc,s. . , Tc,tgs , Kc,s , - .

: , - — Tc,tgs, Kc,tgs, Kc,tgs, Kc — .

: , - , , , , 10 . Kc , .

, , , IP-, . - , , Kc,tgs, TGS. — , , , .

, , , . , , . TGS , , PO12, TGS PO12. , , Kc,s . , , . Kc,s.



, , Tc,mail, Kmail, , , , 5 – DELETE 5, Kc,mail.



, mail? Kmail, - , , Kc,s, Kerberos 5. : «, C , ».

: Kerberos Tc,tgs Kc,s. ?

: Ac . , Kc,s, , . , .



, Kerberos 4 , , , , , , , .

, , , , . , . , , . , , , , . , .
. Kerberos, , , Kerberos 4. , - .

, , , , , Kerberos 4, , , K,mail. , .



, , . , , . - : «, , DELETE 5, - ».

, Kerberos 5 -, . , , , , , .

: K,mail?

: .



, TGS , , S – mail, S Tc,s – mail, S Kc,s — mail. Kc,s K,mail. , .

: K,mail?

: , ? , , . K,mail ?

: ?

: , , ! Kmail, T,mail, , . , , .

, . . Kerberos , , 30 .
Daher ist es unvermeidlich, dass wir Probleme haben, die Sie lösen müssen. Ein interessantes Kerberos 4-Problem betrifft daher die Methode zum Verschlüsseln und Authentifizieren von Nachrichten für Anwendungen. Es besteht darin, dass hier derselbe Schlüssel zum Verschlüsseln von Nachrichten vom Client zum Server und für Antwortnachrichten vom Server zum Client verwendet wird.

54:00 Min.

MIT-Kurs "Computer Systems Security". Vorlesung 13: Netzwerkprotokolle, Teil 3


Die Vollversion des Kurses finden Sie hier .

Vielen Dank für Ihren Aufenthalt bei uns. Gefällt dir unser Artikel? Möchten Sie weitere interessante Materialien sehen? Unterstützen Sie uns, indem Sie eine Bestellung aufgeben oder Ihren Freunden empfehlen, einen Rabatt von 30% für Habr-Benutzer auf ein einzigartiges Analogon von Einstiegsservern, das wir für Sie erfunden haben: Die ganze Wahrheit über VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s von $ 20 oder wie teilt man den Server? (Optionen sind mit RAID1 und RAID10, bis zu 24 Kernen und bis zu 40 GB DDR4 verfügbar).

VPS (KVM) E5-2650 v4 (6 Kerne) 10 GB DDR4 240 GB SSD 1 Gbit / s bis Dezember kostenlos, wenn Sie für einen Zeitraum von sechs Monaten bezahlen, können Sie hier bestellen.

Dell R730xd 2 mal günstiger? Nur wir haben 2 x Intel Dodeca-Core Xeon E5-2650v4 128 GB DDR4 6 x 480 GB SSD 1 Gbit / s 100 TV von 249 US-Dollar in den Niederlanden und den USA! Lesen Sie mehr über den Aufbau eines Infrastrukturgebäudes. Klasse mit Dell R730xd E5-2650 v4 Servern für 9.000 Euro für einen Cent?