XADM: Wie Secure Sockets Layer Works

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 245152 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

In diesem Artikel Überblick Funktionsweise von SSL (Secure Sockets Layer).

Weitere Informationen

Eine Einführung in Key Cryptography

Kryptografie (Rivest-Shamir-ADLEMAN) mit öffentlichen Schlüsseln wird häufig für Authentifizierung und Verschlüsselung in der Computerindustrie verwendet. Netscape hat RSA Kryptografie des öffentlichen Schlüssels von RSA Data Security Inc. zur Verwendung in seiner Produkte für die Authentifizierung lizenziert.

Verschlüsselung mit öffentlichen Schlüsseln ist eine Technik, die ein paar asymmetrischen Schlüssel für Verschlüsselung und Entschlüsselung verwendet wird. Jedes Paar von Schlüsseln besteht aus einem öffentlichen Schlüssel und einen privaten Schlüssel. Erfolgt der öffentliche Schlüssel öffentlich ist weit verteilt. Der private Schlüssel wird niemals verteilt; immer geheim gehalten.

Daten, die mit dem öffentlichen Schlüssel verschlüsselt ist, können nur mit dem privaten Schlüssel entschlüsselt werden. Umgekehrt können Daten, die mit dem privaten Schlüssel verschlüsselt sind nur mit dem öffentlichen Schlüssel entschlüsselt werden. Diese Asymmetrie ist die Eigenschaft, die Kryptografie mit öffentlichen Schlüsseln so nützlich.

Kryptografie mit öffentlichen Schlüsseln verwenden für die Authentifizierung

Authentifizierung ist der Prozess der Überprüfung Identität, so dass eine Entität der Identität einer anderen Entität sicher sein kann. In den folgenden Beispielen verwenden Benutzer A und Benutzer B, Kryptografie mit öffentlichen Schlüsseln um den Identität zu überprüfen. Die folgende Notation gibt an, dass ein Element wurde verschlüsselt oder entschlüsselt mit Schlüsseln
{something}key
wo something ist eine Beschreibung des Elements, den verschlüsselten entschlüsselt oder hat und key ist der Schlüssel, der zum Verschlüsseln oder Entschlüsseln dieses Elements verwendet wird.

In der folgenden Beispiel hat möchte zum Authentifizieren von Benutzer b Benutzer B Benutzer A ein Paar Schlüssel, eine öffentliche und eine Private. Benutzer B erläutert den öffentlichen Schlüssel Benutzer A (wird im Abschnitt "Elementverzweigungen ansprechen nicht öffentlicher Schlüssel" in diesem Artikel erläutert). Benutzer A wird eine zufällige Meldung generiert und sendet es an Benutzer B wie folgt:
EINEM-> Brandom_message
Benutzer B den privaten Schlüssel verwendet, um die zufällige Nachricht zu verschlüsseln und Benutzer A: die verschlüsselte Version wieder
B-> A {random_message}User_B's_private_key
Benutzer A empfängt diese Meldung und mit dem öffentlichen Schlüssel, den zuvor veröffentlicht von Benutzer B entschlüsselt. Benutzer A vergleicht die entschlüsselte Nachricht mit der Nachricht, die Benutzer ein, die ursprünglich an Benutzer B; gesendet, wenn die Nachrichten entsprechen, Benutzer A kennt, die höhere Nachricht von Benutzer B stammt, da ein falschen vermutlich nicht den privaten Schlüssel und so wissen würde konnte nicht ordnungsgemäß Verschlüsseln der zufällige Nachricht an von Benutzer a wäre

Weitere Überlegungen

Wenn Sie genau welche Sie verschlüsseln wissen, empfiehlt es nie eine um etwa mit Ihrem privaten Schlüssel verschlüsseln und dann an eine andere Person senden. Ist Sie verantwortlich für den verschlüsselten Wert gehalten werden können (Beachten Sie, dass nur Sie die Verschlüsselung durchführen können, da nur den privaten Schlüssel müssen).

Aus diesem Grund in diesem Beispiel statt der ursprünglichen Nachricht, dass Benutzer A gesendet, Verschlüsseln wird Benutzer B erstellt einen Nachrichtenhash und verschlüsselt das Message Digest. Ein Message Digest ist von der ursprünglichen Nachricht nach dem Zufallsprinzip abgeleitet und hat die folgenden nützlichen Eigenschaften:
  • Der Digest ist schwierig zu stornieren. Person versucht, die Identität von Benutzer B kann die ursprüngliche Nachricht aus der Digest nicht ermitteln.
  • Eine Identität hat Schwierigkeiten beim Suchen nach eine andere Nachricht, die auf den gleichen Digest-Wert berechnet.
Benutzer B ist einen Digest mit geschützt. Benutzer B berechnet dem Hash der zufälligen Nachricht, dass Benutzer A gesendet und verschlüsselt dann das Ergebnis. Benutzer B sendet, die der verschlüsselte Hash, Benutzer a Benutzer A kann zurück berechnen den gleichen Digest und Authentifizieren von Benutzer B durch Entschlüsselung den Nachricht und die Werte vergleichen.

Ursprünglicher Daten für die Authentifizierung

Die im Abschnitt "Weitere Erwägungen" dieses Artikels beschriebenen Technik wird als digitale Signatur bezeichnet. Dieses Verfahren erfordert, dass Benutzer B Signieren einer Nachricht, dass Benutzer A generiert; Dies ist fast wie gefährlich für Benutzer B als einen zufälligen Wert, der mit Benutzer a verschlüsseln Folglich dieses Beispiel-Authentifizierungsprotokoll benötigt eine weitere Schritt gesichert werden; Benutzer B muss einige (oder alle) der Daten wie folgt stammen:
EIN-> B B-> eine Hello, können Sie Benutzer B? Benutzer A, dies wird Benutzer B {digest[Benutzer A, ist dieser Benutzer B]} User_B's_private_key
Wenn Benutzer B dieses Protokoll verwendet, Benutzer B weiß, welche Nachrichten an Benutzer A gesendet wird und Benutzer B können so bedenkenlos Signieren der Nachricht. Benutzer B sendet die unverschlüsselte Version der Nachricht zunächst "Benutzer A, dies wird Benutzer B," und Benutzer B sendet dann die digested-verschlüsselte Version. Benutzer A kann leicht überprüfen, ob Benutzer B Benutzer B wird und Benutzer B muss nicht alles signieren, die nicht mit Benutzer b stammen

Öffentliche Schlüssel übergeben

Wie kann ein Benutzer auf sichere Weise einen öffentlichen Schlüssel ausgeben? Im folgenden ist ein Beispiel-Authentifizierungsprotokoll für Benutzer B:
EINEM->-> EIN EINEM->-> A B B
Hallo hoch, bin ich Benutzer B User_B's_public_key Beweisen Sie Benutzer A, dieser ist
Benutzer B {digest [Benutzer A, dieser wird Benutzer B]} User_B's_private_key
Wenn dieses Protokoll verwendet wird, kann jeder Benutzer b imitieren. Einen falschen ist muss ein öffentlicher und privater Schlüssel. Einen falschen kann Benutzer A liegen und Identität von Benutzer B durch den des falschen öffentlichen Schlüssel anstelle der den öffentlichen Schlüssel bereitstellen. Dann beweist"die falschen" ist die falschen Benutzer B durch etwas mit der falschen privaten Schlüssel zu verschlüsseln, und Benutzer A kann nicht sagen, dass die falschen nicht Benutzer b ist

Um dieses Problem zu beheben, hat die Standards Community ein Objekt als Zertifikat bezeichnet erfunden. Ein Zertifikat enthält die folgende Informationen:
  • Der Name des den Aussteller des Zertifikats.
  • Die Entität, für die das Zertifikat (auch bekannt als des Antragstellers) ausgestellt wird.
  • Der öffentliche Schlüssel des Antragstellers.
  • Einige Zeitstempel.
Das Zertifikat ist signiert, mithilfe des privaten Schlüssels des Zertifikatausstellers. Jeder kennt den öffentlichen Schlüssel für den Aussteller des Zertifikats (d. h., der Aussteller des Zertifikats auch hat ein Zertifikat). Zertifikate stellen eine Standardmethode zum Binden eines öffentlichen Schlüssels an einen Namen.

Wenn Zertifikat Technologie verwendet wird, kann jeder untersuchen den Zertifikat angezeigt, wenn das Zertifikat gefälscht wurde hat. Wenn Benutzer B enge Steuerelement des privaten Schlüssels behält, und Benutzer B tatsächlich das Zertifikat erhält, wird die Zertifikat-Technologie sicher. Dies ist das ergänzende Protokoll mit diesem Verfahren:
EIN-> B B-> A A-> B B-> eine Hello hoch, bin ich Benutzer BUser_B's_certificate nachweisen
Diese Benutzer A, dieser wird Benutzer B {digest [Benutzer A, dieser wird Benutzer B]} User_B's_private_key
Wenn Benutzer A empfängt den ersten Nachricht, Benutzer A kann untersuchen Sie das Zertifikat, überprüfen Sie die Signatur (wie im vorherigen Beispiel, mit einer Digest und einem öffentlichen Schlüssel entschlüsseln), und dann überprüfen Sie den Betreff (d. h. den Namen) und sehen, dass es tatsächlich Benutzer b Benutzer A kann dann vertrauen, dass der öffentliche Schlüssel, den öffentlichen Schlüssel ist und den Identitätsnachweis anfordern können.

Benutzer B durchläuft das gleiche Verfahren wie in dem vorherigen Beispiel beschrieben, indem Sie einen Message Digest entwerfen und reagieren auf Benutzer A mit eine signierte Version des Digest. Benutzer A kann überprüfen, den Message Digest, indem Sie mithilfe des öffentlichen Schlüssels aus dem Zertifikat und das Ergebnis.

Eine Person, die sichere Kommunikation (in diesem Beispiel Benutzer C) beeinträchtigen möchten möglicherweise können Sie das folgende Szenario dazu versuchen erstellen:
EIN-> C C-> A A-> C C-> eine Hello hoch, bin ich Benutzer BUser_B's_certificate nachweisen
Es????
Allerdings kann keine Benutzer C Benutzer A in der letzten Nachricht erfüllen. Benutzer C verfügt nicht den privaten Schlüssel, damit Benutzer C kann keine Nachricht erstellen, die Benutzer A glauben wird Benutzer b stammt

Ein Schlüssel austauschen

Nach Benutzer A Benutzer B authentifiziert hat, kann Benutzer A Benutzer B eine Nachricht senden, die nur Benutzer B wie folgt decodiert werden können
EINEM-> B {secret}User_B's_public_key
Die einzige Möglichkeit der secret zu ermitteln, besteht, durch die obige Nachricht mit den privaten Schlüssel entschlüsseln. Austausch eines geheimen Schlüssels ist eine weitere leistungsstarke Möglichkeit Kryptografie mit öffentlichen Schlüsseln zu verwenden. Selbst wenn die Kommunikation zwischen Benutzer A und Benutzer B beobachtet wird, kann niemand jedoch Benutzer B die geheime Informationen ermitteln.

In diesem Fall ist eine Taste zu einem symmetrischen kryptografischen Algorithmus wie z. B. DES (Data Encryption Standard), RC4 oder IDEA, aber diese Technik erhöht die Sicherheit im Internet mithilfe des geheimen Schlüssels als eine andere Taste. Benutzer A kennt den geheimen Schlüssel, da Benutzer A den geheimen Schlüssel, generiert bevor Sie den geheimen Schlüssel an Benutzer b Benutzer B senden bekannt werden, da Benutzer B den privaten Schlüssel und können Benutzer die Nachricht entschlüsseln. Da Benutzer A und Benutzer B den geheimen Schlüssel kennen, können sowohl einen symmetrischen Verschlüsselung Algorithmus starten und senden Sie Nachrichten, die mit dem Algorithmus symmetrischen Verschlüsselung verschlüsselt sind. Ist ein überarbeitetes Protokoll, das diese Technik verwendet:
EIN-> B B-> A A-> B B-> A A-> B B-> eine Hello hoch, bin ich Benutzer BUser_B's_certificate
Beweisen Sie Benutzer A, dieser wird Benutzer B {digest [Benutzer A, dieser wird Benutzer B]} User_B's_private_key
OK Benutzer B hier ist ein geheimer Schlüssel {secret} User_B's_public_key {some_message} secret_key
Die Methode, mit der compute-secret_key einrichten für das Protokoll ist, die definiert wird, sondern secret_key kann einfach eine Kopie der geheime Schlüssel sein.

Sicherheit Störungen

Selbst wenn alle der vorstehend beschriebenen Verfahren verwendet werden, kann dazu eine Person, die sichere Kommunikation (Benutzer C) beeinträchtigen möchte möglicherweise. Obwohl Benutzer C den geheimen Schlüssel entdecken nicht möglich, die Benutzer A und Benutzer B ausgetauscht haben, können Benutzer C mit Ihrer Unterhaltung durch re-arranging beeinträchtigen (oder garbling) der geheimen Informationen. Beispielsweise wenn Benutzer C zwischen Benutzer A und Benutzer B sitzen, können Benutzer C die meisten Informationen hin-und unverändert übergeben, jedoch bestimmte Nachrichten (Dies ist für Benutzer C ausführen, da Benutzer C das Protokoll, dass Benutzer A weiß und Benutzer B zur Kommunikation mit leicht) garble:
EINEM-> C C-> B-> C C-> EIN EINEM-> C C-> B-> C C-> EIN EINEM-> C C-> B-> C C-> A
Hallo Hallo hoch, bin ich Benutzer B User_B's_certificate Hi, bin ich Benutzer B
User_B's_certificateBeweisen Sie Benutzer A, das Benutzer B {digest [Benutzer A ist nachweisen
Diese wird Benutzer B]} User_B's_private_key Benutzer A, dieser wird Benutzer B {digest [Benutzer A, dieser ist
Benutzer B]} User_B's_private_key ok von Benutzer B, hier ist ein geheimer Schlüssel {secret} User_B's_public_key
OK Benutzer B hier ist ein geheimer Schlüssel {secret} User_B's_public_key {some_message} secret_key
Garble [{some_message} secret_key]
Benutzer C übergibt die Daten unverändert, bis der Benutzer A und Benutzer B einen geheimen Schlüssel gemeinsam verwenden. Benutzer C dann garbles den Nachricht an Benutzer a Benutzer A Benutzer B vertraut, also Benutzer A können zu diesem Zeitpunkt Ihrer Meinung nach die unlesbare Nachricht und versuchen, auf diese reagieren. Beachten Sie, dass Benutzer C nicht, den geheimen Schlüssel weiß; alle Benutzer C möglich ist Beschädigung der Daten, die mit dem geheimen Schlüssel verschlüsselt sind. Abhängig vom Protokoll Benutzer C erzeugt eine gültige Nachricht möglicherweise, aber Benutzer C Glück und eine gültige Nachricht erzeugen kann.

Um diese Art der Beschädigung zu verhindern, können Benutzer A und Benutzer B einen Nachrichtenauthentifizierungscode in Ihrem Protokoll einführen. Ein Nachrichtenauthentifizierungscode ist eine Softwarekomponente von Daten, die mithilfe einer geheimen und einige übertragenen Daten berechnet wird. Der oben beschriebene Digest-Algorithmus hat nur die rechten Eigenschaften für das Erstellen einer Nachricht Authentifizierung Codefunktion, die Abwehr von Benutzer c können
message_authentication_code: = digest [some_message, secret]
Da Benutzer C den geheime Schlüssel nicht bekannt ist, können Benutzer C nicht den richtigen Wert für den Digest berechnen. Selbst wenn Benutzer C nach dem Zufallsprinzip Nachrichten garbles, ist die Erfolgschance klein, wenn große Datenmengen einer Digest. Zum Beispiel mithilfe von MD5 (eine gute kryptografische Digestalgorithmus durch RSA erfunden), können Benutzer A und Benutzer B 128-Bit-Meldung Authentifizierung Codewerte mit Nachrichten senden. Die Wahrscheinlichkeit von Benutzer C den richtige Message Authentication Code zu erraten sind ungefähr 1 in 18,446,744,073,709,551,616. Benutzer C kann nicht den richtige Message Authentication Code erraten, praktischen Gründen.

Im folgenden ist das Beispiel-Protokoll, erneut überarbeitet, um dieses Verfahren verwenden:
EIN-> B B-> A A-> B B-> eine Hello hoch, bin ich Benutzer BUser_B's_certificate nachweisen
Diese Benutzer A, dieser wird Benutzer B {digest [Benutzer A, dieser wird Benutzer B]} User_B's_private_key ok
Benutzer B, hier ist ein geheimer Schlüssel {secret} User_B's_public_key {some_message, message_authentication_code} secret_key
Benutzer C kann versuchen, Nachrichten garble, aber die Nachricht Authentifizierung Code Berechnungen anzuzeigen, die Nachrichten können nicht von Benutzer b Benutzer A geschaltet werden, oder Benutzer B entdecken den Codewert falsche Meldung Authentifizierung und Kommunikation beenden können. Benutzer C kann nicht mehr Benutzer b imitieren.

Eigenschaften

Artikel-ID: 245152 - Geändert am: Samstag, 28. Oktober 2006 - Version: 3.3
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 4.0 Standard Edition
  • Microsoft Exchange Server 5.0 Standard Edition
  • Microsoft Exchange Server 5.5 Standard Edition
Keywords: 
kbmt kbinfo KB245152 KbMtde
Maschinell übersetzter Artikel
Wichtig: Dieser Artikel wurde maschinell und nicht von einem Menschen übersetzt. Die Microsoft Knowledge Base ist sehr umfangreich und ihre Inhalte werden ständig ergänzt beziehungsweise überarbeitet. Um Ihnen dennoch alle Inhalte auf Deutsch anbieten zu können, werden viele Artikel nicht von Menschen, sondern von Übersetzungsprogrammen übersetzt, die kontinuierlich optimiert werden. Doch noch sind maschinell übersetzte Texte in der Regel nicht perfekt, insbesondere hinsichtlich Grammatik und des Einsatzes von Fremdwörtern sowie Fachbegriffen. Microsoft übernimmt keine Gewähr für die sprachliche Qualität oder die technische Richtigkeit der Übersetzungen und ist nicht für Probleme haftbar, die direkt oder indirekt durch Übersetzungsfehler oder die Verwendung der übersetzten Inhalte durch Kunden entstehen könnten.
Den englischen Originalartikel können Sie über folgenden Link abrufen: 245152
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.
Disclaimer zu nicht mehr gepflegten KB-Inhalten
Dieser Artikel wurde für Produkte verfasst, für die Microsoft keinen Support mehr anbietet. Der Artikel wird deshalb in der vorliegenden Form bereitgestellt und nicht mehr weiter aktualisiert.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com