Codeanalyse der 'ChannelManager'-Klasse (CNG-Beispiel)
Aktualisiert: Juli 2008
Im CNG (Cryptography Next Generation)-Beispiel für sichere Kommunikation stellt die ChannelManager-Klasse die Infrastruktur für die prozessübergreifende Kommunikation (Interprocess Communication, IPC) des Beispiels bereit.
Die Klasse ist für Folgendes verantwortlich:
Das Erstellen, Öffnen, Schließen und Freigeben von Named Pipes.
Das Senden und Empfangen von Anwendungssteuerungsflags, Channelnamen, digitalen Signaturen, kryptografischen Schlüsseln und Meldungen.
Unter Beispiel für sichere Cryptography Next Generation (CNG)-Kommunikation finden Sie eine Übersicht über das Beispiel und Beschreibungen der in diesem Thema erwähnten Versionen.
Dateiinhalt von 'ChannelManager.cs'
Die Datei ChannelManager.cs enthält folgende Klassen und Methoden:
Die ChannelManager-Klasse:
Konstruktor: Erstellt eine Named Pipe und wartet dann auf eine Verbindung am anderen Ende der Pipe. Wenn es sich bei der Named Pipe um einen Pipeserver handelt, wird mit einem Aufruf der WaitForConnection-Methode auf eine Clientverbindung gewartet. Wenn es sich bei der Named Pipe um einen Pipeclient handelt, wird mit einem Aufruf der Connect-Methode auf einen Server für Named Pipes gewartet. Die Ausführung des ChannelManager-Konstruktors wird nicht beendet, bis eine Verbindung hergestellt ist.
Dispose-Methode: Implementiert die System.IDisposable-Schnittstelle, indem die instanziierten Ressourcen (Stream m_Stream) freigegeben werden, wenn die Klasse den Bereich verlässt.
ReadMessage-Methode: Empfängt Meldungen von Pipeclients.
SendMessage-Methode: Sendet Meldungen an Pipeclients.
AppControl-Methode: Von Alice verwendet, um Anwendungssteuerungsflags an Bob und Mallory zu senden. Mit diesen Flags werden die Zustände Version,fMallory und fVerbose zwischen den drei Befehlsfenstern synchronisiert. AppControl übernimmt keine Aufgaben bei der Verschlüsselung oder der Nachrichtenübertragung. Es handelt sich allein um einen Steuermechanismus zwischen den Anwendungen. Mit dieser Methode wird ein temporäres ChannelManager-Objekt erstellt, das nach der Verwendung verworfen wird.
SendChannelName-Methode: Hilfsmethode zum Senden eines neuen Channelnamens an einen Client. Mit dieser Methode wird ein temporäres ChannelManager-Objekt erstellt, das nach der Verwendung verworfen wird.
ReceiveChannelName-Methode: Hilfsmethode zum Empfangen eines neuen Channelnamens von einem Server. Mit dieser Methode wird ein temporäres ChannelManager-Objekt erstellt, das nach der Verwendung verworfen wird.
Details der 'ChannelManager'-Klasse
Die Anwendungen Alice, Bob und Mallory werden mit von ChannelManager-Instanzen erstellten Named Pipes verbunden. Jede Anwendung erstellt und verwirft zwei Typen von ChannelManager-Objekten:
Objekte mit langer Lebensdauer: Alice und Bob erstellen zu Beginn ihrer Run-Methoden ein ChannelManager-Objekt mit langer Lebensdauer. Sie verwenden dieses Objekt zum Senden von Vertriebskontakten. Mallory erstellt zwei ChannelManager-Objekte mit langer Lebensdauer in seiner Run-Methode: eines zur Kommunikation mit Alice und eines zur Kommunikation mit Bob. Die Channels werden zum Austauschen von kryptografischen Schlüsseln und verschlüsselten Nachrichten verwendet. Sie bleiben bis zum Ende der Run-Methode erhalten und werden dann verworfen.
Temporäre Objekte: Die Methoden AppControl, SendChannelName und ReceiveChannelName erstellen temporäre ChannelManager-Objekte zum Ausführen bestimmter Aufgaben. Die Objekte werden dann verworfen. In den Versionen 4 und 5 sendet Alice außerdem mithilfe eines temporären ChannelManager-Objekts einen privaten digitalen Signaturschlüssel an Bob.
Die ChannelManager-Klasse implementiert die System.IDisposable-Schnittstelle und verwaltet sowohl den send-Übertragungsmodus als auch den receive-Übertragungsmodus.
Die Klasse stellt scheinbar einen dynamischen Austausch zwischen Alice, Bob und Mallory bereit. Tatsächlich kann sich eine Pipe zu einem Zeitpunkt nur in einem Modus befinden: Sie kann ein Server oder ein Client sein. Deshalb werden die Anwendungen Alice, Bob und Mallory auf eine sorgfältige, lineare Weise ausgeführt. Jede Anwendung erwartet zu bestimmten Zeitpunkten während der Ausführung des Beispiels das Öffnen und Schließen von Pipes. Die Kommunikation ist nur scheinbar asynchron.
Es hat den Anschein, dass ein Thread-Manager im Hintergrund Threads verwaltet. Es werden jedoch keine Threadingaufrufe verwendet. Die zeitliche Abstimmung zwischen den Prozessen wird allein durch sorgfältiges Verschränken von send-Aufrufen und receive-Aufrufen zwischen Alice, Bob und Mallory erreicht. Im Ergebnis kommunizieren die drei Fenster dem in der Übersicht über das CNG-Beispiel diskutierten Szenario folgend problemlos miteinander.
Ein Vorteil dieser Implementierung ist die Synchronisierung, und der Code ist einfach und linear. Ein Nachteil ist mangelnde Robustheit: Wenn die Verbindung eines Pipeclients mit dem Server fehlschlägt, antwortet der Server nicht mehr. Eine bessere Methode ist die Verwendung eines Multithreadpipeservers, der solche Fehler problemlos behandelt. Um Komplexität zu vermeiden, wird diese Methode im Beispiel jedoch nicht verwendet.
Die ChannelManager-Klasse wird von den Main-Methoden von Alice, Bob und Mallory sowie dem Communicator-Klassenkonstruktor in der Datei Communicator.cs instanziiert.
Verwendungsdetails
Die ChannelManager-Klasse wird in fünf unterschiedlichen Zusammenhängen verwendet: Anwendungssteuerung, Übertragung von Channelnamen, Nachrichtenübertragung, Übertragung von digitalen Signaturschlüsseln und Übertragung von öffentlichen Verschlüsselungsschlüsseln. In der folgenden Liste werden diese in der Reihenfolge diskutiert, in der sie im Quellcode verwendet werden.
Anwendungssteuerung: Alice ruft die InitializeOptions-Methode zu Beginn ihrer Main-Methode auf und erhält Sitzungsoptionen vom Benutzer. Diese Optionen (Version,fMallory und fVerbose)) werden dann von der AppControl-Methode an Bob und Mallory gesendet. Wenn der Benutzer die Anwendung schließen möchte und den Buchstaben "x" eingibt, sendet die AppControl-Methode anstelle der Sitzungsoptionen die Zeichenfolge "exit" an Bob und Mallory.
Alices AppControl-Methode erstellt die beiden temporären ChannelManager-Pipeserver BobControlChannel und MalloryControlChannel.
Die AppControl-Methoden von Bob und Mallory erstellen temporäre ChannelManager-Pipeclients und stellen eine Verbindung mit ihren jeweiligen Steuerungschannels her.
Bob und Mallory empfangen die Sitzungsoptionen von Alice und verwerfen die temporären ChannelManager-Objekte.
Übertragung von Channelnamen: Nachdem die Sitzungsoptionen übertragen wurden, sendet Alice Bob einen neuen Channelnamen.
Alice verwendet die SendChannelName-Methode, und Bob und Mallory verwenden die ReceiveChannelName-Methode. Jede Methode erstellt einen temporären ChannelManager-Pipeserver oder -Pipeclient. Nachdem der neue Channelname gesendet oder empfangen wurde, wird die temporäre ChannelManager-Instanz verworfen.
Die Sicherheitslücke wird bedeutsam, wenn Mallory den neuen Channelnamen abfängt, indem er ReceiveChannelName 200 Millisekunden vor Bob aufruft. Eine Erörterung dieser Sicherheitslücke finden Sie unter Implementieren eines "Man-in-the-Middle"-Angriffs (CNG-Beispiel).
Nachrichtenübertragung: Nachdem die Sitzungsoptionen und ein neuer Channelname übertragen wurden, erstellen Alice, Bob und Mallory Communicator-Objekte. Die Communicator-Konstruktoren erhalten den im vorhergehenden Schritt gesendeten Namen des neuen Channels und erstellen damit ChannelManager-Instanzen mit langer Lebensdauer. Diese Objekte sind die einzigen nicht temporären ChannelManager-Instanzen. Sie bleiben erhalten, bis die letzte Nachricht gesendet und empfangen wird, und werden dann verworfen.
.gif "Hinweis")
Hinweis:Das von Alice erstellte ChannelManager-Objekt kapselt einen Pipeserver mit dem Namen AliceAndBobChannel. Mallory fängt diesen Namen jedoch ab und sendet einen anderen Channelnamen (AliceAndBobChannel1) an Bob. Bob übergibt diese Zeichenfolge als name-Parameter an seinen Communicator-Konstruktor und erstellt so einen Pipeclient mit dem Namen AliceAndBobChannel1. Diese Namensänderung ermöglicht Mallory, in seinen Nachrichten an Bob die Identität von Alice anzunehmen.
Übertragung von digitalen Signaturschlüsseln: Nachdem Alice ihr Communicator-Objekt erstellt hat, wird der Version-Kennzeichner untersucht. In Version 3 sendet sie Bob einen digitalen Signaturschlüssel über die Named Pipe PublicChannel. Dabei wird dieser von Mallory abgefangen. In den Versionen 4 und 5 erstellt sie eine temporäre, geheime ChannelManager-Instanz. Mit dieser Instanz wird dann ein privater digitaler Signaturschlüssel an Bob gesendet.
Hinweis:Mallory hat keine Kenntnis von dieser privaten Named Pipe, da er nicht über Version 4 oder 5 der Instant Messaging (IM)-Software verfügt. Alice verwendet das in Schritt 3 erstellte ChannelManager-Messagingobjekt mit langer Lebensdauer weiter, um eine gefälschte digitale Signatur an Bob zu senden. In den Versionen 4 und 5 wurde Bobs IM-Tool so aktualisiert, dass dieses Objekt ignoriert wird. Mallory geht jedoch davon aus, dass die Signatur gültig ist, und verwendet sie zum Signieren seiner kryptografischen Schlüssel und seiner Nachrichten. Damit scheitert sein Angriff.
Übertragung von öffentlichen Verschlüsselungsschlüsseln: Das Version-Kennzeichen wird erneut untersucht. In Version 2 und später wird das in Schritt 3 erstellte ChannelManager-Messagingobjekt mit langer Lebensdauer zum Senden und Empfangen öffentlicher Verschlüsselungsschlüssel verwendet.
Nachdem Channelnamen, digitale Signaturen und kryptografische Schlüssel ausgetauscht wurden, verwenden Alice und Bob den in Schritt 3 erstellten ChannelManager zum Übertragen von Nachrichten.
Siehe auch
Konzepte
Beispiel für sichere Cryptography Next Generation (CNG)-Kommunikation
ChannelManager.cs-Quellcode (CNG-Beispiel)
Quellcodeübersicht (CNG-Beispiel)
Referenz
Änderungsprotokoll
Date |
Versionsgeschichte |
Grund |
|---|---|---|
|
Juli 2008 |
Thema hinzugefügt. |
Informationsergänzung. |