DE19548387C1 - Verfahren zur kryptographischen Sicherung der rechnergestützten digitalen Kommunikation zwischen einem Programm und mindestens einer Benutzereinheit - Google Patents

Description

Die Erfindung betrifft ein Verfahren zur kryptographischen Sicherung der Kommunikation in sogenannten Client-Server-Fen­ ster-Systemen mit einer offenen Netzschnittstelle. Ein Beispiel solcher Client-Server-Fenster-Systeme ist beschrie­ ben in [1].

Durch eine zusätzliche Verwendung einer sogenannten Applica­ tion Sharing Komponente, die dazu verwendet wird, Anforderun­ gen von Benutzereinheiten an das Programm zu multiplexen und Nachrichten von dem Programm, zum Beispiel Ereignismeldungen, Antworten oder Fehlermeldungen, für die Benutzereinheiten zu demultiplexen, wird die gemeinsame Nutzung einer Standard- Ein-Benutzer-Anwendung (Standard Single User Application) zwischen verschiedenen heterogenen Umgebungen, die sich an unterschiedlichen Orten befinden können, erreicht.

Diese gemeinsame Bearbeitung eines Programms wird als Appli­ cation Sharing bezeichnet.

Um jedoch auch eine verläßliche Kommunikation vertraulicher Daten zu erreichen, muß das in [1] beschriebene Client-Server-Fenster-System um kryptographische Merkmale erweitert werden.

Dies ist von besonderer Bedeutung bei unternehmensübergrei­ fender Kommunikation. Dies bedeutet bei einer Kommunikation zwischen Rechnern, bei denen sich ein Rechner im prinzipiell abgesicherten vertrauenswürdigen sogenannten Corporate Net­ work eines Unternehmens befindet, und anderen Rechnern, die sich in einer gemeinsamen synchronen verteilten Arbeitsumge­ bung mehrerer vernetzter Rechner, in einem sogenannten Compu­ ter System Cooperated Work-System (CSCW-Systemen), welches Application Sharing realisiert, befindet, nur über einen un­ sicheren Kanal erreicht werden kann, wodurch eine sichere Kommunikation nicht mehr gewährleistet ist.

Solche CSCW-Systeme basieren auf der Möglichkeit, eine Stan­ dard-Ein-Benutzer-Anwendung (Standard Single User Applicati­ on) gemeinsam mit anderen Benutzern zu einem Zeitpunkt zu be­ arbeiten.

Die zwischen den Rechnern ausgetauschte Information kann von besonderer Bedeutung sein, beispielsweise kann es sich um vertrauliche Geschäftsinformation handeln, um Designspezifi­ kationen, Finanztransaktionen oder um medizinische Daten, die über den unsicheren Kanal ausgetauscht werden.

Aus diesem Grund ist es notwendig auch für diese Transaktio­ nen von Anwendungsdaten eine gewisse Sicherheit zu gewährlei­ sten.

Bei vielen kommerziellen Systemen, die auf dem in [1] be­ schriebenen Client-Server-Fenster-System beruhen, ist eine direkte Integration kryptographischer Merkmale nicht möglich.

Der Erfindung liegt somit das Problem zugrunde, ein Verfahren zur kryptographischen Sicherung der rechnergestützten digita­ len Kommunikation zwischen einem Programm und mindestens ei­ ner Benutzereinheit, anzugeben.

Das Problem wird durch das Verfahren gemäß Patentanspruch 1, das Verfahren gemäß Patentanspruch 4, das Verfahren gemäß Pa­ tentanspruch 7 sowie das Verfahren gemäß Patentanspruch 8 ge­ löst.

Bei dem Verfahren gemäß Patentanspruch 1 wird von dem Pro­ gramm eine Nachricht gebildet, die für ein Transportprotokoll codiert wird. Direkt nach der Codierung wird unter Verwendung des Transportprotokolls die codierte Nachricht wieder deco­ diert und die decodierte Nachricht einem kryptographischen Verfahren unterzogen. Danach wird die Anforderung wiederum mit dem Transportprotokoll codiert und an mindestens eine Be­ nutzereinheit übertragen. Hierbei können sich das Programm und die Benutzereinheit auf einem oder auch auf verschiedenen Rechnern befinden.

Bei dem Verfahren gemäß Patentanspruch 4 werden prinzipiell dieselben Schritte ausgeführt, mit dem Unterschied, daß dies­ mal eine Anforderung in einer Benutzereinheit gebildet wird und dort auch die im vorigen beschriebenen weiteren Schritte durchgeführt werden. Zum Schluß des Verfahrens wird in diesem Fall die codierte kryptographische verarbeitete Anforderung zu dem Programm übertragen.

Bei dem Verfahren gemäß Patentanspruch 7 wird von der Situa­ tion ausgegangen, daß auf der Seite des Programms eine Erwei­ terung des Client-Server-Fenster-Systems durch Sicherheitsme­ chanismen unterschiedlichster Art, die im weiteren beschrie­ ben werden, möglich ist. Für diesen Fall werden die im vori­ gen beschriebenen Verfahrensschritte ausgehend von der Bil­ dung einer Nachricht in dem Programm nur nach Empfang der kryptographisch in der eingefügten Sicherheitsschicht auf der Seite des Programms bearbeiteten Anforderungen in einer der Benutzereinheiten durchgeführt. Dort werden also die inversen kryptographischen Verfahren zur Bearbeitung der Nachrichten durchgeführt, wobei dieser Verfahrensschritt durch eine zuvor erfolgte Decodierung mit dem Transportprotokoll und eine nachfolgende Codierung mit dem Transportprotokoll charakteri­ siert ist.

Das Verfahren gemäß Patentanspruch 8 weist prinzipiell die gleichen Verfahrensschritte auf wie das Verfahren gemäß Pa­ tentanspruch 7 mit dem Unterschied, daß hierbei eine Anforde­ rung von einer Benutzereinheit gebildet wird und an das Pro­ gramm übertragen wird. Die Stellen, an denen die einzelnen Verfahrensschritte ablaufen, und die Stellen, an denen die Verfahrensschritte des Patentanspruchs 7 ausgeführt werden, sind in diesem Fall einfach vertauscht.

Vorteilhafte Weiterbildungen der erfindungsgemäßen Verfahren ergeben sich aus den abhängigen Ansprüchen.

Es ist vorteilhaft, als kryptographische Bearbeitung zumin­ dest eine Verschlüsselung der Anforderung vorzusehen. Damit wird die Vertraulichkeit der ausgetauschten Daten gewährlei­ stet.

Weiterhin ist es vorteilhaft, als kryptographische Bearbei­ tung der Anforderung Integritäts- und Authentikationsmecha­ nismen vorzusehen, wodurch dann jeweils gewährleistet ist, daß die empfangene Nachricht tatsächlich von dem Absender stammt, der auch in der Nachricht als Absender angegeben ist.

In einer Weiterbildung der erfindungsgemäßen Verfahren ist es außerdem vorteilhaft, als kryptographische Verfahren Zu­ griffskontrollmechanismen zu realisieren, um somit sicherzu­ stellen, daß wirklich nur diejenigen Anforderungen auch durchgeführt werden, die auch die Berechtigung zur Durchfüh­ rung aufweisen.

Ferner ist es vorteilhaft vor Beginn des Verfahrens in einer Initialisierungsphase beispielsweise die kryptographischen Schlüssel, die zur Realisierung der einzelnen kryptographi­ schen Verfahren eingesetzt werden, auszutauschen zwischen dem Programm und der mindestens einen Benutzereinheit.

Eine vorteilhafte Verwendung der Verfahren findet sich beim Datenaustausch zwischen Kommunikationspartnern, die über die Grenzen eine Coporate Networks, welches durch kryptographi­ sche Verfahren in sich gesichert ist, über einen unsicheren Kanal in einem sogenannten Firewall.

Durch eine solche Verwendung ist es nicht mehr wie bisher nö­ tig, bei einer vorgesehenen Kommunikation über Coporate Net­ work-Grenzen hinweg den für die Kommunikation zu verwendenden Rechner von dem gesamten Netz des Coporate Networks zu ent­ koppeln, um somit nicht das gesamte Coporate Network zu ge­ fährden bei möglichen Angriffen über den unsicheren Kommuni­ kationskanal.

In den Figuren sind einige Ausführungsbeispiele dargestellt, die im folgenden näher erläutert werden.

Es zeigen

Fig. 1 das allgemeine Prinzip eines Client-Server-Fenster-Systems;

Fig. 2 das allgemeine Prinzip eines Client-Server-Fenster-Systems in einer "Mehrbenutzer-Umgebung";

Fig. 3 eine Anordnung, die die Mehrbenutzer-Umgebung detail­ lierter beschreibt;

Fig. 4 ein prinzipielles Blockschaltbild, in dem das Einfü­ gen einer Sicherheitsschicht zwischen Client-Surfer-Fenster­ system und dem Transportprotokoll beschrieben ist;

Fig. 5 eine Anordnung, in der prinzipiell dargestellt ist, wie das erfindungsgemäße Verfahren in einem Firewall zur Kommunikationssicherung über Coporate Network-Gren­ zen hinweg verwendet werden kann;

Fig. 6 ein Ablaufdiagramm, in dem die Verfahrensschritte des Verfahrens gemäß Patentanspruch 1 dargestellt sind;

Fig. 7 ein Ablaufdiagramm, in dem die Schritte des Verfah­ rens gemäß Patentanspruch 2 dargestellt sind;

Fig. 8 ein Blockdiagramm, in dem die einzelnen Möglichkeiten zur Realisierung der sicherheitsspezifischen Bearbei­ tung der Anforderung bzw. der inversen sicherheits­ spezifischen Bearbeitung der Anforderung beschrieben ist.

Fig. 9 ein Ablaufdiagramm, in dem die einzelnen Verfahrens­ schritte des Verfahrens gemäß Patentanspruch 4 darge­ stellt sind;

Fig. 10 ein Ablaufdiagramm, in dem die Schritte des Verfah­ rens gemäß Patentanspruch 5 dargestellt sind;

Fig. 11 ein Ablaufdiagramm, in dem die Schritte des Verfah­ rens gemäß Patentanspruch 7 dargestellt sind;

Fig. 12 ein Ablaufdiagramm, in dem die Schritte des Verfah­ rens gemäß Patentanspruch 8 dargestellt sind;

Fig. 13 ein Blockschaltbild, in dem die einzelnen zur Durch­ führung des Verfahrens gemäß Patentanspruch 1 benö­ tigten Komponenten und der Nachrichtenaustausch be­ schrieben ist;

Fig. 14 ein Blockschaltbild, in dem die einzelnen zur Durch­ führung des Verfahrens gemäß Patentanspruch 4 benö­ tigten Komponenten und der Nachrichtenaustausch be­ schrieben ist;

Fig. 15 ein Blockschaltbild, in dem die einzelnen zur Durch­ führung des Verfahrens gemäß Patentanspruch 2 benö­ tigten Komponenten und der Nachrichtenaustausch be­ schrieben ist;

Fig. 16 ein Blockschaltbild, in dem die einzelnen zur Durch­ führung des Verfahrens gemäß Patentanspruch 5 benö­ tigten Komponenten und der Nachrichtenaustausch be­ schrieben ist;

Fig. 17 ein Blockschaltbild, in dem die einzelnen zur Durch­ führung des Verfahrens gemäß Patentanspruch 7 benö­ tigten Komponenten und der Nachrichtenaustausch be­ schrieben ist;

Fig. 18 ein Blockschaltbild, in dem die einzelnen zur Durch­ führung des Verfahrens gemäß Patentanspruch 8 benö­ tigten Komponenten und der Nachrichtenaustausch be­ schrieben ist.

Anhand der Fig. 1 bis 18 wird die Erfindung weiter erläu­ tert.

In Fig. 1 ist eine Benutzerumgebung dargestellt, die bei­ spielsweise bei einem Client-Server-Fenster-System, welches in [1] beschrieben ist, auftritt.

Diese Anordnung weist mindestens folgende Komponenten auf:

• - eine Benutzereinheit XS, im weiteren als auch Server XS be­ zeichnet, die wiederum folgende Komponenten aufweist:
• - mindestens eine Treibereinheit DD, die eine Kopplung zwi­ schen weiteren Peripheriekomponenten mit einem im weiteren beschriebenen Klienten XC ermöglicht,
• - eine Bildschirmeinheit BS,
• - eine Tastatur TA,
• - eine Maus MA,
• - den Klienten XC, der mindestens folgende Komponenten auf­ weist:
• - eine Menge von Bibliotheksroutinen XL sowie
• - eine Anwendung ANW.

Die Bildschirmeinheit BS, die Tastatur TA, die Maus MA sowie eventuell außerdem vorhandene weitere Peripherieeinheiten bilden die im vorigen beschriebenen Peripheriekomponenten, die über die entsprechenden Treibereinheiten DD mit dem Kli­ enten XC gekoppelt sind.

Die Menge der Bibliotheksroutinen XL des Klienten XC bildet die Schnittstelle zwischen der Anwendung ANW, beispielsweise einem Textverarbeitungsprogramm oder auch einem Tabellenkal­ kulationsprogramm oder allen anderen bekannten Anwendungen ANW, und der Benutzereinheit XS.

Zusammen bilden die Bibliotheksroutinen XL sowie die Anwen­ dung ANW ein Programm P.

Auch wenn in diesem Ausführungsbeispiel nur jeweils eine An­ wendung ANW bzw. ein Programm P beschrieben wird, können selbstverständlich mehrere Anwendungen ANW und damit mehrere Klienten XC auf einer, diese Anwendung ANW ausführenden Rech­ nereinheit zur Verfügung gestellt werden.

Diese in Fig. 1 dargestellte Anordnung ist also nur ein sehr einfaches, prinzipielles Beispiel für den Ablauf der Kommuni­ kation eines Klienten XC mit dem Server XS, wie sie unter dem bekannten, in [1] beschriebenen Client-Server-Fenster-System durchgeführt wird.

Von dem Server XS wird eine Anforderung A an den Klienten XC gesendet. Dadurch werden in dem Klienten XC Aktionen, bei­ spielsweise in der Anwendung ANW, angestoßen.

Die Anforderung A kann zum Beispiel eine Eingabe auf der Ta­ statur TA sein, die durch die Treibereinheiten DD in die An­ forderung A "übersetzt" und an den Klienten XC gesendet wird.

Die Anwendung ANW, beispielsweise ein Textbearbeitungspro­ gramm oder ein Kalkulationsprogramm, ein Zeichenprogramm und ähnliche Programme, kann nun die Eingabe akzeptieren und bei­ spielsweise als einen neuen Buchstaben in der Textdatei auf­ nehmen.

Damit diese Änderung in der Textdatei auch auf dem Bildschirm BS dargestellt werden kann, wird in einer Antwort B in diesem Fall beispielsweise eine Darstellungsnachricht an die Bild­ schirmeinheit BS gesendet, mit der eine Änderung in der Bild­ schirmdarstellung angefordert wird.

Ein Nachteil vieler kommerzieller Systeme, die nach diesem Prinzip arbeiten, liegt vor allem darin, daß eine direkte In­ tegration benötigter Sicherheitsmechanismen in das Client-Server-Fenster-System oftmals nicht möglich ist.

Hierzu wäre nämlich ein direkter Eingriff in die Schnittstel­ le zwischen den Bibliotheksroutinen XL und den Transportpro­ tokollen nötig. Diese sind eben oftmals dem Benutzer nicht zugänglich.

In Fig. 6 ist ein Ablaufdiagramm mit einzelnen Verfahrens­ schritten des erfindungsgemäßen Verfahrens gemäß Patentan­ spruch 1 dargestellt. Die zur Durchführung dieses Verfahrens nötige Anordnung ist in Fig. 13 beschrieben.

Von dem Programm P wird in einem ersten Schritt 601 die Nach­ richt B gebildet.

In einer Transportprotokollschicht TP wird aus der Nachricht B eine neue Nachricht gebildet, in dem die Nachricht B in das Transportprotokollformat "eingebettet", also codiert wird 602, CB.

Eine Übersicht über verschiedene Transportprotokolle ist in [2] zu finden. Die erfindungsgemäßen Verfahren sind unabhän­ gig von dem speziell jeweils verwendeten Transportprotokoll.

Entweder auf derselben Rechnereinheit, auf der das Programm P läuft, oder auf einer gesondert vorgesehenen ersten Siche­ rungscomputereinheit SC1, die über einen sicheren Kanal mit dem Rechner gekoppelt ist, wird in der dort vorgesehenen Transportprotokollschicht TP die codierte Nachricht CB deco­ diert 603, DB.

Die decodierte Nachricht DB wird nun einer Sicherheitsschicht SL zugeführt, in der sie unterschiedlichen, beliebig vorgege­ benen kryptographischen Verfahren unterzogen wird 604.

Eine durch die kryptographische Bearbeitung gebildete krypto­ graphisch bearbeitete Nachricht VB wird nun wiederum in der Transportprotokollschicht TP codiert 605, wodurch eine co­ dierte kryptographisch verarbeitete Nachrichtung CVB gebildet wird.

Die codierte kryptographisch verarbeitete Nachricht CVB wird in einem letzten Schritt 606 an die Benutzereinheit XS, also an den Server übertragen.

Der prinzipiell umgekehrt gelagerte Fall für die Anforderung A aus Fig. 1 ist in Fig. 9 in Form eines Ablaufdiagramms und in Fig. 14 in Form eines Blockdiagramms für die Anord­ nung, die zur Durchführung des Verfahrens benötigt wird, dar­ gestellt.

In diesem Fall wird die Anforderung A von der Benutzereinheit XS gebildet 901.

Die Anforderung A wird der Transportprotokollschicht TP zuge­ führt und dort in das jeweils verwendete Transportprotokoll­ format eingebettet 902. Eine hieraus resultierende codierte Anforderung CA wird nunmehr entweder in der Benutzereinheit XS selbst oder in einer gesondert vorgesehenen zweiten Siche­ rungscomputereinheit SC2, die über einen sicheren Kanal mit der Benutzereinheit XS gekoppelt ist, in der Transportproto­ kollschicht TP "ausgepackt", also decodiert 903, wodurch eine decodierte Anforderung DA gebildet wird.

In der Sicherheitsschicht SL wird die ihr zugeführte deco­ dierte Anforderung DA nunmehr den vorgesehenen kryptographi­ schen Verfahren, die im weiteren beschrieben werden, unterzo­ gen 904. Daraus resultiert eine kryptographisch bearbeitete Anforderung VA.

Die kryptographisch bearbeitete Anforderung VA wird wiederum der Transportprotokollschicht TP zugeführt 905 und dort co­ diert, wodurch eine codierte kryptographisch bearbeitete An­ forderung CVA gebildet wird. Die codierte kryptographisch be­ arbeitete Anforderung CVA wird in einem letzten Schritt 906 an das Programm P, also an den Klienten XC übertragen.

Eine Weiterbildung des Verfahrens gemäß Patentanspruch 1 ist in Fig. 7 in Form eines Ablaufdiagramms, sowie die zur Durchführung dieses Verfahrens notwendige Anordnung in Fig. 16 dargestellt.

Nachdem die in Fig. 6 dargestellten Verfahrensschritte zur letztendlich gebildeten codierten kryptographisch verarbeite­ ten Nachricht CVB, die an die Benutzereinheit XS übertragen wird, durchgeführt wurden, wird die codierte kryptographisch bearbeitete Nachricht CVB von der mindestens einen Benut­ zereinheit XS oder von der zweiten Sicherungscomputereinheit SC2 empfangen 701.

Unter Verwendung des zur Codierung verwendeten Transportpro­ tokolls wird die codierte kryptographisch bearbeitete Nach­ richt CVB in der Transportprotokollschicht TP der Benut­ zereinheit oder der zweiten Sicherungscomputereinheit SC2 "ausgepackt", also decodiert 702.

Damit wird eine decodierte kryptographisch verarbeitete Nach­ richt DVB gebildet, die nun der Sicherungsschicht SL, die auch auf der Seite der Benutzereinheit XS bzw. der zweiten Sicherungscomputereinheit SC2 vorgesehen ist, zugeführt. In der Sicherheitsschicht SL wird die decodierte kryptographisch bearbeitete Nachricht DVB den jeweils inversen kryptographi­ schen Verfahren unterzogen 703. Invers bedeutet in diesem Zu­ sammenhang invers zu den kryptographischen Verfahren, die in der Sicherheitsschicht des Klienten XC bzw. der ersten Siche­ rungscomputereinheit SC1 auf die decodierte Nachricht DB an­ gewendet wurden.

Das Ergebnis dieser kryptographischen Bearbeitung ist eine invers kryptographisch bearbeitete Nachricht DEB, die nun wiederum der Transportprotokollschicht TP zugeführt wird, wo sie auch wieder codiert wird 704.

Die daraus entstandene codierte invers kryptographisch bear­ beitete Nachricht CEB wird wiederum der Transportprotokoll­ schicht TP zugeführt und dort decodiert 705.

Die resultierende Nachricht wird nunmehr dem eigentlichen Server XS, also der Benutzereinheit XS, zugeführt und dort weiterverarbeitet. Es ist selbstverständlich in einer Varian­ te des Verfahrens auch möglich, direkt die invers kryptogra­ phisch bearbeitete Nachricht DEB weiter zu verarbeiten.

Die prinzipiell gleiche Weiterbildung des Verfahrens gemäß Patentanspruch 4 wie die im vorigen beschriebene Weiterbil­ dung für das Verfahren gemäß Patentanspruch 1 ist in Fig. 10 dargestellt sowie die zur Durchführung des Verfahrens gemäß Patentanspruch 5 benötigte Anordnung in Fig. 17.

Bei dieser Weiterbildung wird wiederum davon ausgegangen, daß die in Fig. 9 beschriebenen Verfahrensschritte bis zur Co­ dierung der kryptographisch bearbeiteten Anforderung VA und deren Übertragung an das Programm P durchgeführt wurden.

Die übertragene codierte kryptographisch bearbeitete Anforde­ rung CVA wird von dem Programm P oder von der ersten Siche­ rungscomputereinheit SC1 empfangen 1001.

In einem weiteren Schritt 1002 wird unter Verwendung des Transportprotokolls wiederum die codierte kryptographisch be­ arbeitete Anforderung CVA "ausgepackt", also decodiert in der Transportprotokollschicht TP.

Weiter wird die daraus resultierte decodierte kryptographisch bearbeitete Anforderung DVA in der Sicherheitsschicht SL, der sie zugeführt wurde, der zu dem eingesetzten kryptographi­ schen Verfahren inversen kryptographischen Verarbeitung un­ terzogen 1003.

Die resultierende invers kryptographisch bearbeitete Anforde­ rung DEA wird wiederum in der Transportprotokollschicht TP codiert 1004.

Anschließend wird sie in der Transportprotokollschicht TP wiederum decodiert 1005 und dem Programm P zugeführt. Dort wird die eigentliche Anforderung A weiterverarbeitet.

Wiederum ist es ebenso möglich, direkt die decodierte invers kryptographisch bearbeitete Anforderung DEA dem Programm P zuzuführen und dort weiterzuverarbeiten.

In Fig. 11 ist ein weiteres Verfahren, das ebenso auf der gemeinsamen erfinderischen Idee der im vorigen beschriebenen Verfahren basiert, beschrieben.

Hierbei wird jedoch vorausgesetzt, daß es möglich ist, direkt eine Sicherheitsschicht SL zwischen dem Klienten XC und der Transportprotokollschicht TP einzufügen. Hieraus ergibt sich nunmehr nicht mehr die Notwendigkeit auf der Seite des Klien­ ten XC die Transportprotokollschicht TP zweimal zu "durchlaufen".

Dies ist in der Anordnung von Fig. 17 dargestellt.

Hierbei wird wiederum von dem Programm P die Nachricht B ge­ bildet 1101. Die Nachricht B wird jedoch diesmal direkt in der Sicherheitsschicht S- einen kryptographischen Verfahren unterzogen VB, 1102. Die resultierende kryptographisch bear­ beitete Nachricht VB wird der Transportprotokollschicht TP zugeführt, wo sie codiert wird 1103.

Die codierte kryptographisch bearbeitete Nachricht CVB wird an die Benutzereinheit XS übertragen 1104, dort von der Be­ nutzereinheit XS oder der zweiten Sicherungscomputereinheit SC2 empfangen 1105, in der dort vorgesehenen Transportproto­ kollschicht TP decodiert zu der decodierten kryptographisch bearbeiteten Nachricht DVB 1106.

Diese wird der Sicherheitsschicht SL zugeführt und dort dem bzw. den inversen kryptographischen Verfahren unterzogen 1107.

In zwei letzten Schritten wird die invers kryptographisch be­ arbeitete Nachricht DEB in der Transportprotokollschicht TP wiederum codiert 1108 und in einem letzten Schritt decodiert 1109.

Die daraus resultierende Nachricht B wird dem Server XS zuge­ führt und weiter verarbeitet.

Die Sicherheitsschicht SL ist in Fig. 4 dargestellt für den Fall, daß es möglich ist, die Sicherheitsschicht SL zwischen die Transportschicht TP und die Bibliotheksroutinen XL einzu­ fügen.

Hierbei werden für das spezielle Beispiel, das jedoch die Allgemeingültigkeit in keinster Weise einschränkt, ungesi­ cherte read, write, readv, writev connect und accept Nach­ richten durch in der Sicherheitsschicht SL vorgesehene kryp­ tographische Verfahren "abgesichert". Dies erfolgt durch An­ wendung der vorgesehenen kryptographischen Verfahren auf die jeweilige Nachricht B bzw. Anforderung A. Die durch die Si­ cherheitsschicht SL "gesicherten" Nachrichten sind mit einem Stern * in Fig. 4 gekennzeichnet.

Die beschriebene kryptographische Sicherung der Kommunikation einer Anwendung mit einem Fenstersystem über ein Netz setzt einerseits den Austausch kryptographischer Schlüssel voraus und beruht andererseits auf einer wechselseitigen Authentika­ tion der beiden Kommunikationspartner.

Zu dieser Authentikation können asymmetrische, kryptographi­ sche Verfahren mitsamt Zertifikaten, die öffentliche Schlüs­ sel enthalten, vorteilhaft eingesetzt werden. Durch eine ge­ eignete Definition der Identitätsmerkmale in dem Zertifikat ist es möglich, Dienste wie Anwendungen oder Fensterdienst­ programme über die reine Rechneradresse im Netz hinaus zu identifizieren und zu authentisieren. Solche über die Netza­ dresse hinausgehenden Identitätsmerkmale zur Differenzierung verschiedener Anwendungsprogramme eines Rechners können z. B. der Name des Dienstebesitzers auf einem Mehrbenutzersystem sein.

Die wechselseitige Authentikation und der Schlüsselaustausch werden in einer Initialisierungsphase zum Aufbau der sicheren Verbindung realisiert.

In einer Weiterbildung des erfindungsgemäßen Verfahrens ist es vorteilhaft, auf der Seite des Fensterdienstprogrammes, also der Benutzereinheit XC eine Zugriffskontrolle auf Basis der authentifizierten Identität des Programmes P durchzufüh­ ren. Da die authentifizierte Identifikationsinformation über die Rechneradresse des Programmes P hinausgehen kann, kann eine Zugriffskontrolle zwischen verschiedenen Programmes P eines Rechners unterscheiden und somit den Verbindungsaufbau steuern.

Eine vorteilhafte Anwendung der beschriebenen Sicherungsver­ fahren findet sich beim Austausch von Anwendungsdaten zwi­ schen einem Programmes P und einem Fensterdienstprogramm, al­ so einer Benutzereinheit XC, wobei zwischen beiden nur eine nicht vertrauenswürdige Netzverbindung geschaltet werden kann.

Dieses Szenario ist von besonderer Bedeutung für die oben be­ schriebenen CSCW-Systeme, die Application Sharing realisie­ ren. Hierbei befinden sich die beteiligten Fensterdienstpro­ gramme der Benutzereinheiten XC oftmals in verschiedenen Fir­ mennetzen und können Daten mit der Anwendung bzw. der Appli­ cation Sharing Komponente nur über öffentliche Netze austau­ schen.

Mit dem Betreiben des bekannten Fenstersystems sind erhebli­ che Sicherheitsprobleme verbunden, welche in [6], [7] be­ schrieben werden. Aufgrund des erheblichen Risikopotentials, welches mit dem aus [1] bekannten Fenstersystem verbunden ist, lassen es die Betreiber von Firmennetzen in der Regel nicht zu, daß solche Fensterdienstprogramme mit Anwendungen außerhalb des Firmennetzes zusammenarbeiten. Dies dient dem Schutz firmeninterner Informationen und Datenbestände. Dieser Schutz wird durch sogenannte Firewalls am Netzübergang zwi­ schen internem Netz und externen Netzen realisiert. Diese verhindern durch eine Filterung von Datenpaketen auf Trans­ portsystemebene, daß externe Anwendungsprogramme auf interne Fensterdienstprogramme zugreifen.

Diese üblichen Vorkehrungen verhindern aber die Nutzung syn­ chroner CSCW-Systeme, die darauf beruhen, daß Nutzer an un­ terschiedlichen Standorten und in verschiedenen Firmen ge­ meinsam durch ein synchrones CSCW-System kooperieren und ge­ meinsam mit Anwendungsprogrammen arbeiten.

Auf Basis des beschriebenen Sicherungsverfahren für Anwen­ dungsdaten läßt sich ein Programm für ein Firewall konstruie­ ren, welches es ermöglicht, interne Fensterdienstprogramme auf sichere Weise mit externen Anwendungsprogrammen kommuni­ zieren zu lassen:

Dieses spezielle Programm beruht einerseits auf der beschrie­ benen Sicherheitserweiterung zum Schutz von Anwendungsdaten in Fenstersystemen und andererseits auf einer Durchschalte­ komponente für Anwendungsdaten. Die Durchschaltekomponente kann direkt aus der Application Sharing Komponente ASC abge­ leitet werden, da hierzu die Anforderung des Multiplexens und Demultiplexens entfällt.

Diese beiden Komponenten (Sicherheitsdienstprogramm und Durchschaltekomponente) bilden ein spezielles Firewall-Si­ cherheitsdienstprogramm durch welches es möglich wird, von einem externen Anwendungsprogramm eine spezifische Authenti­ kation zu verlangen, sowie es einer Zugriffskontrolle zu un­ terziehen, bevor die Durchschaltekomponente die Verbindung zu dem internen Fensterdienstprogramm herstellt und anschließend die Verbindung durchstellt. Der nachfolgende Datenaustausch zwischen dem externen Anwendungsprogramm und dem Firewall-Si­ cherheitsdienstprogramm wird durch kryptographische Mecha­ nismen geschützt.

Durch das Betreiben von Paketfiltern im Firewall können ex­ terne Anwendungsprogramme gezwungen werden, zunächst die Ver­ bindung zu dem beschriebenen Sicherheitsdienstprogramm aufzu­ nehmen.

Das entsprechende Verfahren unter Berücksichtigung des "Rollentauschs" zwischen Programm und Benutzereinheit XS, al­ so für die Anforderung A, ist in Fig. 12 sowie die zu deren Durchführung benötigte Anordnung in Fig. 18 dargestellt.

Hierbei wird natürlich angenommen, daß die Sicherheitsschicht SL auf der Seite der Benutzereinheit XS zwischen die Benut­ zereinheit XS und die Transportprotokollschicht TP eingefügt werden kann.

Unter dieser Annahme wird also von der Benutzereinheit XS die Anforderung A gebildet 1201. Diese wird direkt in der Sicher­ heitsschicht SL dem kryptographischen Verfahren VA unterzogen 1202.

Die kryptographisch bearbeitete Anforderung VA wird in der Transportprotokollschicht TP codiert 1203 und im Anschluß daran wird die codierte kryptographisch bearbeitete Anforde­ rung CVA an das Programm P übertragen 1204.

Dort wird sie von dem Programm P oder von der ersten Siche­ rungscomputereinheit SC1 empfangen 1205. In einer auch dort vorgesehenen Transportprotokollschicht TP wird sie nunmehr decodiert zur decodierten kryptographisch bearbeiteten Anfor­ derung DVA 1206.

In der Sicherheitsschicht SL der sie in einem weiteren Schritt zugeführt wird, wird die decodierte kryptographische Anforderung dem inversen kryptographischen Verfahren unterzo­ gen 1207. Die daraus resultierende invers kryptographisch be­ arbeitete Anforderung DEA wird in der Transportprotokoll­ schicht TP wiederum "eingepackt", also codiert 1208.

Die codierte inverse kryptographische bearbeitete Anforderung CEA wird in der Transportprotokollschicht TP in einem weite­ ren Schritt wiederum decodiert 1209 und die resultierende An­ forderung A, die nunmehr kryptographisch "abgesichert" ist, wird dem Programm zugeführt und von dem Programm P weiter verwendet.

Verschiedene Möglichkeiten zur Realisierung der zu verwenden­ den kryptographischen Verfahren in der Sicherheitsschicht SL sind in Fig. 8 dargestellt.

Zum einen ist es möglich, Verschlüsselungsverfahren 81 in der Sicherheitsschicht SL anzuwenden. Damit wird eine Vertrau­ lichkeit bzw. Integrität der ausgetauschten Nachrichten B bzw. Anforderungen A erreicht.

Ferner ist es vorgesehen, in der Sicherheitsschicht SL auch Authentikationsmechanismen 82 zu verwenden. Diese erlauben es, Identitätsangaben der Kommunikationspartner im Netz zu verifizieren. Diese Authentikationsmechanismen haben besonde­ re Bedeutung in Zusammenhang zum Beispiel des Transport Con­ trol Protocols (TCP), oder auch des User Datagramm Protocols (UDP), da diese keinerlei Authentikationsmechanismen für Sen­ der und Empfänger aufweisen.

Auch die Realisierung von Zugriffskontrollmechanismen 83, die auf den Authentikationsverfahren beruhen, bietet zusätzlichen Schutz des Zugangs zu dem Fensterdienstprogramm in einem Cli­ ent-Server-Fenster-System.

Die im vorherigen beschriebenen Verfahren können natürlich auch auf Mehrbenutzersysteme sehr vorteilhaft angewendet wer­ den.

Wie das [1] beschriebene Client-Server-Fenstersystem erwei­ tert werden kann zu einem Mehrbenutzersystem ist beispiels­ weise beschrieben in [3], [4], [5].

Die daraus resultierende Situation mit einer zusätzliche Mul­ tiplexerkomponente ASC und mehreren Benutzereinheiten XSi, wobei ein Index i jede Benutzereinheit XSi eindeutig identi­ fiziert und eine natürliche Zahl im Bereich von 1 bis n ist, ist in Fig. 2 dargestellt.

Hierbei werden in bekannter Weise die Anforderungen Ai von den einzelnen Benutzereinheiten XSi zusammengeführt und die Nachricht B wird an die einzelnen Benutzereinheiten XSi als Kopien der Nachricht Bi gesendet.

Die erfindungsgemäßen Verfahren werden in diesem Zusammenhang natürlich für jede einzelne Verbindung zwischen dem Klienten XC und jeder Benutzereinheit XSi einzeln durchgeführt.

Detaillierter ist diese "Mehrbenutzer-Umgebung" noch in Fig. 3 dargestellt. In dieser Realisierung entsprechen die Anfor­ derungen Ai sogenannten Xrequests und die Nachrichten Bi den sogenannten Xreplies, Xevents, Xerrors. Die Anwendung ANW greift über Systemaufrufe SC auf Systemressourcen SR zu.

In einer Weiterbildung des Verfahrens ist es vorteilhaft, zu Beginn des Verfahrens eine Initialisierungsphase vorzusehen, in der beispielsweise ein Schlüsselaustausch sowie eine beid­ seitige Authentikation zwischen einer Benutzereinheit XS der Benutzereinheiten XSi und dem Programm P durchgeführt wird.

Hierbei sind dem Fachmann unterschiedlichste Verfahren zum Schlüsselaustausch bekannt. Als Beispiel einer Initialisie­ rungsphase, die in dem erfindungsgemäßen Verfahren eingesetzt werden kann, wird folgendes Vorgehen vorgeschlagen.

Das im folgende beschriebene Verfahren zum Schlüsselaustausch wird allgemein zwischen dem Klienten XC und einer Benut­ zereinheit XS durchgeführt. Die Multiplexerkomponente ASC ist in diesem Zusammenhang als eine spezielle Komponente des Kli­ enten XC zu betrachten.

Unter der Annahme, daß die Multiplexerkomponente ASC ein An­ wendungszertifikat besitzt und die Benutzereinheiten, also die Server XSi, jeweils ein Benutzerzertifikat besitzen, die jeweils eindeutig den Benutzereinheiten zugeordnet sind, wird dann von der Multiplexerkomponente ASC eine erste Zufallszahl erzeugt.

Nachdem eine Transportverbindung zwischen der Multiplexerkom­ ponente ASC und dem jeweiligen Server XSi aufgebaut wurde, wird von der Multiplexerkomponente ASC eine erste Verhand­ lungsnachricht an die Benutzereinheit gesendet, die minde­ stens folgende Komponenten aufweist:

• - das Programmzertifikat,
• - die erste Zufallszahl,
• - einen ersten Vorschlag für ein im weiteren zu verwendende kryptographische Verfahren, und
• - eine digitale Unterschrift, die mindestens über die erste Zufallszahl sowie den ersten Vorschlag gebildet wird.

Die erste Verhandlungsnachricht wird von der jeweiligen Be­ nutzereinheit, also dem Server XSi, empfangen.

Von der Benutzereinheit XSi wird das Programmzertifikat auf Korrektheit überprüft.

Ferner wird die digitale Unterschrift überprüft.

Falls die Überprüfung des Programmzertifikats und der digita­ len Unterschrift ein positives Ergebnis liefert, wird in der Benutzereinheit XSi weiterhin überprüft, ob die vorgeschlage­ nen kryptographischen Algorithmen die in der ersten Verhand­ lungsnachricht vorgeschlagen wurden, im weiteren zur Siche­ rung der Übertragung verwendet werden können.

Wenn die Benutzereinheit XSi die vorgeschlagenen kryptogra­ phischen Algorithmen nicht unterstützen kann, wird von der Benutzereinheit, also dem Server XSi, ein zweiter Vorschlag in einer zweiten Vorschlagsnachricht gebildet und an die Mul­ tiplexerkomponente ASC gesendet. Der zweite Vorschlag weist kryptographische Verfahren auf, die die Benutzereinheit XSi unterstützt. Diese werden nunmehr der Multiplexerkomponente ASC als im weiteren Verfahren zu verwendende kryptographische Verfahren für diese logische Verbindung zwischen der Multi­ plexerkomponente und der Benutzereinheit XSi vorgeschlagen.

Die zweite Vorschlagsnachricht weist mindestens folgende Kom­ ponenten auf:

• - das Benutzerzertifikat des jeweiligen Servers XSi,
• - eine zweite Zufallszahl, die von der Benutzereinheit XSi selbst erzeugt wurde,
• - den zweiten Vorschlag,
• - eine digitale Unterschrift, die jeweils mindestens über die erste Zufallszahl, die zweite Zufallszahl sowie den zweiten Vorschlag gebildet werden.

Die zweite Vorschlagsnachricht wird an die Multiplexerkompo­ nente ASC gesendet.

Für den Fall, daß die in dem ersten Vorschlag angegebenen kryptographischen Algorithmen von dem Benutzereinheit XSi un­ terstützt werden, wird von dem Benutzereinheit XSi eine Be­ stätigungsnachricht gebildet und an die Multiplexerkomponente ASC gesendet.

Die Bestätigungsnachricht weist mindestens folgende Komponen­ ten auf:

• - das Benutzerzertifikat,
• - die zweite Zufallszahl,
• - eine positive Bestätigung, und
• - eine digitale Unterschrift, die jeweils mindestens über die erste Zufallszahl, die zweite Zufallszahl, und die positive Bestätigung gebildet werden.

Die Bestätigungsnachricht wird an die Multiplexerkomponente ASC gesendet.

Von der Multiplexerkomponente ASC wird die Verhandlungsnach­ richt oder die Bestätigungsnachricht empfangen und es wird in der Multiplexerkomponente ASC geprüft, ob das Benutzerzerti­ fikat sowie die digitale Unterschrift korrekt sind.

Weiterhin wird von der Multiplexerkomponente ASC für den Fall, daß die Überprüfung ein positives Ergebnis liefert und die empfangene Nachricht die Bestätigungsnachricht war, ein erster Sitzungsschlüssel unter Berücksichtigung der verein­ barten kryptographischen Algorithmen für eine folgende Nutz­ datenübertragungsphase erzeugt.

Aus dem ersten Sitzungsschlüssel wird eine erste Sitzungs­ schlüsselnachricht gebildet und an die Benutzereinheit XSi gesendet, die mindestens folgende Komponenten aufweist:

• - den mit einem öffentlichen Schlüssel des Servers XSi ver­ schlüsselten ersten Sitzungsschlüssel,
• - eine Spezifikation der zu verwendenden kryptographischen Verfahren,
• - eine mindestens über die erste Zufallszahl, die zweite Zu­ fallszahl, den ersten Sitzungsschlüssel gebildete digitale Unterschrift sowie die Spezifikation der zu verwendenden kryptographischen Verfahren.

Wurde von der Multiplexerkomponente ASC die zweite Verhand­ lungsnachricht empfangen, und die Überprüfung des Benutzer­ zertifikats und der digitalen Unterschrift oder des Hash-Werts der zweiten Verhandlungsnachricht hat ein positives Er­ gebnis geliefert, wird in der Multiplexerkomponente ASC ge­ prüft, ob die in der zweiten Verhandlungsnachricht vorge­ schlagenen kryptographischen Algorithmen zur Durchführung der weiteren kryptographischen Verfahren von der Multiplexerkom­ ponente ASC unterstützt werden.

Werden die vorgeschlagenen kryptographischen Verfahren von der Multiplexerkomponente ASC unterstützt, wird ein erster Sitzungsschlüssel unter Berücksichtigung der vereinbarten kryptographischen Algorithmen für die folgende Nutzdatenüber­ tragungsphase erzeugt.

Weiterhin wird, wie im vorigen beschrieben wurde, eine erste Sitzungsschlüsselnachricht unter Verwendung des ersten Sit­ zungsschlüssels an die Multiplexerkomponente ASC gesendet.

Diese im vorigen beschriebene Vorgehensweise zum "Aushandeln" der zu verwendenden kryptographischen Verfahren wird solange wiederholt, bis sowohl die Benutzereinheit XSi als auch die Multiplexerkomponente ASC zuletzt vorgeschlagenen kryptogra­ phischen Verfahren akzeptieren.

In der Benutzereinheit XSi wird der erste Sitzungsschlüssel unter Verwendung eines privaten Schlüssels der Benutzerein­ heit XSi ermittelt. Ferner wird die digitale Unterschrift der ersten Sitzungsschlüsselnachricht überprüft.

Außerdem wird für den Fall, daß die Überprüfung der digitalen Unterschrift ein positives Ergebnis lieferte, eine zweite Sitzungsschlüsselnachricht gebildet unter Verwendung eines zweiten Sitzungsschlüssels, der von der Benutzereinheit XSi gebildet wird.

Die zweite Sitzungsschlüsselnachricht weist mindestens fol­ gende Komponenten auf:

• - den mit einem öffentlichen Programmschlüssel der Multiple­ xerkomponente ASC verschlüsselten zweiten Sitzungsschlüs­ sel, und
• - eine mindestens über die erste Zufallszahl, die zweite Zu­ fallszahl, den zweiten Sitzungsschlüssel gebildete Digitale Unterschrift oder einen über dieselben Komponenten gebilde­ ten Hash-Wert.

Von der Multiplexerkomponente ASC wird die zweite Sitzungs­ schlüsselnachricht empfangen und der zweite Sitzungsschlüssel ermittelt. Die digitale Unterschrift oder der Hash-Wert der zweiten Sitzungsschlüsselnachricht wird überprüft.

Lieferte die Prüfung der digitalen Unterschrift ein positives Ergebnis, werden die ausgetauschten Sitzungsschlüssel in der folgenden Nutzdatenübertragungsphase zur Verschlüsselung der Nutzdaten verwendet. Dabei verwendet jede beteiligte Instanz den Sitzungsschlüssel, der von ihr selbst generiert wurde zum Senden von Nutzdaten, während der empfangene Sitzungsschlüs­ sel ausschließlich zum Empfangen von Nutzdaten verwendet wird.

Weitere kryptographische Verfahren zum Schlüsselaustausch bzw. zur Bildung des Sitzungsschlüssels für die Nutzdatenver­ schlüsselung sind im Rahmen des erfindungsgemäßen Verfahrens ohne Einschränkungen einsetzbar.

Die erfindungsgemäßen Verfahren können sehr vorteilhaft in folgendem Szenario eingesetzt werden.

In vielen privaten Netzen werden zwischen vernetzten Rechnern sehr vertrauliche Informationen untereinander ausgetauscht. Hierbei ist meistens das private Netz selbst sehr gut abgesi­ chert gegen die Außenwelt, beispielsweise durch sogenannte Firewalls [6].

Wenn nun ein an das jeweils abgesicherte private Netz ange­ schlossene Rechner mit einem sich außerhalb dieses Netzes, nur über einen unsicheren Kanal erreichbaren Rechner kommuni­ zieren möchte, beispielsweise einem nur über das Internet IN erreichbaren Rechner, besteht bisher ein großes Problem dar­ in, daß bei dem auf [1] basierenden Client-Server-Fenster-Systemen keine sichere Kommunikation möglich ist.

Insbesondere ergibt sich das Problem, daß über Fensterdienst­ programme andere Anwendungen angegriffen werden können. Um das Ausspähen interner Informationen zu verhindern, ist es in Firmennetzen in der Regel nicht erlaubt, ein Fensterdienst­ programm außerhalb des Firmennetzes zu betreiben. Diese all­ gemein übliche Beschränkung behindert insbesondere synchrone CSCW-Systeme, die auf Application Sharing beruhen.

Diese Probleme sind beispielsweise in [6], [7] ausführlich geschildert.

Es muß sich bei diesem Problem nicht unbedingt um eine über ein lokales Netz übergreifende Kommunikation handeln, sondern es kann sich beispielsweise auch um ein abgesichertes Corpo­ rate Network CN handeln, bei dem ein Kommunikationspartner mit einem anderen Kommunikationspartner einer anderen Firma über den Rechner beispielsweise in einem CSCW-System kommuni­ zieren möchte.

Durch die erfindungsgemäßen Verfahren ist es nunmehr möglich, bei Einsätzen dieser Verfahren in einem Firewall SC1, SC2 des lokalen Netzes bzw. des Corporate Networks CN, wobei eben der Firewall jeweils als erste Sicherungscomputereinheit SC1 bzw. als zweite Sicherungscomputereinheit SC2 anzusehen ist (vgl. Fig. 3).

In dieser Schrift wurden folgende Veröffentlichungen zitiert:
[1] R. Scheifler et al, The X Window System, ACM Transactions on Graphics, Vol. 5, No. 2, S. 79 bis 109, April 1986
[2] S. Garfinkel et al, Practical UNIX Security, O′Reilly & Associates, Inc., ISBN 0-937175-72-2, S. 221-253, 1991
[3] H. Abdel-Wahab et al, Issues, Problems and Solutions in Sharing X Clients on Multiple Displays, Internetworking: Re­ search and Experience, Vol. 5, S. 1 bis 15, 1994
[6] D. Garfinkel et al, HP Shared X: A Tool for Real-Time Collaboration, Hewlett-Packard Journal, S. 23 bis 36, April 1994
[5] J. Baldeschwieler et al, A Survey of X Protocol Multi­ plexors, Swiss Federal Institute of Technology, Computer Engi­ neering and Networks Laboratory (TIK), ETH-Zentrum, Zürich, 1993
[6] S. Bellovin et al, Network Firewalls, IEEE Communications Magazin, S. 50 bis 57, September 1994
[7] G. Treese et al, X Through the Firewall, and Other Appli­ cation Relays, Summer Usenix, 1993, 21. bis 25. Juni, Cincin­ nati, S. 87 bis 98, 1993

Claims (11)

1. Verfahren zur kryptographischen Sicherung der rechnerge­ stützten digitalen Kommunikation zwischen einem Programm (P) und mindestens einer Benutzereinheit (XSi),

• - bei dem von dem Programm (P) eine Nachricht (B) gebildet wird (601)
• - bei dem von einer Rechnereinheit, auf der das Programm (P) verarbeitet wird, oder von einer ersten Sicherungscompu­ tereinheit (SC1) die Nachricht (B) mit einem Transportproto­ koll codiert (CB) wird (602),
• - bei dem die codierte Nachricht (CB) unter Verwendung des Transportprotokolls decodiert (DB) wird (603),
• - bei dem die decodierte Nachricht (DB) einem kryptographi­ schen Verfahren (VB) unterzogen wird (604),
• - bei dem die kryptographisch bearbeitete Nachricht (VB) mit dem Transportprotokoll codiert (CVB) wird (605), und
• - bei dem die codierte kryptographisch bearbeitete Nachricht (CVB) an die mindestens eine Benutzereinheit (XSi) übertragen wird (606)
• 2. Verfahren nach Anspruch 1,
• - bei dem die codierte kryptographisch bearbeitete Nachricht (CVB) von der mindestens einen Benutzereinheit (XSi) oder von einer zweiten Sicherungscomputereinheit (SC2) empfangen wird (701),
• - bei dem unter Verwendung des Transportprotokolls die codier­ te kryptographisch bearbeitete Nachricht (CVB) decodiert (DVB) wird (702),
• - bei dem die decodierte kryptographisch bearbeitete Nach­ richt (DVB) einer zu dem kryptographischen Verfahren inversen kryptographischen Bearbeitung (DEB) unterzogen wird (703),
• - bei dem die invers kryptographisch bearbeitete Nachricht (DEB) mit dem, Transportprotokoll codiert (CEB) wird (704), und
• - bei dem die codierte invers kryptographisch bearbeitete Nachricht (CEB) unter Verwendung des Transportprotokolls deco­ diert wird (705).

3. Verfahren nach Anspruch 1,

• - bei dem die codierte kryptographisch bearbeitete Nachricht (CVB) von der mindestens einen Benutzereinheit (XSi) empfan­ gen wird,
• - bei dem unter Verwendung des Transportprotokolls die codier­ te kryptographisch bearbeitete Nachricht (CVB) decodiert (DVB) wird, und
• - bei dem die decodierte kryptographisch bearbeitete Nach­ richt (DVB) einer zu dem kryptographischen Verfahren inversen kryptographischen Bearbeitung (DEB) unterzogen wird.

4. Verfahren zur kryptographischen Sicherung der rechnerge­ stützten digitalen Kommunikation zwischen einem Programm (P) und mindestens einer Benutzereinheit (XSi),

• - bei dem von einer Benutzereinheit (XSi) eine Anforderung (A) gebildet wird (901),
• - bei dem von der Benutzereinheit (XSi) oder von einer zwei­ ten Sicherungscomputereinheit (SC2) die Anforderung (A) mit einem Transportprotokoll codiert (CA) wird (902),
• - bei dem die codierte Anforderung (CA) unter Verwendung des Transportprotokolls decodiert (DA) wird (903),
• - bei dem die decodierte Anforderung (DA) einem kryptographi­ schen Verfahren (VA) unterzogen wird (904),
• - bei dem die kryptographisch bearbeitete Anforderung (VA) mit dem Transportprotokoll codiert (CVA) wird (905), und
• - bei dem die codierte kryptographisch bearbeitete Anforde­ rung (CVA) an das Programm (P) übertragen wird (906).

5. Verfahren nach Anspruch 4,

• - bei dem die codierte kryptographisch bearbeitete Anforde­ rung (CVA) von dem Programm (P) oder von einer ersten Siche­ rungscomputereinheit (SC1) empfangen wird (1001),
• - bei dem unter Verwendung des Transportprotokolls die codier­ te kryptographisch bearbeitete Anforderung (CVA) decodiert (DVA) wird (1002),
• - bei dem die decodierte kryptographisch bearbeitete Anforde­ rung (DVA) einer zu dem kryptographischen Verfahren inversen kryptographischen Bearbeitung (DEA) unterzogen wird (1003), - bei dem die invers kryptographisch bearbeitete Anforderung (DEA) mit dem Transportprotokoll codiert (CEA) wird (1004), und
• - bei dem die codierte invers kryptographisch bearbeitete An­ forderung (CEA) unter Verwendung des Transportprotokolls deco­ diert wird (1005).

6. Verfahren nach Anspruch 4,

• - bei dem die codierte kryptographisch bearbeitete Anforde­ rung (CVA) von dem Programm (P) empfangen wird,
• - bei dem unter Verwendung des Transportprotokolls die codier­ te kryptographisch bearbeitete Anforderung (CVA) decodiert (DVA) wird, und
• - bei dem die decodierte kryptographisch bearbeitete Anforde­ rung (DVA) einer zu dem kryptographischen Verfahren inversen kryptographischen Bearbeitung (DEA) unterzogen wird.

7. Verfahren zur kryptographischen Sicherung der rechnerge­ stützten digitalen Kommunikation zwischen einem Programm (P) und mindestens einer Benutzereinheit (XSi),

• - bei dem von dem Programm (P) eine Nachricht (B) gebildet wird (1101),
• - bei dem die Nachricht (B) einem kryptographischen Verfahren (VB) unterzogen wird (1102),
• - bei dem die kryptographisch bearbeitete Nachricht (VB) mit dem Transportprotokoll codiert (CVB) wird (1103),
• - bei dem die codierte kryptographisch bearbeitete Nachricht (CVB) an die mindestens eine Benutzereinheit (XSi) übertragen wird (1104),
• - bei dem die codierte kryptographisch bearbeitete Nachricht (CVB) von der mindestens einen Benutzereinheit (XSi) oder von einer zweiten Sicherungscomputereinheit (SC2) empfangen wird (1105),
• - bei dem unter Verwendung des Transportprotokolls die codier­ te kryptographisch bearbeitete Nachricht (CVB) decodiert (DVB) wird (1106)
• - bei dem die decodierte kryptographisch bearbeitete Nach­ richt (DVB) einer zu dem kryptographischen Verfahren inversen kryptographischen Bearbeitung (DEB) unterzogen wird (1107),
• - bei dem die invers kryptographisch bearbeitete Nachricht (DEB) mit dem Transportprotokoll codiert (CEB) wird (1108), und
• - bei dem die codierte invers kryptographisch bearbeitete Nachricht (CEB) unter Verwendung des Transportprotokolls deco­ diert wird (1109).

8. Verfahren zur kryptographischen Sicherung der rechnerge­ stützten digitalen Kommunikation zwischen einem Programm (P) und mindestens einer Benutzereinheit (XSi),

• - bei dem von der mindestens einen Benutzereinheit (XSi) eine Anforderung (A) gebildet wird (1201),
• - bei dem die decodierte Anforderung (DA) einem kryptographi­ schen Verfahren (VA) unterzogen wird (1202),
• - bei dem von der Benutzereinheit (XSi) oder von einer zwei­ ten Sicherungscomputereinheit (SC2) die kryptographisch bear­ beitete Anforderung (A) mit einem Transportprotokoll codiert (CA) wird (1203),
• - bei dem die codierte kryptographisch bearbeitete Anforde­ rung (CVA) an das Programm (P) übertragen wird (1204),
• - bei dem die codierte kryptographisch bearbeitete Anforde­ rung (CVA) von dem Programm (P) oder von einer ersten Siche­ rungscomputereinheit (SC1) empfangen wird (1205),
• - bei dem unter Verwendung des Transportprotokolls die codier­ te kryptographisch bearbeitete Anforderung (CVA) decodiert (DVA) wird (1206),
• - bei dem die decodierte kryptographisch bearbeitete Anforde­ rung (DVA) einer zu dem kryptographischen Verfahren inversen kryptographischen Bearbeitung (DEA) unterzogen wird (1207),
• - bei dem die invers kryptographisch bearbeitete Anforderung (DEA) mit dem Transportprotokoll codiert (CEA) wird (1208), und
• - bei dem die codierte invers kryptographisch bearbeitete An­ forderung (CEA) unter Verwendung des Transportprotokolls deco­ diert wird (1209).

9. Verfahren nach einem der Ansprüche 1 bis 8,

• - bei dem die kryptographische Bearbeitung mindestens durch eine Verschlüsselung der Anforderung (Ai) realisiert ist (81), und
• - bei dem die inverse kryptographische Bearbeitung mindestens durch eine Entschlüsselung der Anforderung (Ai) realisiert ist.

10. Verfahren nach einem der Ansprüche 1 bis 9,

• - bei dem die kryptographische Bearbeitung mindestens durch Authentikationsmechanismen für die Anforderung (Ai) reali­ siert ist (82), und
• - bei dem die inverse kryptographische Bearbeitung mindestens durch inverse Authentikationsmechanismen für die Anforderung (Ai) realisiert ist.

11. Verfahren nach einem der Ansprüche 1 bis 10,

• - bei dem die kryptographische Bearbeitung mindestens durch Zugriffskontrollmechanismen für die Anforderung (Ai) reali­ siert ist (83), und
• - bei dem die inverse kryptographische Bearbeitung mindestens durch inverse Zugriffskontrollmechanismen für die Anforderung (Ai) realisiert ist.

12. Verfahren nach einem der Ansprüche 1 bis 11, bei dem zu Beginn des Verfahrens eine kryptographische In­ itialisierungsphase mit Bildung eines Sitzungsschlüssels für jede Verbindung einer Benutzereinheit (XSi) mit dem Programm (P) durchgeführt wird.