DE19548397C1 - Verfahren zur Zugriffskontrolle auf rechnerkontrollierte Programme, die von mehreren Benutzereinheiten gleichzeitig genutzt werden können - Google Patents

Description

Durch ein sogenanntes "Sharing" von rechnerkontrollierten Programmen können Standard-Ein-Benutzer-Anwendungen (Programme) in rechnergestützte Konferenzen eingebracht wer­ den. Die an der Konferenz beteiligten Personen, die sich an verschiedenen Standorten befinden können, können dadurch ge­ meinsam mit der Standard-Ein-Benutzer-Anwendung arbeiten. Die Ausgaben der jeweiligen gemeinsam genutzten Anwendung können alle Beteiligten beobachten. Genau einer der beteiligten Per­ sonen kann zu jedem Zeitpunkt Eingaben an die Anwendung ma­ chen.

Diese technische Konstruktion zur Anwendungsverteilung ist die Basis von informationstechnischen Systemen zur Unterstüt­ zung synchroner Kollaboration geographisch verteilter Perso­ nen.

Bei der technischen Umsetzung des "Sharing" von Anwendungen gibt es bislang zwei verschiedene Rollen für die Anwender. Es handelt sich dabei zum einen um den sogenannten "Token Hol­ der", womit diejenige Person bezeichnet wird, die zu dem je­ weiligen Zeitpunkt das Recht hat, Eingaben für die Anwendung zu machen, und zum anderen um die sogenannten "Observer", wo­ mit die anderen an der Konferenz beteiligten Personen be­ zeichnet werden, welche die Ausgabe der Anwendung zwar beob­ achten können, jedoch zu dem jeweiligen Zeitpunkt kein Recht haben, eine Eingabe für die Anwendung zu machen.

Die Rolle des "Token Holder" ist zeitabhängig. Sie kann wäh­ rend einer Konferenz zwischen den Beteiligten wechseln, je­ doch gibt es zu jedem Zeitpunkt immer genau einen "Token Hol­ der". Dies bedeutet, daß zu jedem Zeitpunkt immer genau nur eine Person das Recht hat, Eingaben für die Anwendung zu ma­ chen. Durch diese technische Lösung arbeitet jeder "Token Holder" unter den Privilegien und mit den Zugriffsrechten des Besitzers der Anwendung, also unter den Rechten desjenigen Benutzers, der die Anwendung gestartet hat. Somit kann der "Token Holder" mit der Anwendung genau die Operationen aus­ führen, zu denen der Besitzer der Anwendung berechtigt ist. Damit ist auch der "Token Holder" nicht mehr von dem eigent­ lichen Besitzer der Anwendung unterscheidbar. Für die Anwen­ dung ist nicht erkennbar, daß verschiedene Personen mit ihr arbeiten und ebensowenig, wer zu einem bestimmten Zeitpunkt mit ihr arbeitet. Gewissermaßen wird der jeweilige "Token Holder" durch die existierenden technischen Konstruktionen der "Sharing-Systeme" zu einer Personifikation des Anwen­ dungsbesitzers.

Diese Vorgehensweise birgt große Sicherheitsrisiken in sich, da der "Token Holder" dadurch z. B. Zugriff auf das gesamte Dateisystem des Besitzers der Anwendung hat, wenn die Anwen­ dung beispielsweise ein Textverarbeitungsprogramm mit ent­ sprechender Funktionalität ist. In diesem Fall könnte der "Token Holder" Dateien unerlaubterweise löschen, verändern, lesen oder kopieren, ohne daß der Besitzer der Anwendung un­ bedingt davon Kenntnis nehmen muß.

Fenster-Systeme werden zur Zeit in zwei bekannte Kategorien unterteilt je nach Operations- und Betriebsart, die diese Fenster-Systeme verwenden.

Zum einen sind dies sogenannte Client-Server-Fenster-Systeme mit einer offenen Netzschnittstelle (R. Scheifler et al, The X-Window-System, ACM Transactions on Graphics, Vol. 5, No. 2, S. 79-109, April 1986), zum anderen solche ohne offene Netzschnittstelle. Letztere sind auch als monolithische gra­ phikbasierte Fenster-Systeme GDWS bekannt (Microsoft Windows 3.1 Programmer′s Reference, Volume 1: Overview, Microsoft Press, Redmond, ISBN 1-55615-453-4, 1992; R. Orfali et al, Client/Server Programming with OS/2, Van Nostrand Reinhold, New York, ISBN 0-442-01833-9, 1993; Inside Macintosh, Volume VI, Addison Wesley, ISBN 0-201-57755-0, 1991).

Weiterhin sind auch Erweiterungen, die die Fenster-Systeme zu einem "Sharing"-fähigen Fenster-System machen, bekannt

• (H. Abdel-Wahab et al, Issues, Problems and Solutions in Sharing X Clients on Multiple Displays, Internetworking: Research and Experience, Vol. 5, S. 1-15, 1994;
• D. Garfinkel et al, HP Shared X: A Tool for Real-Time Colla­ boration, Hewlett-Packard Journal, S. 23-36, April 1994;
• W. Minenko, Transparentes Application-Sharing unter X Window, Multimediale Telekooperation, Deutsches Forschungszentrum für Künstliche Intelligenz (DFKI) GmbH, Saarbrücken, S. 1-8, 1994;
• J. Baldeschwieler et al, A Survey on X Protocol Multiplexors, ACM SIGCOMM, Computer Communication Review, Swiss Federal In­ stitute of Technology, Computer Engineering and Networks La­ boratory (TIK), ETH-Zentrum, Zürich, S. 16-24, 1993,
• U. Pech, Sichtlich beeindruckt, PC Professionell, S. 71-88, Oktober 1995;
• E. Chang et al, Group Coordination in Participant Systems, IEEE, Proceedings of the 24th Annual Hawaii International Conference on System Sciences, Vol. 3, No. 4, Kauai, HI, S. 589-599, Januar 1991;
• A. Nakajima, A Telepointing Tool for Distributed Meeting Sy­ stems, IEEE Global Telecommunications Conference and Exhibi­ tion, Vol. 1, No. 3, San Diego, CA, S. 76-80, Dezember 1990;
• J. Patterson, The Implications of Window Sharing for a Virtu­ al Terminal Protocol, IEEE International Conference on Commu­ nications, Vol. 1, No. 4, Atlanta, GA, S. 66-70, April 1990;
• G. Herter, Intel ProShare, Accounting Technology, Vol. 11, No. 1, S. 49-54, Januar 1995;
• D. Riexinger et al, Integration of Existing Applications into a Conference System, Proceedings of International Conference on Multimedia Transport and Teleservices Vienna, S. 346-355, November 1994).

Ferner ist eine Sicherheitserweiterung für von mehreren Be­ nutzern gemeinsam nutzbare Ein-Benutzer-Anwendungen bekannt (G. Gahse, "Zugriffskontrolle in Konferenzsystemen", IBM Deutschland Informationssysteme GmbH, Europäisches Zentrum für Netzwerkforschung, Heidelberg, 1995).

Das bisher bekannte Verfahren zur Erweiterung der Sicherheit von Ein-Benutzer-Anwendungen in Konferenzsystemen beschreibt ein Zugriffskontrollverfahren, bei dem eine Ein-Benutzer- Anwendung, die von mehreren Benutzern gemeinsam genutzt wer­ den soll, unter spezifischen "Sharing-Privilegien" abläuft. Bei diesem Verfahren wird den Benutzern eine gemeinsame, neue temporäre Identität für den Zeitraum der Kollaboration zuge­ teilt. Dieser gemeinsamen, temporären Identität werden Zu­ griffsrechte zugeordnet ("Sharing"-Privilegien), wodurch die ursprünglichen Rechte zurückgesetzt werden können. Damit kann z. B. keiner der Konferenzteilnehmer bei der Nutzung der An­ wendung unberechtigt auf Daten des lokalen Systems zugreifen.

Ein wesentlicher Nachteil, der in dem bekannten Verfahren zu sehen ist, besteht darin, daß der vorgeschlagene Zugriffskon­ trollmechanismus nicht die verschiedenen Benutzer bei der Zu­ teilung von angeforderten Ressourcen berücksichtigt, und so­ mit keine Unterscheidung zwischen dem "Token Holder" und dem Besitzer der Applikation möglich ist.

Eine Hauptursache für bei diesem Verfahren noch immer beste­ hende Sicherheitsrisiken liegt darin, daß bei diesem Verfah­ ren noch immer mehrere Personen, z. B. der Systemadministra­ tor, oder auch andere Benutzer, die in einer bestimmten "Berechtigungsdatei" angegeben sind, die Rechte der anderen Benutzer für eine Anwendung setzen können. Durch diese Vorge­ hensweise können auch weiterhin andere Benutzer als der ei­ gentliche Besitzer der Anwendung beispielsweise über das Da­ teisystem des Besitzers der Anwendung "bestimmen". Diese Vor­ aussetzung der Vertrauenswürdigkeit der Benutzer, die die Rechte für Anwendungen verteilen, stellt ein erhebliches Si­ cherheitsrisiko dar.

Der Erfindung liegt das Problem zugrunde, ein Verfahren zur Zugriffskontrolle auf rechnerkontrollierte Programme, die von mehreren Benutzereinheiten gleichzeitig benutzt werden kön­ nen, anzugeben, das die im vorigen beschriebenen Sicherheits­ risiken vermeidet.

Dieses Problem wird durch das Verfahren gemäß Patentanspruch 1 gelöst.

Bei diesem Verfahren wird explizit zwischen dem Besitzer der Anwendung, also demjenigen Benutzer, der die Anwendung ge­ startet hat, dem jeweiligen "Token Holder" und allen anderen Benutzern unterschieden. Der Besitzer einer Anwendung (Programm) erstellt eine Zugriffskontrolldatenbank, in der er auf der Basis der Identitäten der anderen Benutzer sowie der Art der Anforderung, die von den Benutzern gesendet werden, auf die eigene Anwendung bestimmen kann, ob die Anforderung des jeweiligen Benutzers erlaubt sein soll oder ob die Anfor­ derung zurückgewiesen wird.

In dem Verfahren wird eine empfangene Anforderung für eine Anwendung (Programm und Menge von Bibliotheksroutinen), die von mehreren Benutzereinheiten gleichzeitig genutzt werden kann, von einem Mittel zur Organisation des Datenflusses (sogenannte Multiplexerkomponente) empfangen und daraufhin überprüft, ob die Anforderung von der Benutzereinheit gesen­ det wurde, die das Programm ursprünglich gestartet hatte.

Falls dies der Fall ist und falls der Anwendungsbesitzer zu dem betreffenden Zeitpunkt das Eingaberecht besitzt, wird die Anforderung direkt an das Programm weitergeleitet.

Anderenfalls wird für die Anforderung anhand der von dem Be­ sitzer der Anwendung erstellten Zugriffskontrolldatenbank ei­ ne Zugriffskontrolle durchgeführt. Durch die Zugriffskontrol­ le wird erreicht, daß nur explizit von dem Besitzer der An­ wendung "genehmigte" Anforderungen an das Programm weiterge­ leitet werden.

Durch diese zusätzliche Zugriffskontrolle wird die Sicherheit des "Sharings" von Anwendungen in Konferenzsystemen erheblich erhöht.

Durch die Weiterbildung des Verfahrens gemäß Patentanspruch 2 wird das Verfahren vereinfacht, indem vor der Kontrolle, ob die Benutzereinheit das Programm ursprünglich gestartet hat­ te, überprüft wird, ob die Benutzereinheit, die die Anforde­ rung gesendet hatte, überhaupt ein Bearbeitungsrecht besaß, d. h. ob diese Benutzereinheit "Token Holder" war. Falls dies zu dem Sendezeitpunkt nicht der Fall war, wird die Anforde­ rung gar nicht erst den weiteren Verfahrensschritten, die der Patentanspruch 1 aufweist, zugeführt.

Damit wird die Zugriffskontrolle für Anforderungen, die von Benutzern gesendet wurden, die zu dem jeweiligen Zeitpunkt des Sendens der Anforderung nicht "Token Holder" waren, ver­ mieden, wodurch erhebliche Rechenzeiteinsparungen erzielt werden, da die Zugriffskontrolle nicht mehr für alle von dem Mittel zur Organisation des Datenflusses (Multiplexereinheit) empfangenen Anforderungen durchgeführt werden muß.

Durch die Weiterbildung des Verfahrens gemäß Patentanspruch 3 wird durch eine Authentikation der Benutzereinheit, die die Anforderung gesendet hat und/oder der Anforderung selbst die Sicherheit des Verfahrens weiter erhöht.

Weiterbildungen des erfindungsgemäßen Verfahrens ergeben sich aus den abhängigen Ansprüchen.

Im folgenden wird die Erfindung anhand von Zeichnungen, die zwei Ausführungsbeispiele des erfindungsgemäßen Verfahrens darstellen, näher erläutert.

Es zeigen

Fig. 1 eine prinzipielle Anordnung von Ressourcen, die ein Fenster-System eines ersten Ausführungsbeispiels verwenden, welches erweiterbar ist auf ein Fenster-System, in dem Anwendungen von mehreren Benutzern gleichzeitig genutzt werden können;

Fig. 2 eine prinzipielle Anordnung einer Erweiterung der in Fig. 1 beschriebenen Ressourcen, wodurch die gleichzeitige Nutzung einer Anwendung durch mehrere Benutzer möglich ist;

Fig. 3 ein Ablaufdiagramm, in dem einzelne Verfahrensschrit­ te des erfindungsgemäßen Verfahrens dargestellt sind;

Fig. 4 ein Ablaufdiagramm, in dem eine Weiterbildung durch eine Authentikation der Anforderung und/oder des Senders der Anforderung durchgeführt wird;

Fig. 5 ein Ablaufdiagramm, in dem eine Weiterbildung des Verfahrens beschrieben ist, bei dem zu Beginn des Verfahrens überprüft wird, ob die die Anforderung sendende Benutzereinheit zu dem Sendezeitpunkt ein Bearbeitungsrecht für die Anwendung besitzt;

Fig. 6 ein Struktugramm, in dem die Information dargestellt ist, die in einer Zugriffskontrolldatenbank minde­ stens enthalten sein sollte;

Fig. 7 eine Anordnung, in der die nötige Sicherheitserweite­ rung der in Fig. 2 beschriebenen Anordnung durch eine Zugriffskontrolldatenbank dargestellt ist.

Fig. 8 eine prinzipielle Anordnung von Ressourcen, die ein monolithisches, graphikbasiertes Fenster-System eines zweiten Ausführungsbeispiels verwenden, welches erweiterbar ist auf ein monolithisches, graphikbasiertes Fenster-System, in dem Anwendungen von mehreren Benutzern gleichzeitig genutzt werden können.

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

In Fig. 1 ist zur Erläuterung eines ersten Ausführungsbei­ spiels eine Anordnung dargestellt, in der einzelne Komponen­ ten (Ressourcen) beschrieben sind, die ein bekanntes, in (R. Scheifler et al, The X Window System, ACM Transactions on Graphics, Vol. 5, No. 2, S. 79-109, April 1986) beschriebe­ nes Fenster-System nutzen.

Diese Anordnung weist mindestens folgende Komponenten auf:

• - Eine Benutzereinheit, im weitern als Server XS bezeichnet, die wiederum folgende Komponenten aufweist:
  • - mindestens eine Treibereinheit DD, die eine Kopplung zwischen 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 und
  • - 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 dem bekannten, oben beschriebenen Fenster-System und der Anwendung ANW.

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 na­ türlich mehrere Anwendungen ANW und damit mehrere Klienten XC auf einer, diese Anwendungen ANW ausführenden Rechnereinheit 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 Fenster-System durchgeführt wird.

Von dem Server XS wird eine Anforderung A an den Klienten XC gesendet, wodurch in dem Klienten XC Aktionen, beispielsweise in der Anwendung ANW, angestoßen werden. Diese Anforderung kann z. B. eine Eingabe auf der Tastatur TA repräsentieren, die durch die Treibereinheiten DD in die Anforderung A "übersetzt" und an den Klienten XC gesendet wird.

Die Anwendung ANW, beispielsweise ein Textverarbeitungspro­ gramm oder auch ein Kalkulationsprogramm, ein Zeichenprogramm und ähnliche Programme, kann nun die Eingabe akzeptieren und beispielsweise als neuer Buchstabe in der Textdatei aufneh­ men.

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

In Fig. 2 ist eine Anordnung beschrieben, die verglichen mit der in Fig. 1 beschriebenen Anordnung um ein Mittel zur Or­ ganisation des Datenflusses, das im weiteren als eine Multi­ plexerkomponente ASC bezeichnet wird, erweitert wird, so daß ein Konferenzsystem auf Basis des im vorigen beschriebenen Fenster-Systems ermöglicht wird.

Es sind mehrere unterschiedliche Realisierungen der Multiple­ xerkomponente ASC bekannt. Diese sind beispielsweise be­ schrieben in (D. Garfinkel et al, HP Shared X: A Tool for Re­ al-Time Collaboration, Hewlett-Packard Journal, S. 23-36, April 1994; W. Minenko, Transparentes Application Sharing un­ ter X Window, Multimediale Telekooperation, Deutsches For­ schungszentrum für Künstliche Intelligenz (DFKI) GmbH, Saar­ brücken, S. 1-8, 1994).

Eine Untersuchung über unterschiedliche Realisierungen der Multiplexerkomponente ASC ist beschrieben in (J. Baldeschwie­ ler et al, A Survey on X Protocol Multiplexors, Swiss Federal Institute of Technology, Computer Engineering and Networks Laboratory (TIK), ETH-Zentrum, Zürich, 1993).

Durch die Multiplexerkomponente ASC ist es nun möglich, daß mehrere Server XSi über die Multiplexerkomponente ASC mit dem Klienten XC kommunizieren und so auf jeweils das Programm P zugreifen können. Ein Index i identifiziert hierbei jeweils jeden Server XSi eindeutig und ist eine beliebige natürliche Zahl zwischen 1 und n, wobei die Zahl n die Anzahl der Server XSi, die über die Multiplexerkomponente ASC mit dem Klienten XC gekoppelt sind, angibt.

Die Multiplexerkomponente ASC sollte mindestens folgende Ei­ genschaften aufweisen:

• - Die Multiplexerkomponente ASC ist zwischen den Klienten XC und die Server XSi geschaltet.
• - Gegenüber dem Klienten XC übernimmt die Multiplexerkompo­ nente die Funktionalität eines einzigen Servers XS, um so­ mit die Funktionalität der Anordnung gemäß Fig. 1 zu er­ halten.
• - Gegenüber den n Servern XSi übernimmt die Multiplexerkompo­ nente ASC die Funktionalität des Klienten XC, wodurch n "logische Klienten" durch die Multiplexerkomponente ASC mo­ delliert werden.

Es wird also jeweils von einem Server XSi eine Konferenzan­ frage Ai an die Multiplexerkomponente ASC gesendet. In der Multiplexerkomponente ASC wird die jeweilige Konferenzan­ frage Ai umgewandelt in die Anfrage A, die an den Klienten XC gesendet wird.

Die Darstellungsanfrage B des Klienten XC wird im Gegensatz zu der Anordnung, die in Fig. 1 beschrieben wurde, an die Multiplexerkomponente ASC gesendet, wo sie dann umgewandelt wird in eine Konferenzdarstellungsanfrage Bi, und an den jeweiligen Server XSi, der die Konferenzanfrage Ai gesendet hatte gesendet.

Es kann aber auch je nach Typ der Konferenzdarstellungsan­ frage Bi erforderlich sein, daß die Darstellungsanfrage B an jeden Server XSi verteilt wird. Dies ist beispielsweise notwendig, wenn die Darstellungsanfrage B in einer Anforde­ rung an die Bildschirmeinheit BS besteht, da ja eine Ände­ rung des Bildschirminhalts auf jeden Server XSi sichtbar sein muß.

• - Die Multiplexerkomponente ASC übernimmt also die Funktio­ nalität eines Multiplexers und Demultiplexers, also die Or­ ganistion des Datenflusses.

Hierbei wird in der Multiplexerkomponente ASC die Darstel­ lungsanfrage B des Klienten XC zu den angekoppelten Servern XSi gemultiplext, wobei Kopien der Darstellungsanfrage B an die einzelnen Server XSi gesendet werden.

Dabei werden Änderungen an den einzelnen Konferenzdarstel­ lungsanfragen Bi durchgeführt entsprechend den unterschied­ lichen Ressourcen der Server XSi, beispielsweise bei unter­ schiedlichen Farbendarstellungen bei den Servern XSi, wenn unterschiedliche Arten von Bildschirmeinheiten BS bei den Servern XSi verwendet werden, oder ähnliches.

• - Von den Servern XSi gesendete Konferenzanforderungen Ai werden in der Multiplexerkomponente ACS gesammelt und even­ tuell nicht erlaubte Konferenzanforderungen Ai werden her­ ausgefiltert.
• - Die erlaubten Konferenzanforderungen Ai werden an den Kli­ enten XC weitergeleitet als ob diese Konferenzantorderungen Ai direkt von einem einzigen Server XS kämen und nicht, wie dies tatsächlich der Fall ist, von mehreren Servern XSi.

In Fig. 3 sind einzelne Verfahrensschritte des erfindungsge­ mäßen Verfahrens dargestellt.

In einem ersten Schritt 1 wird eine Konferenzanforderung Ai von einem beliebigen Server XSi an die Multiplexerkomponente ASC gesendet.

Die Konferenzanforderung Ai wird von der Multiplexerkomponen­ te ASC empfangen 2.

Nach Empfang der Konferenzanforderung Ai wird in einem weite­ ren Schritt 3 überprüft, ob der Server XSi, der die Konfe­ renzanforderung Ai gesendet hat, das Programm P, auf das sich die Konferenzanforderung Ai bezieht, ursprünglich gestartet hat.

Dies entspricht der Kontrolle, ob der Sender der Konferenzan­ forderung Ai der Besitzer der Anwendung ANW ist.

Hat der die Konferenzanforderung Ai sendende Server XSi das Programm P ursprünglich gestartet und besitzt er zu dem be­ treffenden Zeitpunkt das Eingaberecht, wird die Konferenzan­ forderung Ai von der Multiplexerkomponente ASC direkt an den Klienten XC und somit an das Programm P und die Anwendung ANW weitergeleitet 4.

Dies geschieht, da im Rahmen dieser Erfindung der Besitzer der Anwendung ANW die komplette Kontrolle über seine Anwen­ dung ANW besitzt. Somit ist es für diesen Fall auch nicht nö­ tig, eine weitere Zugriffskontrolle für Konferenzanforderun­ gen Ai, die von dem Besitzer der Anwendung ANW gesendet wur­ den, durchzuführen.

Wird die Konferenzanforderung Ai jedoch von einem Server XSi gesendet, der nicht Besitzer der Anwendung ANW ist, wird für die Konferenzanforderung Ai eine zusätzliche Zugriffskontrol­ le anhand einer Zugriffskontrolldatenbank ZDK durchgeführt 5. Durch die Zugriffskontrolle wird die Konferenzanforderung Ai in erlaubte Konferenzanforderungen Ai und nicht erlaubte Kon­ ferenzanforderungen Ai unterschieden.

In einem weiteren Schritt 6 wird das Ergebnis der im vorigen durchgeführten Zugriffskontrolle 5 überprüft. Wurde die Kon­ ferenzanforderung Ai durch den Applikationsbesitzer als eine nicht erlaubte Konferenzanforderung Ai klassifiziert, wird die Konferenzanforderung Ai nicht an den Klienten XC und da­ mit auch nicht an die Anwendung ANW weitergeleitet, sondern sie wird verworfen 7.

Wurde jedoch die Konferenzanforderung Ai durch den Applikati­ onsbesitzer als eine erlaubte Konferenzanforderung Ai klassi­ fiziert, wird diese Konferenzanforderung Ai an den Klienten XC und somit an die Anwendung ANW weitergeleitet 8.

Durch diese Vorgehensweise wird nicht mehr nur, wie bisher zwischen demjenigen, der ein Bearbeitungsrecht zu dem Zeit­ punkt des Sendens der Konferenzanforderung Ai besitzt, also der sogenannte "Token Holder" ist, und den weiteren Benut­ zern, den sogenannten Observern" unterschieden.

Es kommt durch das erfindungsgemäße Verfahren eine weitere Unterscheidung hinzu, nämlich die Unterscheidung, ob der Ser­ ver XSi, der die Konferenzanforderung Ai gesendet hat, nicht auch der Besitzer der Anwendung ANW ist, also ob die Anwen­ dung ANW nicht ursprünglich von dem entsprechenden Server XSi gestartet wurde.

Durch diese zusätzliche Unterscheidung wird bei geeigneter Klassifikation erlaubter Konferenzanforderungen Ai durch den Applikationsbesitzer in der Zugriffskontrolldatenbank ZDK verhindert, daß unbefugte Dritte auf Ressourcen des Besitzers der Anwendung ANW zugreifen können.

Durch das erfindungsgemäße Verfahren ist nunmehr nur noch der Besitzer der Anwendung ANW berechtigt, vollständig auf seine eigenen Ressourcen zuzugreifen.

Außerdem hat der Besitzer der Anwendung ANW das alleinige Recht, die Zugriffskontrolldatenbank ZDK aufzubauen, und so­ mit als einziger die Möglichkeit, den Konferenzteilnehmern, mit denen er die von ihm gestartete Anwendung ANW gemeinsam nutzt, also allen anderen Servern XSi, ganz spezifisch be­ stimmte Rechte zuzugestehen oder zu nehmen.

Damit wird auch das Sicherheitsrisiko, das das in (G. Gahse, "Zugriffskontrolle in Konferenzsystemen", IBM Deutschland In­ formationssysteme GmbH, europäisches Zentrum für Netzwerkfor­ schung, Proceeding of VIS 1995, S. 141-162, 1995) beschrie­ bene Verfahren aufweist und im vorigen beschrieben wurde, vermieden, da auch keine weiteren Benutzereinheiten als der Besitzer der Anwendung ANW selbst, Zugriffsrechte auf die An­ wendung ANW verteilen können und auch ohne Zustimmung des Be­ sitzers der Anwendung ANW keine "allmächtigen" Zugriffsrechte auf die Anwendung ANW besitzen.

Die Zugriffskontrolldatenbank ZDK wird also ausschließlich von dem Besitzer der Anwendung ANW, also von demjenigen Ser­ ver XSi aus, von dem die Anwendung ANW ursprünglich gestartet wurde, aufgebaut und kontrolliert.

Die Zugriffskontrolldatenbank ZDK sollte mindestens folgende Informationen aufweisen, um die Zugriffskontrolle für jede Konferenzanforderung Ai effizient durchführen zu können (vgl. Fig. 6):

• - Eine Angabe AC des Klienten XC, auf den sich der Eintrag in der Zugriffskontrolldatenbank ZDK bezieht, beispielsweise durch Angabe einer Internet-Protocol-Adresse (IP) und zu­ sätzlich der entsprechenden Adresse des Ports,
• - eine Angabe AXSi des Servers XSi, auf den sich der Eintrag in der Zugriffskontrolldatenbank ZDK bezieht, beispielswei­ se durch Spezifizierung der Bildschirmadresse des jeweili­ gen Servers XSi,
• - eine Angabe des jeweiligen Typs AAT der Konferenzanforde­ rung Ai, auf den sich der Eintrag in der Zugriffskontroll­ datenbank ZDK bezieht, beispielsweise bei dem im vorigen beschriebenen Fenster-System für das erste Ausführungsbei­ spiel: XCreate, XRequest usw.,
• - weitere Parameter WP; die weiteren Parameter WP können bei­ spielsweise einen erlaubten Wertebereich für den jeweiligen Konferenzanforderungstyp aufweisen.

Die Art und Weise, wie die Zugriffskontrolldatenbank ZDK auf­ gebaut und geändert werden darf, kann auf unterschiedliche Weise realisiert sein.

Es ist beispielsweise vorgesehen, daß der Besitzer der Anwen­ dung ANW die Zugriffskontrolldatenbank ZDK als Textdatei mit Hilfe eines Texteditors aufbaut.

Weiterhin ist es auch vorgesehen, zum Aufbau der Zugriffskon­ trolldatenbank ZDK eine Bildschirmmaske zu verwenden, durch die die Eingabe zur Erstellung der Zugriffskontrolldatenbank ZDK für den Besitzer der Anwendung ANW intuitiv ermöglicht wird und somit erleichtert wird.

Es ist ferner vorgesehen, für vordefinierte Konferenzteilneh­ mer Schablonen zu definieren. Die Schablonen sind Zugriffs­ kontrolldatenbanken, die für bestimmte Sicherheitsszenarien, beispielsweise für bestimmte Applikationen und für bestimmte Konferenzteilnehmer, vordefiniert wurden und leicht abrufbar für die jeweils gestartete Anwendung ANW von dem Besitzer der Anwendung als Zugriffskontrolldatenbank ZDK eingebunden wer­ den kann.

Zusätzliche Maßnahmen zur Authentikation der Nachrichten, die zur Definition, also dem Aufbau der Zugriffskontrolldatenbank ZDK oder auch zur Änderung von Daten in der Zugriffskontroll­ datenbank ZDK dienen, sind in einer Weiterbildung des Verfah­ rens vorgesehen zur Vermeidung, daß Unbefugte Dritte Zugang zur Zugriffskontrolldatenbank ZDK selbst erhalten.

Kryptographische Verfahren zur Authentikation sind dem Fach­ mann bekannt, beispielsweise asymmetrische kryptographische Verfahren mit denen eine digitale Signatur und somit eine Au­ thentikation des Senders der jeweiligen Nachricht möglich ist oder auch die Verwendung einer Einwegfunktion, mit der ein Hash-Wert zumindest über einen Teil der Konferenzanforderung Ai gebildet wird.

In einer Weiterbildung des Verfahrens, die in Fig. 4 darge­ stellt ist, wird vor Beginn des Verfahrens eine Initialisie­ rung der im weiteren beschriebenen Authentikation durchge­ führt 41.

Dies geschieht beispielsweise durch folgendes Vorgehen.

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 krypthographische 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 Authen­ tikation und zur Sicherung 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.

Nachdem die Initialisierungsphase zur Authentikation 41 abge­ schlossen ist, wird in der Nutzdatenübertragungsphase jeweils nach Empfang der jeweiligen Konferenzanforderung Ai in der Multiplexerkomponente ASC eine Authentikation der Konferenz­ anforderung Ai und/oder der die Konferenzanforderung Ai sen­ denden Benutzereinheit XSi durchgeführt 42.

In einem weiteren Schritt 43 wird überprüft, ob die Authenti­ kation ein positives Ergebnis lieferte. Ist dies der Fall, wird die Konferenzanforderung Ai dem weiteren, im vorigen be­ schriebenen Verfahren zugeführt L.

Ergab jedoch die Authentikation 43 ein negatives Ergebnis, wird die Konferenzanforderung Ai verworfen, und somit nicht an den Klienten XC weitergeleitet 44.

Eine Weiterbildung des Verfahrens liegt ferner darin, nach Empfang der Konferenzanforderung Ai durch die Multiplexerkom­ ponente ASC 2 zu überprüfen, ob die Benutzereinheit XSi, die die Konferenzanforderung Ai gesendet hat, zu dem jeweiligen Sendezeitpunkt ein Bearbeitungsrecht besaß 51 (vgl. Fig. 5).

Dies entspricht der Fragestellung, ob die Benutzereinheit XSi zu dem Sendezeitpunkt der Konferenzanforderung Ai "Token Hol­ der" der Anwendung ANW war.

Ist dies der Fall, wird die Konferenzanforderung Ai den wei­ teren Verfahrensschritten des erfindungsgemäßen Verfahrens unterzogen L. Ist dies jedoch nicht der Fall, wird die Konfe­ renzanforderung Ai nicht weitergeleitet und somit verworfen 52.

Diese Weiterbildung weist den Vorteil auf, daß eine Konfe­ renzanforderung Ai, die ohnehin nicht erlaubt ist, da sie von einer Benutzereinheit XSi, die zur Zeit gar nicht das Bear­ beitungsrecht besaß, gesendet wurde, dem gesamten Verfahren unterzogen wird. Damit werden überflüssige Zugriffskontrollen vermieden.

Die nötige Erweiterung der in Fig. 2 beschriebenen Anord­ nung, damit die Anordnung das im vorigen beschriebene Verfah­ ren durchführen kann, ist in Fig. 7 dargestellt. Diese Er­ weiterung besteht darin, daß eine zusätzliche Zugriffskon­ trolldatenbank ZDK in der Multiplexerkomponente ASC vorgese­ hen ist.

Ferner müssen natürlich die vorgesehenen Überprüfungen, die im vorigen beschrieben wurden, implementiert werden.

In einem zweiten Ausführungsbeispiel wird das Verfahren be­ schrieben für Rechnereinheiten, die monolithische, graphikba­ sierte Fenster-Systeme verwenden, die keine offene Kommunika­ tionsschnittstelle zwischen der Anwendung ANW und dem Fen­ ster-System aufweisen (vgl. Fig. 8).

Beispiele solcher monolithische, graphikbasierte Fenster- Systeme sind bekannt und wurden im vorigen zitiert.

Bei monolithischen, graphikbasierten Fenster-Systemen muß zum Verteilen einer Ein-Benutzer-Anwendung ebenfalls das Fenster­ protokoll zwischen der Anwendung ANW und der Benutzeroberflä­ che "aufgebrochen" werden. Die Vorgehensweise hierbei ist prinzipiell analog zu der bereits beschriebenen. Die mögli­ chen Stellen zum Eingriff in das Fensterprotokoll werden im folgenden geschildert.

Die Struktur dieses monolithischen, graphikbasierten Fenster- Systems GDWS ist in Fig. 8 dargestellt.

Monolithische, graphikbasierte Fenstersysteme GDWS weisen mindestens folgende Komponenten auf:

• - den Bildschirm BS,
• - die Tastatur TA,
• - die Maus MA,
• - Graphikkartentreiber-Programme GDD,
• - Graphik-Bibliotheksroutinen BCL,
• - Fenster-Bibliotheksroutinen WL mit einem Input-Handler IL,
• - die Anwendung ANW.

Die Anwendung ANW läuft bei diesem Ausführungsbeispiel in derselben Umgebung wie das Graphikbasierte Fenstersystem GDWS und beide verwenden eine Menge von Funktionsaufrufen in einem gemeinsamen Speicher um miteinander zu kommunizieren.

Da Graphikbasierte Fenstersysteme GDWS keine offene Kommuni­ kationsschnittstelle aufweisen, muß für Anwendungen ANW, die von mehreren Benutzern gleichzeitig genutzt werden sollen, in den Aufbau der in Fig. 8 dargestellten Figur eingegriffen werden.

Die Erweiterungen können an verschiedenen Stellen des jewei­ ligen Graphikbasierten Fenstersystems GDWS vorgenommen wer­ den, beispielsweise an einer ersten Programmierschnittstelle zwischen den Fenster-Bibliotheksroutinen WL und der Anwendung ANW, an einer zweiten Programmierschnittstelle zwischen den Graphik-Bibliotheksroutinen BCL und den Fenster- Bibliotheksroutinen WL oder an den Graphikkartentreiber- Programmen GDD.

Diese Änderungen sind nur möglich, falls die Fenster- Bibliotheksroutinen WL, die Graphik-Bibliotheksroutinen BCL oder die Graphikkartentreiber-Programme GDD nicht fest an die Anwendung ANW gebunden sind, sondern dynamisch. Diese Art von Programmen werden als Dynamic Link Library (DLL) bezeichnet.

Die nötigen Änderungen sind bekannt.

Das erfindungsgemäße Verfahren selbst wird auch bei diesen monolithischen, graphikbasierte Fenstersysteme GDWS wie im vorigen beschrieben durchgeführt.

Claims (6)

1. Verfahren zur Zugriffskontrolle auf rechnerkontrollierte Programme (P), die von mehreren Benutzereinheiten (XSi; i = 1 . . . n) gleichzeitig genutzt werden können,

• - bei dem von einer Benutzereinheit (XSi) eine Anforderung (Ai) für ein Programm (P) gesendet wird (1),
• - bei dem in einem Mittel zur Organisation des Datenflusses (ASC) die Anforderung (Ai) für ein Programm empfangen wird (2),
• - bei dem in dem Mittel (ASC) geprüft wird, ob die Benut­ zereinheit (XSi), von der die Anforderung (Ai) gesendet wurde, das Programm (P) ursprünglich gestartet hatte (3),
• - bei dem, falls die die Anforderung (Ai) sendende Benut­ zereinheit (XSi) das Programm (P) gestartet hatte, die An­ forderung (Ai) an das Programm (P) weitergeleitet wird (4),
• - bei dem, falls die die Anforderung (Ai) sendende Benut­ zereinheit (XSi) das Programm (P) nicht gestartet hatte, anhand einer Zugriffskontrolldatenbank (ZDK) eine Zugriffs­ kontrolle für die Anforderung (Ai) durchgeführt wird (5),
• - bei dem, falls die Zugriffskontrolle ergibt, daß die Anfor­ derung (Ai) eine erlaubte Anforderung darstellt, die Anfor­ derung (Ai) an das Programm (P) weitergeleitet wird (6, 8), und
• - bei dem, falls die Zugriffskontrolle (ZDK) ergibt, daß die Anforderung (Ai) eine unerlaubte Anforderung darstellt, die Anforderung (Ai) nicht an das Programm (P) weitergeleitet wird (6, 7).

2. Verfahren nach Anspruch 1,

• - bei dem vor der Kontrolle, ob die Benutzereinheit (XSi) das Programm (P) ursprünglich gestartet hatte (3), in dem Mittel (ASC) überprüft wird, ob die Benutzereinheit (XSi) zu dem Sendezeitpunkt der Anforderung (Ai) ein Bearbeitungsrecht be­ saß (51), und
• - bei dem, falls die Benutzereinheit (XSi) kein Bearbeitungs­ recht besaß, die Anforderung (Ai) nicht an das Programm (P) weitergeleitet wird (52).

3. Verfahren nach Anspruch 1 oder 2, bei dem zu Beginn des Verfahrens eine Authentikation der Be­ nutzereinheit (XSi), die die Anforderung (Ai) gesendet hat, und/oder der Anforderung (Ai) durchgeführt wird (42).

4. Verfahren nach Anspruch 3, bei dem bei einem Verbindungsaufbau zwischen einer Benut­ zereinheit (XSi) und dem Programm (P) eine Initialisierungs­ phase zur Authentikation durchgeführt wird (41).

5. Verfahren nach Anspruch 4, bei dem in der Initialisierungsphase folgende Schritte vorge­ sehen werden, wobei die Benutzereinheit (XSi) ein Benutzer­ zertifikat besitzt und die Multiplexerkomponente (ASC) ein Programmzertifikat besitzt:

• a) von der Multiplexerkomponente (ASC) wird eine erste Zu­ fallszahl erzeugt,
• b) von der Multiplexerkomponente (ASC) wird eine erste Ver­ handlungsnachricht an die Benutzereinheit (XSi) gesendet, die mindestens folgende Komponenten aufweist:
  • - das Programmzertifikat,
  • - die erste Zufallszahl,
  • - einen ersten Vorschlag, und
  • - eine digitale Unterschrift, die mindestens über die erste Zufallszahl, und den ersten Vorschlag gebildet wird,
• c) die erste Verhandlungsnachricht wird von der Benutzerein­ heit (XSi) empfangen,
• d) von der Benutzereinheit (XSi) wird das Programmzertifikat überprüft,
• e) von der Benutzereinheit (XSi) wird die digitale Unter­ schrift überprüft,
• f) von der Benutzereinheit (XSi) wird, falls die Überprüfung des Programmzertifikats und der digitalen Unterschrift ein positives Ergebnis liefert, überprüft, ob die vorgeschlagenen kryptographischen Algorithmen im weiteren verwendet werden können,
• g) falls die kryptographischen Algorithmen von der Benut­ zereinheit (XSi) nicht unterstützt werden, wird von der Be­ nutzereinheit (XSi) ein zweiter Vorschlag in einer zweiten Vorschlagsnachricht gebildet und an die Multiplexerkomponente (ASC) gesendet, die mindestens folgende Komponenten aufweist:
  • - das Benutzerzertifikat,
  • - eine zweite Zufallszahl, die von der Benutzereinheit er­ zeugt wird,
  • - den weiteren Vorschlag, und
  • - eine digitale Unterschrift, die mindestens über die erste Zufallszahl, die zweite Zufallszahl, und den weiteren Vor­ schlag gebildet wird,
• h) falls die kryptographischen Algorithmen unterstützt wer­ den, wird von der Benutzereinheit (XSi) eine Bestätigungs­ nachricht gebildet und an die Multiplexerkomponente (ASC) ge­ sendet, die mindestens folgende Komponenten aufweist:
  • - das Benutzerzertifikat,
  • - eine zweite Zufallszahl, die von der Benutzereinheit (XSi) erzeugt wird,
  • - eine positive Bestätigung, und
  • - eine digitale Unterschrift, die mindestens über die erste Zufallszahl, die zweite Zufallszahl, und die positive Bestä­ tigung gebildet wird,
• i) die zweite Verhandlungsnachricht oder die Bestätigungs­ nachricht wird von der Multiplexerkomponente (ASC) empfangen,
• j) von der Multiplexerkomponente (ASC) wird das Benutzerzer­ tifikat überprüft,
• k) von der Multiplexerkomponente (ASC) wird die digitale Un­ terschrift überprüft,
• l) von der Multiplexerkomponente (ASC) wird, falls die Über­ prüfung des Benutzerzertifikats und der digitalen Unter­ schrift ein positives Ergebnis liefert und die Bestätigungs­ nachricht empfangen wurde, ein erster Sitzungsschlüssel unter Berücksichtigung der vereinbarten kryptographischen Algorith­ men für eine folgende Nutzdatenübertragungsphase erzeugt,
• m) von der Multiplexerkomponente (ASC) wird, falls die Über­ prüfung des Programmzertifikats und der digitalen Unter­ schrift ein positives Ergebnis liefert und die weitere Ver­ handlungsnachricht empfangen wurde, überprüft, ob die vorge­ schlagenen kryptographischen Algorithmen im weiteren verwen­ det werden können,
• o) von der Multiplexerkomponente (ASC) wird, falls die vorge­ schlagenen kryptographischen Algorithmen im weiteren verwen­ det werden können, ein erster Sitzungsschlüssel unter Berück­ sichtigung der vereinbarten kryptographischen Algorithmen für eine folgende Nutzdatenübertragungsphase erzeugt,
• p) von der Multiplexerkomponente (ASC) wird eine erste Sit­ zungsschlüsselnachricht an die Benutzereinheit (XSi) gesen­ det, die mindestens folgende Komponenten aufweist:
  • - den mit einem öffentlichen Schlüssel der Benutzereinheit (XSi) verschlüsselten ersten Sitzungsschlüssel,
  • - eine mindestens über die erste Zufallszahl, die zweite Zu­ fallszahl, den ersten Sitzungsschlüssel gebildete digitale Unterschrift,
• q) von der Benutzereinheit (XSi) wird der erste Sitzungs­ schlüssel unter Verwendung eines privaten Benutzerschlüssels ermittelt,
• r) von der Benutzereinheit (XSi) wird die digitale Unter­ schrift überprüft,
• s) von der Benutzereinheit (XSi) wird eine zweite Sitzungs­ schlüsselnachricht an das Programm gesendet, die mindestens folgende Komponenten aufweist:
  • - den mit einem öffentlichen Schlüssel der Multiplexerkompo­ nente (ASC) verschlüsselten zweiten Sitzungsschlüssel,
  • - eine mindestens über die erste Zufallszahl, die zweite Zu­ fallszahl, den zweiten Zwischenschlüssel gebildete digitale Unterschrift oder Hash-Wert,
• t) von der Multiplexerkomponente (ASC) wird die zweite Sit­ zungsschlüsselnachricht empfangen,
• u) von der Multiplexerkomponente (ASC) wird die digitale Un­ terschrift oder der Hash-Wert überprüft,
• v) falls die Überprüfung ein positives Ergebnis liefert, be­ ginnt die Nutzdatenübertragungsphase, bei der jede Instanz für das Senden von Daten den Sitzungsschlüssel verwendet, der von ihr selbst generiert wurde und bei der der jeweils emp­ fangene Sitzungsschlüssel der Partnerinstanz ausschließlich zum Empfang von versendeten Nachrichten verwendet wird.

6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem die Zugriffskontrolldatenbank (ZDK) mindestens fol­ gende Information aufweist:

• - Eine Angabe (AC) des Klienten (XC), auf den sich der Ein­ trag in der Zugriffskontrolldatenbank (ZDK) bezieht,
• - die Angabe des Fensters (AF), auf den sich der Eintrag in der Zugriffskontrolldatenbank (ZDK) bezieht,
• - die Benutzereinheit (XSi),
• - Angabe eines Anforderungstyps (AAT), dessen nähere Eigen­ schaften in weiteren Parametern (WP) angegeben sind,
• - die weiteren Parameter (WP), die die Anforderung (Ai) auf­ weisen muß, um als eine erlaubte Anforderung akzeptiert zu werden.