Freigeben über

Quellcodeübersicht (CNG-Beispiel)

  • Artikel

Aktualisiert: Juli 2008

Diese Übersicht bietet eine ausführliche Beschreibung der Interaktionen zwischen den verschiedenen Codeelementen im Cryptography Next Generation (CNG)-Beispiel für sichere Kommunikation.

Die folgenden Aspekte des Beispiels werden erläutert:

  • Anwendungen

  • Files

  • Klassen

  • Sicherheitsversionen

  • Übersicht über die Sitzung

  • Kryptografische Schlüssel (Versionen 2-5)

  • Über einen öffentlichen Channel ausgetauschte digitale Signaturen (Version 3)

  • Über einen privaten Channel ausgetauschte digitale Signaturen (Version 4)

  • Beenden der Sitzung (Version 5)

  • Weitere Hinweise

  • Einschränkungen des CNG-Beispiels

Anwendungen

Das Beispiel besteht aus den drei separaten Konsolenanwendungen Alice, Bob und Mallory. Die Anwendungen sind als separate Visual Studio-Projekte erstellt und bestehen aus einer Hauptdatei und drei gemeinsam verwendeten Dateien. In der folgenden Tabelle werden die Anwendungen mit den entsprechenden Dateien aufgelistet.

Anwendungsname (Projektname)

Files

Alice

  • Alice.cs (Hauptdatei)

  • Utilities.cs

  • ChannelManager.cs

  • Communicator.cs

Bob

  • Bob.cs (Hauptdatei)

  • Utilities.cs

  • ChannelManager.cs

  • Communicator.cs

Mallory

  • Mallory.cs (Hauptdatei)

  • Utilities.cs

  • ChannelManager.cs

  • Communicator.cs

Files

In den Tabellen in den folgenden Abschnitten werden die von den einzelnen Anwendungen verwendeten Klassen und Methoden in der Reihenfolge aufgeführt, in der sie im Quellcode auftreten.

Alice.cs, Bob.cs und Mallory.cs

Name der Klasse, Methode

oder globalen Variable

Operator

CNG_SecureCommunicationExample

Projektweite partielle Klasse.

MyColor

OtherColor

fDisplaySendMessage

Globale Variablen.

Main

Programmeinstiegspunkt der einzelnen Anwendungen. Diese Methode behandelt Folgendes:

  • Lädt, wenn von Alice aufgerufen, automatisch Bob.exe und Mallory.exe.

  • Erstellt eine Verarbeitungsschleife.

  • Ruft die InitConsole-Methode auf, um Größe, Position und Titel der Konsole festzulegen.

  • Aufruf der Run-Methode.

Run

Methode, die die InitializeOptions-Methode aufruft und das ausgewählte Sicherheitsszenario erstellt.

Utilities.cs

Name der Klasse, Methode

oder globalen Variable

Operator

CNG_SecureCommunicationExample

Projektweite partielle Klasse.

Version

fVerbose

fMallory

Globale Variablen.

Autoloader

Methode, die Alice aufruft, um die Anwendungen Bob.exe und Mallory.exe zu laden.

InitConsole

Methode, die das Benutzeroberflächenmenü und Meldungen auf Anwendungsebene behandelt.

SplashScreen

Methode, die Konsolenfenstertitel bereitstellt.

ReadALine

Dienstmethode, die eine vom Benutzer in die Konsole eingegebene Zeile liest.

ReadAChar

Dienstmethode, die eine Frage anzeigt, auf die der Benutzer mit "Ja" oder "Nein" antworten kann.

InitializeOptions

Methode, die Optionen anzeigt und den Benutzer zur Auswahl auffordert. Von dieser Methode werden auch die globalen Flags Version, fVerbose und fMallory festgelegt.

Display(string s)

Die erste von zwei Display-Methoden. Diese Methode übergibt die Zeichenfolge und die MyColor-Variable an die zweite Display-Methode.

Display(string DisplayString, int color)

Die zweite von zwei Display-Methoden. Diese Methode umschließt Console.WriteLine-Anweisungen und stellt Farbunterstützung für Ausgabezeilen bereit.

Weitere Informationen über diese Klassen, Methoden und Variablen finden Sie unter Codeanalyse der Dienstprogrammklassen (CNG-Beispiel).

ChannelManager.cs

Name der Klasse, Methode

oder globalen Variable

Operator

CNG_SecureCommunicationExample

Projektweite partielle Klasse.

AppControl

Methode, die eine interne Anwendungssteuerung bereitstellt und die drei Konsolenanwendungen synchronisiert.

Alice verwendet diese Methode, um die Programmoptionen (Version-Flag und fVerbose-Flag) an Bob und Mallory zu senden.

AppControl ist keine Messagingmethode. Der Inhalt ist nicht verschlüsselt oder signiert. Die Communicator-Klasse wird nicht aufgerufen.

SendChannelName

ReceiveChannelName

Methoden, die verwendet werden, um von der Named Pipe PublicChannel zu den Named Pipes AliceAndBobChannel und AliceAndBobChannel1 zu wechseln. Diese Methoden ermöglichen die absichtliche Sicherheitslücke, die in der Übersicht über das CNG-Beispiel erläutert wird.

ChannelManager

Klasse, die das prozessübergreifende Kommunikationsframework für die Anwendung bereitstellt.

Weitere Informationen über diese Klassen und Methoden finden Sie unter Codeanalyse der 'ChannelManager'-Klasse (CNG-Beispiel).

Communicator.cs

Name der Klasse, Methode

oder globalen Variable

Operator

CNG_SecureCommunicationExample

Projektweite partielle Klasse.

Communicator

Klasse, die alle kryptografischen Funktionen kapselt. Diese Klasse verarbeitet alle Nachrichten zwischen Alice, Bob und Mallory. Sie verarbeitet keine von der ChannelManagerAppControl-Methode gesendeten Nachrichten.

m_DSKey

m_ECDH_Cng

m_ECDH_local_publicKey_XML

m_ECDH_remote_publicKey

ChMgr

Klassenvariablen.

Communicator

Methode, die ein Communicator-Objekt erstellt.

Dispose

Methode, die privat verwendete Ressourcen freigibt.

StoreDSKey

Methode, die einen digitalen Signaturschlüssel speichert.

Send_or_Receive_PublicCryptoKey

Methode, die Unterstützung für den Schlüsselaustausch bereitstellt.

iv

ciphertext

signature

Private Klassenvariablen, die zum Verschlüsseln von Klartextnachrichten verwendet werden. Diese Variablen werden kurz vor oder nach der ReceiveMessage()-Methode deklariert.

ReceiveMessage

Methode, die je nach Sicherheitsversion Klartextnachrichten oder verschlüsselte Nachrichten empfängt.

SendMessage

Methode, die eine ihr übergebene Klartextnachricht je nach Sicherheitsversion im Klartextformat oder im verschlüsselten Format sendet.

Weitere Informationen über diese Klassen, Methoden und Variablen finden Sie unter Codeanalyse der Communicator-Klasse (CNG-Beispiel).

Klassen

Jedes Projekt enthält drei Klassen:

  • public partial class CNG_SecureCommunicationExample

    Diese Klasse ist über alle vier in den Anwendungen Alice, Bob und Mallory enthaltenen Projektdateien verteilt. Nach der Kompilierung enthält die CNG_SecureCommunicationExample-Klasse alle Klassen, Variablen und Methoden für die vier Projektdateien. Weitere Informationen zu partiellen Klassen finden Sie unter Partielle Klassen und Methoden (C#-Programmierhandbuch).

  • internal sealed class ChannelManager

    Diese Klasse stellt Unterstützung für Named Pipes bereit. Während der Ausführung des Programms erstellt jedes Projekt zu unterschiedlichen Zeitpunkten mehrere ChannelManager-Instanzen. Ausführliche Informationen zu dieser Klasse finden Sie unter Codeanalyse der 'ChannelManager'-Klasse (CNG-Beispiel).

  • internal sealed class Communicator

    Diese Klasse stellt Unterstützung für Verschlüsselung und Entschlüsselung bereit. Während der Ausführung des Programms erstellt jedes Projekt zu unterschiedlichen Zeitpunkten mehrere Communicator-Instanzen. Ausführliche Informationen zu dieser Klasse finden Sie unter Codeanalyse der Communicator-Klasse (CNG-Beispiel).

Sicherheitsversionen

Der Quellcode unterstützt das in der Übersicht über das CNG-Beispiel dargestellte Sicherheitsszenario. Es implementiert die folgenden fünf Versionen des Instant Messaging (IM)-Tools, die fünf Sicherheitsebenen darstellen:

  • Version 1: Verwendet Klartextnachrichten und Named Pipes.

  • Version 2: Verwendet verschlüsselte Nachrichten.

  • Version 3: Verwendet verschlüsselte Nachrichten und digitale Signaturen.

  • Version 4: Verwendet verschlüsselte Nachrichten und eine private digitale Signatur.

  • Version 5: Beendet die Anwendung, wenn Sicherheitsfehler auftreten.

Hinweis:

Im verbleibenden Teil dieses Themas wird auf diese Versionen nach ihren Zahlen verwiesen. Weiterhin verweisen die Namen "Alice", "Bob" und "Mallory" je nach Kontext auf die drei Personen aus dem Beispiel oder auf die drei Visual Studio-Anwendungen.

Übersicht über die Sitzung

Alice, Bob und Mallory verfügen jeweils über eine Main-Methode und eine Run-Methode.

Die Main-Methode synchronisiert die Anwendungen und führt die folgenden Funktionen aus:

  • Anzeigen eines Startbegrüßungsbildschirms.

  • Auffordern des Benutzers, Sitzungsoptionen auszuwählen (nur Alice).

  • Senden der Sitzungsoptionen an Bob und Mallory (nur Alice).

  • Empfangen der Sitzungsoptionen von Alice (nur Bob und Mallory).

  • Aufrufen der Run-Methode zum Ausführen der angeforderten Sicherheitssitzung.

Die Run-Methode führt Sicherheitsszenarien aus.

  • Jede Sitzung illustriert eine der im vorherigen Abschnitt aufgeführten Versionen.

  • Eine Sitzung beginnt, wenn Alice, Bob und Mallory mit der Ausführung der Run-Methoden beginnen, und endet, wenn sie zu ihren Main-Methoden zurückkehren.

  • Alice, Bob und Mallory führen während einer Sitzung stets die gleiche Version aus.

  • Alice initiiert alle während einer Sitzung auftretenden Transaktionen. Mallory antwortet Alice und initiiert die Transaktionen mit Bob. Bob antwortet nur.

Der Quellcode für Alice und Bob unterscheidet sich nur wenig. Der hauptsächliche Unterschied besteht darin, dass Alice die Sitzungen initiiert und als Pipeserver dient, während Bob als Pipeclient dient. Der Code von Mallory ist komplizierter, da dieser zwei separate Pipes verwaltet: eine mit Alice und eine mit Bob.

Die 'Main'-Methode

Alice ruft zu Beginn ihrer Main-Methode die InitializeOptions-Methode auf und erhält Sitzungsoptionen (Version, fVerbose, fMallory) vom Benutzer. Mithilfe ihrer AppControl-Methode sendet sie die Optionen an Bob und Mallory, die diese mit ihren AppControl-Methoden empfangen. Wenn der Benutzer die Anwendung durch Eingabe des Buchstabens "x" schließen möchte, sendet die AppControl-Methode von Alice anstelle der Sitzungsoptionen die Zeichenfolge "exit" an Bob und Mallory.

Nachdem die drei Anwendungen die Sitzungsoptionen empfangen haben, rufen sie ihre Run-Methoden auf.

Die 'Run'-Methode

Alice, Bob und Mallory führen die angeforderte Sitzung aus, indem sie die folgenden Schritte ausführen:

  1. Alice ruft die SendChannelName-Methode auf, die einen Channel mit dem Namen PublicChannel verwendet. Sie sendet Bob einen neuen Channelnamen (AliceAndBobChannel).

  2. Wenn das fMallory-Flag auf true festgelegt ist, hört Mallory PublicChannel ab und fängt den neuen Channelnamen (AliceAndBobChannel) von Alice ab. Daraufhin sendet er Bob einen anderen Channelnamen (AliceAndBobChannel1).

  3. Alice und Bob erstellen nach ihnen benannte Communicator-Objekte. Diese Objekte werden in using-C#-Anweisungen erstellt und am Ende der Run-Methode verworfen.

    Alice wird als Pipeserver initialisiert:

    using (Communicator Alice = new Communicator("server", NewChannelName))

    Bob wird als Pipeclient initialisiert:

    using (Communicator Bob = new Communicator("client", NewChannelName))

    Mallory erstellt die beiden Communicator-Objekte MalloryAlice und MalloryBob. Mallory wird als Pipeclient mit Alice initialisiert:

    using (Communicator MalloryAlice = new Communicator("client", AliceChannelName))

    Mallory wird als Pipeserver mit Bob initialisiert:

    using (Communicator MalloryBob = new Communicator("server", BobChannelName"))

  4. Dem Communicator-Klassenkonstruktor wird der Channelname übergeben. Er erstellt ein öffentliches ChannelManager-Objekt mit langer Lebensdauer mit dem Namen ChMgr:

    ChMgr = new ChannelManager(mode, ChannelName);

  5. Dem ChannelManager-Konstruktor wird der Channelname übergeben. Er erstellt eine entsprechende Named Pipe.

    Hinweis:

    An diesem Punkt kommunizieren Alice und Mallory über eine Pipe mit dem Namen AliceAndBobChannel. Mallory und Bob kommunizieren über eine Pipe mit dem Namen AliceAndBobChannel1.

    Bei AliceAndBobChannel und AliceAndBobChannel1 handelt es sich um Channels mit langer Lebensdauer, die bis zum Ende des Sicherheitsszenarios (d. h. bis zum Ende der Run-Methode) geöffnet bleiben.

  6. Durch die Werte des fVersion-Flags (mit dem die Sicherheitsversion gesteuert wird) und des fMallory-Flags (mit dem die Beteiligung von Mallory gesteuert wird) wird der weitere Ablauf festgelegt:

    In Version 3 sendet Alice über PublicChannel einen digitalen Signaturschlüssel an Bob. Sie verwenden diesen digitalen Signaturschlüssel, um Schlüssel und Nachrichten zu signieren. Wenn fMallory auf true festgelegt ist, fängt Mallory den digitalen Signaturschlüssel ab und verwendet ihn zum Signieren der Schlüssel und Nachrichten, die er an Alice und Bob sendet.

    In den Versionen 4 und 5 sendet Alice zwei digitale Signaturschlüssel an Bob. Der digitale Signaturschlüssel 1 ist derselbe Schlüssel, den Alice in Version 3 sendet. Der digitale Signaturschlüssel 2 ist ein geheimer digitaler Signaturschlüssel, von dem Mallory keine Kenntnis hat.

  7. In den Versionen 2 bis 5 tauschen Alice und Bob öffentliche kryptografische Schlüssel aus. Wenn fMallory auf true festgelegt ist, fängt Mallory ihre öffentlichen Schlüssel ab und ersetzt diese durch seine eigenen.

  8. Alice und Bob tauschen Nachrichten aus. Wenn fMallory auf true festgelegt ist, fängt Mallory die Nachrichten von Alice und Bob ab, ändert sie und sendet sie erneut.

  9. Wenn Alice und Bob ihr Gespräch beendet haben, werden Sie aufgefordert, eigene Nachrichten zu senden. Dadurch können Sie verfolgen, wie Ihre Nachrichten verschlüsselt werden und wie Mallory sie verändert. Wenn Sie fertig sind, drücken Sie die EINGABETASTE, um die Steuerung zurück an Alice zu übergeben.

  10. Alice beendet die Sitzung. Die Run-Methoden von Alice, Bob und Mallory übergeben die Steuerung an ihre Main-Methoden, und das Beispiel wird neu gestartet.

Kryptografische Schlüssel (Versionen 2-5)

In den Versionen 2 bis 5 werden Nachrichten mit dem erweiterten Verschlüsselungsstandard (Advanced Encryption Standard, AES)-Algorithmus verschlüsselt. Der Austausch der kryptografischen Schlüssel wird in den Run-Methoden von Alice, Bob und Mallory nach der folgenden Codeanweisung implementiert:

if (2 <= Version)

Der kryptografische Schlüssel wird mithilfe des vom Communicator-Klassenkonstruktor erstellten öffentlichen ChannelManager-Objekts mit langer Lebensdauer (ChMgr) gesendet.

Die folgenden beiden Codeanweisungen machen deutlich, wie Alice den kryptografischen Schlüssel sendet und Bob diesen empfängt:

Alice.Send_or_Receive_PublicCryptoKey("send", MyColor);
Bob.Send_or_Receive_PublicCryptoKey("receive", OtherColor);

Mit dem zweiten Parameter wird die Farbe festgelegt, in der die empfangende Anwendung den Inhalt des kryptografischen Schlüssels anzeigt.

Das unberechtigte Eindringen in AES-Implementierungen wird allgemein als mathematisch unausführbar angesehen. AES bietet jedoch keinen Schutz vor einem Man-in-the-middle-Angriff. Es erscheint widersprüchlich, dass Mallory die Nachrichten von Alice und Bob entschlüsseln kann, obwohl AES eine derart starke Verschlüsselung bietet. Dies ist möglich, da Mallory die gemeinsamen geheimen Schlüssel von Alice und Bob kennt. Aufgrund des Abfangens und Ersetzens der Schlüssel durch Mallory wird die starke AES-Verschlüsselung nutzlos.

Die Verwendung kryptografischer Schlüssel ohne Authentifizierung hat ein trügerisches Gefühl der Sicherheit zur Folge. Alice und Bob gehen davon aus, dass sie mit Version 2 über ein sicheres Schema zur Nachrichtenübertragung verfügen. Tatsächlich ist die Sicherheit bereits vor dem Senden der ersten Nachricht nicht mehr gewährleistet.

Im Unternehmen von Alice und Bob ist nicht bekannt, ob die Angriffe von innerhalb oder außerhalb des Unternehmens kommen. Version 3 des IM-Tools wird entworfen, um die Quelle der Angriffe zu ermitteln.

Über einen öffentlichen Channel ausgetauschte digitale Signaturen (Version 3)

In Version 3 wird versucht, die Sicherheitslücke in Version 2 zu schließen, indem eine digitale Signatur zum Signieren von Schlüsseln und Nachrichten verwendet wird. Der Austausch des digitalen Signaturschlüssels wird in den Run-Methoden von Alice, Bob und Mallory nach der folgenden Codeanweisung implementiert:

if (3 <= Version)

Der digitale Signaturschlüssel wird durch den gleichen öffentlichen Channel mit langer Lebensdauer gesendet wie die kryptografischen Schlüssel. Mit dem folgenden Code wird der digitale Signaturschlüssel gesendet:

Alice.ChMgr.SendMessage(dsKeyBlob);
Hinweis:

Die ChannelManager-Instanz (ChMgr), die den digitalen Signaturschlüssel sendet, ist ein Member des Communicator-Objekts von Alice.

Alice und Bob speichern den digitalen Signaturschlüssel als privaten Member ihrer Communicator-Objekte:

Alice.StoreDSKey(DSKey);
Bob.StoreDSKey(DSKey);

Mallory kopiert jedoch die digitale Signatur problemlos aus PublicChannel und speichert sie:

Mallory.StoreDSKey(DSKey);

Wenn Alice und Bob signierte Nachrichten von einander empfangen, entsprechen die digitalen Signaturen vollkommen den Nachrichten. Der Grund dafür ist, dass Mallory sie mit dem gleichen digitalen Signaturschlüssel signiert, den Alice und Bob verwenden.

In Version 3 werden sowohl die kryptografischen Schlüssel als auch die digitale Signatur über einen öffentlichen Channel über das Unternehmensnetzwerk ausgetauscht. Im Unternehmen, für das Alice und Bob arbeiten, wird vermutet, dass jemand innerhalb des Unternehmens für den Diebstahl verantwortlich ist. Das Unternehmen erstellt Version 4, um diese Vermutung zu testen.

Über einen privaten Channel ausgetauschte digitale Signaturen (Version 4)

In Version 4 werden zwei digitale Signaturschlüssel verwendet: der in Version 3 verwendete Schlüssel und ein zweiter, geheimer Schlüssel, der über einen privaten Channel gesendet wird. Der erste Schlüssel wird nun als falscher digitaler Schlüssel verwendet, mit dem der Dieb dingfest gemacht werden soll. Der zweite Schlüssel wird von Alice und Bob verwendet, um ihre kryptografischen Schlüssel und Nachrichten digital zu signieren.

Nur Alice und Bob bekommen Version 4 der IM-Software. Mallory verwendet weiterhin Version 3. Daher erfährt Mallory nicht, dass die von ihm verwendete digitale Signatur ungültig ist. Die IM-Tools von Alice und Bob zeigen jedoch bei jedem Schlüssel und jeder Nachricht, die sie empfangen, eine Sicherheitswarnung an.

In Version 4 wird weiterhin veranschaulicht, dass sowohl kryptografische Schlüssel als auch Nachrichten abgefangen werden. Dadurch wird deutlich, dass ein Man-in-the-middle-Angriff vorliegt, und dass dieser noch vor dem Senden der kryptografischen Schlüssel beginnt. Daher muss sich ein Mitarbeiter des Unternehmens, der Zugriff auf den PublicChannel des Unternehmens hat, vor Bob anmelden. Die kluge Verwendung des geheimen digitalen Signaturschlüssels enthüllt Mallorys geheime Aktivitäten.

Die Übertragung des geheimen digitalen Signaturschlüssels wird in den Run-Methoden von Alice und Bob nach der folgenden Codeanweisung implementiert:

if (4 <= Version)

Mit den folgenden Codeanweisungen werden die privaten ChannelManager-Instanzen von Alice und Bob erstellt:

ChannelManager ChMgr2 = new ChannelManager("server", "PrivateChannel")
ChannelManager ChMgr2 = new ChannelManager("client", "PrivateChannel")

Der von Alice und Bob verwendete private Channel (ChMgr2) ist kein Member ihrer Communicator-Objekte. Dies wird beim Vergleich der folgenden beiden Codeanweisungen deutlich:

Alice.ChMgr.SendMessage(dsKeyBlob); // Public channel - fake key
ChMgr2.SendMessage(dsKeyBlob);      // Private channel - real key

In der ersten Anweisung wird die ChannelManager-Instanz mit langer Lebensdauer (ChMgr) verwendet, die zu Beginn der Run-Methode erstellt wird. Diese Instanz ist bis zum Ende der Sitzung ein öffentlicher Member der Communicator-Objekte von Alice, Bob und Mallory (siehe Schritt 3 im Abschnitt Übersicht über die Sitzung). In der zweiten Anweisung wird ein temporäres Objekt verwendet, das nur während des Sendens und Empfangens des Schlüssels besteht. Es wird sofort nach der Verwendung verworfen.

Nachdem Alice den geheimen digitalen Signaturschlüssel gesendet hat, empfängt ihn Bob mit der folgenden Anweisung:

DSKey = ChMgr2.ReadMessage();

Alice und Bob speichern den Schlüssel als privaten Member in ihren Communicator-Objekten:

Alice.StoreDSKey(DSKey);
Bob.StoreDSKey(DSKey);

Mit diesen Anweisungen wird auch der falsche digitale Signaturschlüssel überschrieben.

In den Versionen 4 und 5 verwenden Alice und Bob den geheimen digitalen Signaturschlüssel anstelle des falschen digitalen Signaturschlüssels zum Signieren ihrer Schlüssel und Nachrichten. In Version 4 werden außerdem die kryptografischen Schlüssel signiert und Sicherheitswarnungen angezeigt, wenn die digitale Signatur einer Nachricht nicht mit der Nachricht übereinstimmt.

Beenden der Sitzung (Version 5)

Version 5 ist mit Version 4 bis auf den Unterschied, dass die Sitzung beim ersten Fehler beendet wird, identisch. Bei Alice tritt der erste Fehler auf, wenn sie den öffentlichen kryptografischen Schlüssel von Bob erhält und feststellt, dass die digitale Signatur ungültig ist. Bei Bob tritt der erste Fehler auf, wenn er den öffentlichen kryptografischen Schlüssel von Alice erhält und ebenfalls feststellt, dass die digitale Signatur ungültig ist.

Weitere Hinweise

  • Objektfreigabe: using-C#-Anweisungen bieten erhöhte Sicherheit. Sie werden zum Einschließen sämtlicher ChannelManager-Objekte und Communicator-Objekte verwendet. Wenn diese Objekte den Gültigkeitsbereich verlassen, werden sofort ihre Dispose-Methoden aufgerufen und alle intern belegten Ressourcen freigegeben.

  • Codierungsmethoden: Wenn verschlüsselte Daten übertragen werden, sollten diese stets als UTF8 oder Unicode, nicht jedoch als ASCII codiert werden.

Einschränkungen des CNG-Beispiels

Der Zweck des CNG-Beispiels für sichere Kommunikation ist die Darstellung der verwalteten CNG-Funktionen. Folglich wurden bestimmte Funktionalitäten einschließlich der folgenden ausgelassen:

  • Parametervalidierung in allen Methoden.

  • Umfangreiche Verwendung von try/catch-Blöcken.

  • Stabile Ermittlung der Trennung von Pipes.

  • Protokollierung der Bildschirmausgabe in einer Datei.

  • Dynamische Konfigurierbarkeit des Verschlüsselungsalgorithmus.

  • Dynamische Konfigurierbarkeit des digitalen Signaturalgorithmus.

  • Eine andere Art, den digitalen Signaturschlüssel an Bob zu senden. Bei der Named Pipe PrivateChannel handelt es sich um eine einfache Lösung. Es sind auch ausgereiftere Methoden vorhanden.

  • Dauerhaftigkeit, Speichern und Abrufen von Schlüsseln.

  • Verwendung vom Betriebssystem generierter digitaler Signaturschlüssel.

  • Verwendung von Schlüsseln, die von einer Public Key-Infrastruktur (PKI) bereitgestellt werden.

Diese Features verursachen eine größere Komplexität des Codes und würden den Rahmen dieses Beispiels sprengen.

Siehe auch

Konzepte

Beispiel für sichere Cryptography Next Generation (CNG)-Kommunikation

Schrittweiser Austausch von Schlüsseln und Nachrichten (CNG-Beispiel)

Erwartete Ausgabe (CNG-Beispiel)

Änderungsprotokoll

Date

Versionsgeschichte

Grund

Juli 2008

Thema hinzugefügt.

Informationsergänzung.