DE10107883A1

DE10107883A1 - Verfahren zur Übertragung von Daten, Proxy-Server und Datenübertragungssystem

Info

Publication number: DE10107883A1
Application number: DE2001107883
Authority: DE
Inventors: Hans Joachim Bickenbach; Marcus Belke
Original assignee: Post Ebusiness Deutsche GmbH
Current assignee: Deutsche Post AG
Priority date: 2001-02-19
Filing date: 2001-02-19
Publication date: 2002-08-29
Anticipated expiration: 2021-02-20
Also published as: DE10107883B4; WO2002067532A1

Abstract

Die Erfindung betrifft ein Verfahren zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit. DOLLAR A Erfindungsgemäß wird dieses Verfahren so durchgeführt, dass die Übertragung über mindestens einen zwischengeschalteten Proxy-Server erfolgt, wobei der Proxy-Server Signaturinformationen erfasst, die Signaturinformationen mit wenigstens einem Teil der Daten verknüpft und hierdurch die Daten beglaubigt und/oder verschlüsselt. DOLLAR A Die Erfindung betrifft ferner einen für die Durchführung des Verfahrens geeigneten Proxy-Server und ein Datenübertragungssystem.

Description

Die Erfindung betrifft ein Verfahren zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit

Die Erfindung betrifft ferner einen für den Einsatz in dem Verfahren geeigneten Proxy-Server.

Die Erfindung betrifft außerdem ein Datenübertragungssystem.

Der Austausch von Daten über Proxy-Server ist technisch bedeutend, weil hierdurch ein besonders einfacher und sicherer Zugang zu Datennetzwerken ermöglicht wird.

Ein Beispiel eines gattungsgemäßen Verfahrens ist in der Deutschen Offenlegungsschrift DE 197 40 547 A1 dargestellt. Dieses bekannte Verfahren beinhaltet eine sichere Kommunikation zwischen einer anfordernden Anwendungs-Einheit und einer bedienenden Anwendungs-Einheit unter Verwendung eines Proxy-Servers. Bei diesem Verfahren wird überwacht, ob die Kommunikation der anfordernden Einheit mit einem selektierten Kommunikationsprotokoll übereinstimmt.

Dieses bekannte Verfahren ist jedoch auf einen Einsatz mit vorher vorgegebenen Kommunikationsprotokollen beschränkt.

Der Erfindung liegt die Aufgabe zugrunde, ein gattungsgemäßes Verfahren so weiterzuentwickeln, dass eine sichere Kommunikation zwischen verschiedenen Datenverarbeitungseinheiten ermöglicht wird. Vorzugsweise soll dieses Verfahren unabhängig von den jeweils eingesetzten Kommunikationsprotokollen sein.

Erfindungsgemäß wird diese Aufgabe dadurch gelöst, dass ein gattungsgemäßes Verfahren so durchgeführt wird, dass die Übertragung über mindestens einen zwischengeschalteten Proxy- Server erfolgt, wobei der Proxy-Server Signaturinformationen erfasst, die Signaturinformationen mit wenigstens einem Teil der Daten verknüpft und hierdurch die Daten beglaubigt und/oder verschlüsselt.

Hierbei ist es besonders zweckmäßig, dass die Signaturinformationen einem digitalen Signaturschlüssel entsprechen.

Zur weiteren Erhöhung der Datensicherheit ist es vorteilhaft, dass der Proxy-Server, der die Daten durch Verknüpfung mit der Signaturinformation authentisiert und/oder verschlüsselt, die verschlüsselten Daten an einen Authentisierungsserver übermittelt.

Der Begriff Authentisierungsserver ist in einer weiten Bedeutung zu verstehen. Er beinhaltet insbesondere einen Verzeichnisserver, der ein Verzeichnis aller Zertifikate mit der dazugehörigen Statusinformation enthält. Es ist bevorzugt, dass der Authentisierungsserver Gültigkeitsinformationen über sämtliche Zertifikate enthält. Es ist jedoch gleichfalls möglich, beispielsweise nur die gültigen Zertifikate oder nur die gesperrten Zertifikate zu speichern und durch eine Anfrage bei dem Authentisierungsserver die Gültigkeit beziehungsweise die Ungültigkeit des Zertifikats zu überprüfen.

Ferner ist es zweckmäßig, dass ein weiterer Proxy-Server, der mit der Signaturinformation authentisierte und/oder verschlüsselte Daten empfängt, die mit der Signaturinformation verschlüsselten und/oder authentisierten Daten an den Authentisierungs-Server überträgt.

Eine vorteilhafte Weiterführung dieser Varianten der Erfindung sieht vor, dass der Authentisierungs-Server eine Authentisierungsinformation an den Proxy-Server sendet, der unter Einsatz der Signaturinformation die Daten verschlüsselt und/oder authentisiert.

Eine weitere, gleichfalls bevorzugte Methode zur Erhöhung der Datensicherheit ist, dass der Authentisierungs-Server die Authentisierungsinformation an den weiteren Server sendet, der die mit der Signaturinformation verschlüsselten und/oder authentisierten Daten empfängt.

Eine weitere Erhöhung der Datensicherheit lässt sich vorteilhafterweise dadurch erzielen, dass die Signatur mittels wenigstens eines auf einer Smart-Card gespeicherten, digitalen Schlüssels erstellt wird.

Eine Smart Card ist ein Mikro-Prozessor mit Speicher, der auf eine Kunststoff-Karte aufgebracht wird. Die Smart Card steht mit dem Computer über die serielle Schnittstelle und einen Kartenleser in Verbindung. Auf der Smart Card wird durch externes Anlegen einer Spannung ein Betriebssystem (ähnlich dem eines Computers) gestartet, welches den Ablauf von Applikationen auf der Smart Card und/oder das unzugängliche Speichern von privaten Daten auf der Smart Card ermöglicht.

Ferner ist es vorteilhaft, das Verfahren so durchzuführen, dass ein Aufbau einer sicheren Datenverbindung mittels eines Authentisierungsmechanismus eingeleitet wird.

Es ist besonders zweckmäßig, ein IPSEC-Protokoll als Authentisierungsmechanismus einzusetzen.

Eine andere vorteilhafte Ausführungsform dieser Implementation zeichnet sich dadurch aus, dass ein Secure Sockets Layer - Handshake-Protokoll als Authentisierungsmechanismus dient.

Das SSL-Handshake-Protokoll steht am Anfang einer SSL- Verbindung. Es hat die folgenden zwei Aufgaben: zum Einen werden die beiden Kommunikationspartner gegenseitig authentisiert; zum Anderen ermöglicht es die sichere Aushandlung eines (symmetrischen) Schlüssels zum Verschlüsseln der zwischen den beiden Kommunikationspartnern ausgetauschten Nutzdaten.

Ferner ist es zweckmäßig, dass das Verfahren so durchgeführt wird, dass der Proxy-Server von der ersten Datenverarbeitungseinheit als ein virtueller Rechner simuliert wird.

Es ist ferner zweckmäßig, dass der Proxy-Server durch die zweite Datenverarbeitungseinheit als ein virtueller Rechner simuliert wird.

Hierbei ist es besonders vorteilhaft, dass der Proxy-Server in einem geschützten Bereich der Datenverarbeitungseinheit betrieben wird.

Eine geeignete Sicherheitsumgebung kann beispielsweise durch eine geeignete Softwareroutine gestaltet werden, wobei ein Betrieb und/oder eine Freischaltung des Proxy-Servers in einem Personal Security Environment bevorzugt ist.

Ein weiterer Gegenstand der Erfindung ist, einen Proxy-Server mit einem Eingang zum Empfang von Daten von einer ersten Datenverarbeitungseinheit und zur Übertragung der Daten an eine zweite Datenverarbeitungseinheit so zu gestalten, dass der Proxy-Server eine Signaturinformation einliest, mit der Signaturinformation die Daten verschlüsselt und/oder authentisiert und die verschlüsselten und/oder authentisierten Daten an die zweite Datenverarbeitungseinheit übermittelt.

Die Erfindung sieht ferner vor, ein Datenübertragungssystem zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit so zu gestalten, dass die erste Datenverarbeitungseinheit mit einem ersten Proxy-Server verbunden ist, dass die zweite Datenverarbeitungseinheit mit einem weiteren Proxy-Server verbunden ist, dass der erste Proxy-Server mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, dass der weitere Proxy-Server mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, und dass zwischen dem ersten Proxy-Server und dem weiteren Proxy-Server verschlüsselte und/oder authentisierte Daten übertragen werden.

Weitere Vorteile, Besonderheiten und zweckmäßige Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen und der nachfolgenden Darstellung bevorzugter Ausführungsbeispiele anhand der Zeichnung.

Die Zeichnung zeigt in Fig. 1 ein Gesamtsystem zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit und einer zweiten Datenverarbeitungseinheit.

Vorzugsweise handelt es sich bei der ersten Datenverarbeitungseinheit um eine zur Ausführung von Anwendungen geeignete Datenverarbeitungseinheit. Insbesondere ist die erste Datenverarbeitungseinheit ein Client C.

Der Client C kann eine beliebige zur Durchführung eines Datenaustauschs geeignete Einheit sein. Vorzugsweise ist der Client C ein Computer. Der Begriff "Computer" ist in seiner umfassendsten Weise zu verstehen. Es kann sich hierbei um eine beliebige, zur Durchführung von Datenverarbeitungsfunktionen und Berechnungen geeignete Einheit handeln, beispielsweise eine Workstation, einen Personalcomputer, einen Mikrocomputer, eine zur Durchführung von Berechnungen geeignete Schaltung oder eine virtuelle Berechnungseinheit.

Der als erste Datenverarbeitungseinheit wirkende Client C ist mit einer zweiten Datenverarbeitungseinheit verbunden. Die zweite Datenverarbeitungseinheit kann gleichfalls auf verschiedene Weisen gestaltet sein. Vorzugsweise handelt es sich hierbei auch um einen Computer im weitesten Sinne.

Vorzugsweise erfolgt die Datenübertragung zwischen der ersten Datenverarbeitungseinheit und der zweiten Datenverarbeitungseinheit über einen Server. Der Begriff Server ist ebensowenig wie der Begriff Computer einschränkend zu verstehen. Der Begriff Server bedeutet in seiner allgemeinsten Form einen beliebigen Computer einschließlich der Simulation eines separaten Computers auf einem Simulationsrechner. Insbesondere handelt es sich bei dem Server um einen realen oder virtuellen Computer, der Dateneingänge und/oder -ausgänge enthält, die als Mittel dienen, einen Datenaustausch mit einem oder mehreren anderen Computern oder sonstigen Datenverarbeitungseinheiten durchzuführen.

Im dargestellten Fall befinden sich zwischen der ersten Datenverarbeitungseinheit C und der zweiten Datenverarbeitungseinheit S zwei Proxy-Server SPC und SPS. Wenigstens einer der beiden Server ist mit Mitteln zur Authentisierung und/oder Verschlüsselung von Daten ausgestattet, die von der unmittelbar mit ihm verbundenen Datenverarbeitungseinheit an ihn gesendet werden. Die beiden Secure-Proxys SPC und SPS sind über eine beliebige Datenleitung miteinander verbunden, wobei es nicht auf die Art der Verbindung ankommt. Beispielsweise kann diese Verbindung leitungsbezogen oder zumindest teilweise über eine Funkverbindung erfolgen. Die Kommunikationsprotokolle können gleichfalls frei gewählt werden, um eine Anpassung an jeweils für die Datenkommunikation verfügbare Dienste zu erleichtern.

Im dargestellten Fall verschlüsselt der mit SPC bezeichnete Proxy-Server von der ersten Datenverarbeitungseinheit C gesendete Daten. Die Verschlüsselung erfolgt mit Hilfe einer Signaturinformation. Die Signaturinformation ist zur Erhöhung der Datensicherheit wenigstens teilweise auf einer Smart-Card SC1 gespeichert. Zu einer weiteren Erhöhung der Datensicherheit ist es zweckmäßig, dass die Signaturinformation durch die Eingabe weiterer Daten ergänzt wird, beispielsweise indem auf der ersten Datenverarbeitungseinheit ein spezieller Zugriffscode, im einfachsten Fall ein PIN-Code, eingegeben wird. Hierdurch wird eine Signaturinformation freigeschaltet, so dass der zugehörige digitale Schlüssel eingesetzt werden kann.

Unter Einsatz des digitalen Schlüssels authentisiert und/oder verschlüsselt der Secure-Proxy SPC die von der ersten Datenverarbeitungseinheit C übermittelten Daten und sendet diese an den weiteren Secure-Proxy SPS.

Der weitere Proxy SPS kann prinzipiell einen ähnlichen Aufbau aufweisen wie der erste Proxy-Server SPC. Er kann gleichfalls einem oder mehreren Computern den Zugang zu Daten ermöglichen. Zweckmäßigerweise handelt es sich dabei um einen Secure-Proxy, der einen Zugang zu bestimmten Bereichen von Web-Seiten ermöglicht.

Vorzugsweise steuert der weitere Secure-Proxy SPS eine Datenübertragung von beziehungsweise zu einem speziellen Server, beispielsweise einem Server für einen Dateneinsatz im World Wide Web (WWW).

Zur Erhöhung der Datensicherheit ist es zweckmäßig, dass der weitere Proxy-Server SPS gleichfalls mit Mitteln zu einer Authentisierung und/oder Verschlüsselung von Daten versehen ist.

Zu diesem Zweck ist es vorteilhaft, dass auch der weitere Server unter einem Einsatz von Signaturinformationen die Daten verschlüsselt und/oder authentisiert. Vorzugsweise sind diese Signaturinformationen auf einer weiteren Smart-Card SC2 gespeichert. Hierbei ist es gleichfalls möglich, dass die Signaturinformationen - beispielsweise durch Hinzugabe von geeigneten geheimen Code-Daten - zu einem Signaturschlüssel ergänzt werden. Bei den Code-Daten handelt es sich in einem besonders einfachen und zweckmäßigen Fall um eine PIN-Nummer.

Vorzugsweise ist wenigstens einer der Proxy-Server SPC, beziehungsweise SPS mit einem Konfigurationsproxy KP1, beziehungsweise KP2, verbunden. Der Konfigurationsproxy ermöglicht eine Einstellung von Konfigurationsdaten in dem ersten Proxy-Server SPC und/oder in dem weiteren Proxy-Server SPS.

Zur weiteren Erhöhung der Datensicherheit ist es zweckmäßig, dass eine Authentisierung von Informationen durch einen separaten Authentisierungsserver erfolgt.

Eine bevorzugte Authentisierung der Information beinhaltet eine Überprüfung, ob die Informationen mit einem gültigen Zertifikat versehen sind, wobei die Gültigkeit der Zertifikate durch eine Überprüfung von Statusinformationen in dem Authentisierungsserver nachgewiesen wird.

Der Authentisierungs-Server übermittelt eine Dateninformation, die eine Statusinformation, zum Beispiel über die Gültigkeit des Zertifikats bescheinigt, an den ersten Proxy-Server SPC und/oder an den zweiten Proxy-Server SPS.

Ein Berechtigungsnachweis kann auf verschiedene Weise erfolgen. Beispielsweise erfolgt ein Berechtigungsnachweis dadurch, dass die Zertifikate eine Berechtigungsinformation enthalten. Alternativ ist es jedoch gleichfalls möglich, dass bereits über die Identität des jeweiligen Benutzers die Berechtigung ermittelt wird.

Hierbei ist es zweckmäßig, dass die Authentisierung gleichfalls verschlüsselt übertragen wird, damit Dritte nicht in die Lage versetzt werden, missbräuchlich Authentisierungsinformationen zu erzeugen.

Ferner ist es zweckmäßig, dass auch der weitere Proxy-Server SPS digital signierte Daten an den Authentisierungs-Server übermittelt. In diesem Fall überprüft der Authentisierungs- Server die Berechtigung und/oder Identität des Betreibers des weiteren Proxy-Servers SPS.

Eine Anwendung des zuvor beschriebenen Sicherungsmechanismus ist besonders zweckmäßig, wenn ein Zugang zu besonders sicherungsbedürftigen Web-Seiten gewährleistet sein soll. Hierdurch kann beispielsweise verhindert werden, dass missbräuchlich vertrauliche und/oder verschlüsselte Web- Seiten im Internet zur Verfügung gestellt werden und Benutzern dieser Seiten eine Berechtigung und/oder Identität vortäuschen.

Durch eine Prüfung der Berechtigung und/oder Identität des Betreibers des weiteren Proxy-Servers SPS, beziehungsweise der mit dem weiteren Proxy-Server SPS verbundenen weiteren Datenverarbeitungseinheit S. kann der Anwender sicherstellen, dass vertrauliche Informationen nicht an unberechtigte Personen übermittelt werden.

Der Benutzer der ersten Datenverarbeitungseinheit C muss die Sicherheitseinstellungen des mit ihm verbundenen Proxy- Servers SPC so vornehmen, dass bestimmte Datenübertragungsvorgänge nur zu besonders gesicherten und/oder beglaubigten weiteren Datenverarbeitungseinheiten erfolgen. Eine Einstellung dieser Sicherheitskonfiguration ist beispielsweise durch den Konfigurationsproxy-Server KP1 möglich.

Hierdurch wird gewährleistet, dass bestimmte vertrauliche Informationen, wie beispielsweise Kreditkartennummern nicht an beliebige, sondern nur an besonders authentisierte Web- Seiten übertragen werden. Durch eine Übermittlung von Informationen, insbesondere von ausgewählten, geheimzuhaltenden Informationen, ausschließlich an zuvor legitimierte Stellen, wird eine missbräuchliche Abfrage der vertraulichen Daten vermieden.

Obwohl jeder der dargestellten Sicherungsmechanismen grundsätzlich einzeln erfolgen kann, ist eine Gesamtkombination der Sicherheitsmechanismen besonders zweckmäßig, da so eine allseitig gesicherte Datenkommunikation ermöglicht wird.

Wegen der vollständigen Sicherheit ist ein Datenkommunikationsnetz besonders vorteilhaft, bei dem sowohl die Übertragung der Daten von der ersten Datenverarbeitungseinheit zu der zweiten Datenverarbeitungseinheit als auch die Datenübertragung von der zweiten Datenverarbeitungseinheit S zu der ersten Datenverarbeitungseinheit C durch einen Austausch von beglaubigten und/oder verschlüsselten Daten erfolgen.

Nachfolgend werden bevorzugte Ausführungsformen der Erfindung dargestellt, wobei besonders vorteilhafte Kommunikationsprotokolle und Computerprogramme eingesetzt werden.

Auch dort, wo die Protokolle und die Programme mit konkreten, bekannten Begriffen bezeichnet werden, ist es klar, dass sie durch andere, gleichwirkende Funktionen aufweisende Protokolle und Computerprogramme ersetzt werden können.

So bezeichnet beispielsweise die Bezeichnung "UNIX" verschiedene Plattformen, wie beispielsweise Linux, HP-UX 11 oder SUN-Solaris. An Stelle von UNIX-basierten Programmen können jedoch auch andere Computerprogramme eingesetzt werden, wie die Programme der Windows-Familie von Microsoft, beispielsweise "Windows NT", "Windows 95", "Windows 98" oder "Windows 2000".

Soweit es nur eingeschränkt dargestellt ist, gilt die Darstellung sowohl für Clients als auch für Server. Zusammenfassend werden Clients und Server auch als Secure Proxy bezeichnet.

Die Erfindung beinhaltet Implementationen, mit denen beliebige Protokolle zwischen zwei Rechnern abgesichert werden können. Vorzugsweise handelt es sich dabei um TCP/IP- basierte Protokolle. Die sichere Übertragung der Daten wird dabei vorzugsweise durch SSL gewährleistet. Im Einzelnen unterstützt SSL Authentisierung von Client und Server, Verschlüsselung und Integritätsprüfung.

Das Transmission Control Protocol/Internet Protocol, TCP/IP, ist ein Standard, der den Austausch von Daten über ein Netzwerk beschreibt und im Internet zur Anwendung kommt. Er bildet das Fundament für höhere, spezialisierte Protokolle wie HTTP.

Bevorzugte Proxy Client- und Server-Software umfasst eine oder mehrere der nachfolgend aufgelisteten Software-Module. Hinzu kommen geeignete Konfigurationsdateien. Diese werden vom Secure Proxy vorzugsweise nur eingelesen. Die Erstellung und Wartung dieser Dateien erfolgt mit dem jeweiligen Konfigurationswerkzeug.

SQRP.exe ist der Name eines bevorzugten ausführbaren Programmes, das auf einem Server, beziehungsweise auf Client Seite als Hintergrund-Prozess gestartet wird. Unter Unix entfallen die ".exe"-Endungen.

Eine bevorzugte Befehlsdatei, die nachfolgend als CT32.DLL bezeichnet wird, beinhaltet bevorzugte Aufrufe für den Chipkartenleser unter einem geeigneten Programm wie Windows.

Für das Parsen der Inhalte der Konfigurationsdateien werden unter Windows die Funktionen aus einer weiteren Befehlsdatei benötigt, von der eine bevorzugte Ausführungsform nachfolgend als GNU_REGEX.DLL bezeichnet wird.

Nachfolgend werden bevorzugte Funktionen des Datenübertragungssystems und der Vorrichtung zur Durchführung des Verfahrens beispielhaft erläutert.

Vorzugsweise führt ein Proxy Server im Auftrag eines Clients einen Auf- und Abbau von TCP/IP-Verbindungen durch. Der Proxy Server wartet auf Anfragen von Clients (zum Beispiel von WWW- Browsern) innerhalb eines durch eine Firewall geschützten Netzwerks und leitet die Anfragen zu entfernten Servern außerhalb der Firewall weiter. Die Antworten der räumlich getrennten Server werden ebenfalls vom Proxy Server gelesen und zum Client zurückgeschickt.

Eine Firewall ist vorzugsweise eine Soft- und/oder Hardware, die nur eingeschränkt öffentliche Computer und/oder Netzwerkbereiche/z. B. lokale Firmennetze) vor Angriffen "von außen" schützt.

Vorzugsweise übernimmt der Secure Proxy-Server zusätzlich weitere Aufgaben, um den Datenverkehr zwischen den beteiligten Instanzen gegen äußere Zugriffe zu schützen.

Da die dargestellten Proxy-Server SPC und SPS besonders gesichert sind, werden sie als Secure Proxy bezeichnet. Sämtliche Ausführungen zu dem Secure Proxy beziehen sich auf wenigstens einen der genannten Proxy-Server. Es ist besonders vorteilhaft, dass mehrere - im dargestellten Fall beide - Proxy-Server SPC und SPS die dargestellten Eigenschaften aufweisen. In einfachen Ausführungsformen weist wenigstens ein Proxy-Server die dargestellten Eigenschaften auf.

Da nicht alle Ausführungsformen der Erfindung es erfordern, dass beide Proxy-Server SPC und SPS die dargestellten Sicherheitsmerkmale aufweisen, wird nachfolgend ein einzelner Secure Proxy SP dargestellt. Bei diesem Secure Proxy kann es sich um einen oder mehrere der eingesetzten Proxy-Server handeln. Vorzugsweise weist wenigstens einer der Proxy-Server die nachfolgend genannten Merkmale des Secure Proxy auf, noch vorteilhafter ist es jedoch, dass mehrere, beziehungsweise alle Proxy-Server die Merkmale des Secure Proxy SP aufweisen.

Als Sicherheitsdienste werden im bevorzugten Fall von SSL- Verbindungen Authentisierung, Verschlüsselung und Integritätsprüfung zur Verfügung gestellt.

SSL bezeichnet Secure Sockets Layer. Hierbei handelt es sich insbesondere um eine auf TCP/IP basierende Schicht, über die die Verschlüsselung und Integrität von Daten und die gegenseitige Authentisierung der Kommunikationspartner gewährleistet wird.

Der SP wird vorzugsweise als ein Hintergrundprozess implementiert, der zweckmäßigerweise auch dann aktiv ist, wenn kein Anwender aktiv im System arbeitet. Ein solcher Hintergrundprozess kann verschiedene Funktionen wahrnehmen und entspricht in einer besonders zweckmäßigen Implementation dem sogenannten "Daemon" in dem Computersystem UNIX.

Es ist möglich, den Aufbau der sicheren Verbindungen durch Softwareroutinen, die vorzugsweise in PSE realisiert sind, umzusetzen.

Ein Aufbau der sicheren Verbindungen über Smart Cards ist jedoch mit dem besonderen Vorteil einer noch höheren Sicherheit verbunden. Vorzugsweise sind die Smart Cards mit Sicherheitsmerkmalen ausgestattet. Eine Vielzahl derartiger Sicherheitsmerkmale ist bekannt und kann hier eingesetzt werden. Um eine besonders hohe Datensicherheit zu gewährleisten, ist es zweckmäßig, dass die Smart Cards entsprechend den Anforderungen des Signaturgesetzes gestaltet sind und daher auch als Signaturkarten dienen. Als Authentisierungsmechanismus dient das SSL-Handshake- Protokoll, bei dem auch ein Symmetrischer Schlüssel zum Ver- und Entschlüsseln der im Folgenden zwischen den beiden Kommunikationspartnern auszutauschenden Nutzdaten ausgehandelt wird.

Die Smart Cards können verschiedene Funktionen erfüllen, wobei zur Realisierung von unterschiedlichen Funktionalitäten ein Austausch der im Vergleich zu der Rechnerhardware einfach herzustellenden Smart Cards möglich sind. Vorteilhafterweise führen die Smart Cards Funktionen entsprechend dem SSL- Handshake-Protokoll durch. Hierbei ist es vorteilhaft, dass das SSL-Handshake-Protokoll beim Berechnen eines symmetrischen Schlüssels auf einen oder mehrere asymmetrische Schlüssel zurückgreift, die vorteilhafterweise auf den Smart Cards der Kommunikationspartner gespeichert sind.

Nachfolgend sind bevorzugte Eigenschaften des Client-Proxy dargestellt.

Der SP-Client wird unter Windows als Hintergrund-Prozess über den Autostart-Mechanismus beim Logon-Prozess und unter UNIX als Daemon-Prozess gestartet. Die zu überwachende PSE wird vom SP aus der Datei "comport.cfg" gelesen, die sich auf allen Plattformen im Installationsverzeichnis des Programms befindet. Im Falle der Windows-Versionen kann "comport.cfg" auch sogenannte "User-friendly names" enthalten.

Bei den User-friendly-names handelt es sich vorzugsweise um systemspezifische Zeichenketten, die eine Personal Security Environment (PSE) referenzieren.

Auf den UNIX-Pattformen wird der Benutzer sofort zur Eingabe der zur in "comport.cfg" spezifizierten PSE gehörenden PIN aufgefordert, unter Windows geschieht dies vorzugsweise erst beim Aufbau einer SSL-Verbindung.

Die PSE stellt einen digitalen Container für persönliche Daten/z. B. Zertifikate, private Schlüssel) dar, der in Form von Software (sog. Soft-PSE) oder Hardware (Smart Card) realisiert ist.

Vorzugsweise wird eine Personal Identification Number (PIN)eingesetzt. Diese Nummer sollte der Benutzer einer Smart Card eingeben, bevor er mit den auf der Smart Card gesichert gespeicherten Informationen arbeiten kann.

Die PIN behält ihre Gültigkeit für einen kurzen, vorzugsweise vorgegebenen Zeitraum von beispielsweise fünf Minuten nach dem letzten Datentransfer. Nach Verstreichen von fünf Minuten ohne Datentransfer löscht der SP Client die PIN aus Sicherheitsgründen aus dem Speicher, so dass bei erneutem Initialisieren eines SSL-Handshake-Protokoll-Prozesses die PIN neu eingegeben werden soll.

Nun liest der SP-Client die Datei "client.cfg", die sich im selben Verzeichnis wie die Datei "comport.cfg" befindet und übernimmt deren aktuelle Einstellungen.

Beim Entfernen der Smart Card aus dem Terminal laufen alle über den SP-Client laufenden SSL-Verbindungen aus. Insbesondere werden keine neuen SSL-Verbindungen mehr vom SP angenommen. Unter UNIX beendet sich der SP-Client anschließend.

Im Rahmen des SSL-Handshake-Protokolls erhält der SP-Client auch ein Zertifikat vom Server, welches er bei einem Directory Service (DIR) prüfen lässt.

Das Zertifikat beinhaltet eine Zuordnung einer natürlichen Person zu einem Asymmetrischen Schlüssel. Auf der Smart Card ist das Zertifikat des Inhabers der Smart Card als Datei abgelegt.

Der Directory Service (DIR) ist vorzugsweise ein Verzeichnis- Dienst, der Auskunft gibt über die Gültigkeit von Zertifikaten.

Die Konfigurationsdateien können abhängig von den Befugnissen eines Benutzers verschiedene Einträge enthalten. Sie bestimmen maßgeblich das Verhalten des SP Client.

Im Installationsverzeichnis des Dienstes befindet sich die Datei, die nachfolgend beispielhaft als "comport.cfg", in der der bei der Installation ausgewählte PSE eingetragen ist; sie kann vom Systemadministrator mit Hilfe des Konfigurationswerkzeuges des SP-Client bearbeitet werden. Vorzugsweise hat der Systemadministrator auf diese Datei Lese- und Schreibrechte.

Zweckmäßigerweise verfügen sowohl der Client als auch der Secure Proxy SP über die Datei "comport.cfg", welche (zumindest unter UNIX - siehe unten) während des Installationsvorgangs erstellt wird. Sowohl beim Client Proxy als auch beim Server Proxy enthält die Datei den zu verwendenden COM-Port. Sie beinhaltet vorzugsweise die nachfolgend wiedergegebenen Datenfelder.
# COM Port für Karten-Terminal:
COM_PORT = 1
USER_FRIENDLY_NAME = "Ultimaco Cardman 0" USE
USER_FRIENDLY_NAME = "XYZ"
USER_FRIENDLY_NAME = "ABC"

Als COM-Port wird ein Integer angegeben, der die zu benutzende serielle Schnittstelle spezifiziert, über die ein angeschlossenes Karten-Terminal angesprochen werden soll.

Für viele UNIX-Betriebssysteme ist die Angabe von "COM_PORT" obligatorisch, da alle mit "COM_PORT" spezifizierten Slots direkt über ein Application Programming Interface (API) angesprochen (und deswegen auch exklusiv für den SP gelockt) werden.

Hierbei handelt es sich insbesondere um ein Card Terminal Application Programming Interface (CT-API) oder eine andere Programmier-Schnittstelle, über die der Karten-Leser, der eine Smart Card enthält, von Programmen aus angesprochen werden kann.

Andere Programme, beispielsweise der Windows-Programmfamilie, eröffnen die zusätzliche Möglichkeit der User-friendly names. Solchermaßen referenzierte PSEs werden vom Smart Card Resource Manager verwaltet, bei dessen Verwendung auch mehrere Applikationen mit der PSE arbeiten können. Mehrfach genutzte Karten-Leser sollten deswegen immer vom Secure Proxy über User-friendly names angesprochen werden. Unter den verschiedenen UNIX-Betriebssystemen gibt es keinen Smart Card Resource Manager, hier sollte das Card Terminal über "COM_Port" ausgewählt und über CT-API angesprochen werden.

Wegen der Verwendung von User-friendly names unter Windows wird die Datei "comport.cfg" hier nur eingeschränkt beim Installations-Vorgang erzeugt, da das Installationsprogramm die User-friendly names nur eingeschränkt kennen kann. Vielmehr erzeugt unter Windows der SP beim ersten Start die "comport.cfg" selbst.

Wie das obige Beispiel zeigt, kann die unter Windows durch den SP selbst generierte "comport.cfg"-Datei mehrere Einträge enthalten. Die vom SP zu verwendende PSE wird deswegen durch das Key Word "USE" gekennzeichnet. Wurde "comport.cfg" dabei unter Windows vom SP generiert, wählt der SP selbst eine PSE aus, sofern diese Wahl eindeutig ist. Er geht bei der Auswahl der PSE nach der folgenden Regel vor: Enthält "comport.cfg" nur einen Eintrag, so wird dieser ausgewählt. Enthält "comport.cfg" zwei Einträge, einer von beiden referenziert jedoch die Soft-PSE, so wird der andere Eintrag ausgewählt. Alle anderen möglichen Fälle ergeben ohne manuelle Nachkonfiguration mit dem Konfig-Tool eine unbestimmte Konfiguration des SP, und ein Start des SP mit der nur eingeschränkt-konfigurierten "comport.cfg" erzeugt eine Fehler-Meldung.

Im selben Verzeichnis wie "comport.cfg" befindet sich auch die Datei "client.cfg", die vom Systemadministrator ebenfalls mit Hilfe des Konfigurationswerkzeuges des SP-Client bearbeitet werden kann. Die Datei "client.cfg" beinhaltet die aktuellen Einstellungen für den SP-Client. Der Systemadministrator hat auf diese Datei Lese- und Schreibrechte.

Ein Beispiel für die Datei "client.cfg" ist nachfolgend wiedergegeben.
# Proxy Modus:
MODE = NORMAL
# Service Port des Proxies für das Konfigurationswerkzeug:
SERVICE_PORT = 4711
# Log File:
LOG_FILE = C:\SECUREPROXY\SP.LOG
# Inaktivitätszeit in Sekunden:
INACTIVITY_TIME = 51665
# DPAG Directory Service als (IP:Port):
DIR = 1.2.3.4:7777
# Caching Proxy (IP:Port):
# optional
CACHING PROXY = 5.6.7.8:9999
# Liste abzusichernder URLs:
# auch Wildcards (* und?) möglich
SECURE_URL = *:/ / www.sicher.de/
SECURE_URL = http:/ / www.secure.com/
SECURE_URL = http:/ / www.safe.com/users/*
SECURE_URL = http:/ / www.*.??/
# Port Mapping: MAP something TO IP:Port:
MAP URL = http:/ / www.ferrari.it TO 10.11.12.13:1234
MAP URL = http:/ / www.alles.* TO 14.15.16.17:5678
MAP PORT = 6666 INSECURE TO 18.19.20.21:6667
MAP PORT = 80 SECURE TO server_sp.httpserver.com:5080
MAP PORT = 21 SECURE TO server_sp.ftpserver.com:5021
MAP PORT = 81 INSECURE TO REQUESTED_URL HTTP

Die Darstellung zeigt Beispiele der eingesetzten Programmfunktionen in Scriptsprache. Die Datei "client.cfg" ist vorzugsweise in einer derartigen Scriptsprache geschrieben. Diese Datei enthält vorzugsweise wenigstens eines der nachfolgenden Elemente, wobei ein Einsatz sämtlicher der nachfolgend dargestellten Elemente besonders bevorzugt ist.

Ein derartiges Element ermöglicht die Auswahl eines Secure Proxy Modus.

Um festzulegen, ob der Proxy im Rahmen eines Kommunikations- Rechners (KR) eingesetzt wird oder für andere Zwecke, wird hier die Variable "Mode" gesetzt. Diese kann einen der beiden Werte "KR" oder "NORMAL" enthalten.

Über den Kommunikations-Rechner (KR) werden Daten zwischen internen und externen Netzen der Zertifizierungsstelle ausgetauscht. Der Secure Proxy im KR-Modus bietet auf der Server-Seite Zusatzfunktionen wie zum Beispiel das Anfügen der Seriennummer des Client-Zertifikate als URL-parameter.

Ein weiteres Modul ist ein Service Port. Das Service Port wird vorzugsweise so spezifiziert, dass er den Port bezeichnet, auf dem der Secure Proxy Daten eines Konfigurationswerkzeuges, beispielsweise eines Konfigurationsproxys, empfängt. Vorzugsweise wird hierdurch auch der Übermittlungsweg festgelegt, auf dem das Konfigurationswerkzeug Daten an den Secure Proxy schickt. Vorzugsweise ist das Konfigurationswerkzeug der in Fig. 1 dargestellte Konfigurations-Proxy-Server KP1. Beispielsweise werden die Konfigurationsinformationen lokal gespeichert, wobei der Local Hoast in dem dargestellten Beispiel die IP- Adresse IP-Adresse 127.0.0.1 aufweist.

Eine weitere Datei enthält Zugriffsinformationen. Diese Datei wird auch als Log-Datei bezeichnet. Hierbei kann es sich selbstverständlich sowohl um eine selbständige Datei als auch um eine Unterdatei der Konfigurationsdatei handeln. Um auch außerhalb des EventLog Mechanismus bei Windows beziehungsweise des Syslog Mechanismus bei UNIX weitere Fehlermeldungen nach außen geben zu können, besteht hier mittels der Variablen "LOG_FILE" die Möglichkeit, eine Log- Datei anzugeben, in die Fehlermeldungen geschrieben werden können. Diese Datei dient zur Konfiguration des Gesamt- Systems und zur Fehlersuche, zum Beispiel auf einer anvisierten Netzwerk-Route, und kann im normalen Betrieb ausgeschaltet werden durch "LOG_FILE =".

Ein weiteres Datenelement der Konfigurationsdatei ist eine Inaktivitätszeit. Der Variablen "INACTIVITY_TIME" wird mit dem Gleichheitsoperator "=" ein Wert in Sekunden zugeordnet. Jeder Online-Verbindung ist ein Timer Thread zugeordnet, der die Zeit misst, die seit dem letzten Datenverkehr verstrichen ist. Überschreitet diese Zeit die Inaktivitätszeit, so bricht der Client Proxy die Verbindung ab. Falls der Proxy im KR- Modus arbeitet, wird dieser Wert ignoriert. Der Wert "0" bedeutet "keine Inaktivitätszeit".

Ferner ist es vorteilhaft, dass die Konfigurationsdatei eine Verzeichnisstruktur enthält, die auch als ein Verzeichnisdienst bezeichnet wird. Statt eines intern enthaltenen Verzeichnisdienstes ist jedoch ein Zugriff auf einen externen Verzeichnisdienst gleichermaßen möglich. Zur Verifikation von Zertifikaten wird vorzugsweise der Verzeichnisdienst von Signtrust genutzt. Dazu sollte vorzugsweise der Verzeichnis-Dienst von Signtrust im Format "<IP-Adresse<:<Port<" per Gleichheitsoperator "=" der Variablen "DIR" zugewiesen werden. Der Client Proxy kann so das Zertifikat des Server Proxys, welches dieser im Rahmen des SSL-Handshake-Protokoll-Prozesses an den Client Proxy schickt, bei DIR prüfen.

Ferner ist es zweckmäßig, einen Zugriff auf eine weitere Speichereinheit zu ermöglichen. Eine bevorzugte Ausführungsform dieser Speichereinheit wird nachfolgend als Caching Proxy bezeichnet. Sind keine Informationen zur Absicherung einer Verbindung in der Datei client.cfg spezifiziert, so leitet der Client SP die Informationen transparent weiter. In diesem Fall kann durch die Angabe eines Caching Proxies der Client SP veranlasst werden, diese Informationen an diesen weiterzuleiten. Hierzu sollte der Caching Proxy im Format "<IP-Adresse<:<Port<" per Gleichheitsoperator "=" der Veriablen "CACHING_PROXY" zugewiesen werden. Die Angabe dieser Information ist optional, da eventuell auch kein solcher Proxy vorhanden ist.

Es ist zweckmäßig, zwischen Zugriffsquellen zu unterscheiden, die abzusichern sind und solchen, bei denen eine Absicherung nur eingeschränkt erforderlich ist. Nachfolgend wird der Verfahrensablauf für abzusichernde Resourcen dargestellt. Alle Zeichenketten, deren Anforderung zu einer gesicherten Übertragung führen sollen, werden per Zuweisungsoperator "=" einer Listenvariablen "SECURE_URL" hinzugefügt. Auch die Angabe von Wildcards (Verwendung von "*" für beliebige Ausdrücke beliebiger Länge und von "?" für beliebige einzelne Zeichen) ist möglich.

Bei der Zeichenkette handelt es sich vorzugsweise um einen Uniform Resource Locator (URL), der eine in einem Datennetz, vorzugsweise im Internet zu suchende Resource in eindeutiger Weise beschreibt. Die Zeichenkette wird vom Browser in eine HTTP-Anfrage (HTTP-Request) eingebettet zum Server gesendet. In den HTTP-Request können sowohl auf Client- als auch auf Server-Seite Zusatzinformationen als sog. URL-Parameter eingefügt werden.

Der Ausdruck "SECURE_URL = http:/ / www.secure.com/" steht dabei für die Absicherung der Daten, die auf diesen Request zurückkommen, nur eingeschränkt jedoch für die Verschlüsselung aller auf diesem Web Server liegenden Seiten; dafür ist es notwendig, das Wildcard Zeichen "*" an die Zeile anzuhängen: "SECURE_URL = http:/ / www.secure.com/*".

Ein bevorzugtes Protokoll ist das HyperText Transfer Protocol (HTTP). Auf der Basis dieses Protokolls werden im Internet Daten transferiert, die vorzugsweise in einem Browser visualisiert werden.

Es ist zweckmäßig, verschiedene Daten- und Dateiformatskonvertierungsroutinen einzusetzen, insbesondere Port- und URL-Mapping. Spezielle Ports und URLs können hierdurch komplett auf eine neue IP-Adresse und einen neuen Port umgemappt werden. Dieses Feature ist beispielsweise für den telnet-Service interessant, bei dem kein Proxy angegeben werden kann. Stattdessen sollte man per telnet eine Verbindung zum Client Proxy aufnehmen, der den telnet-Port ummappt auf den Server Proxy der Remote Machine, auf der seinerseits ein Remapping des Ports vorgenommen wird auf den ursprünglich gewollten telnet-Peer. Oder, allgemein ausgedrückt: der SP verfügt über ein Port-Remapping, welches eine Umleitung eines Ports X der Client-Seite auf einen Port Y (und IP-Adresse Z) auf der Server-Seite ermöglicht. Hierzu existieren sowohl für den Client Proxy als auch für den Server Proxy je eine Datei, in der festgelegt ist, an welchen Ports der jeweilige Proxy auf eingehende Anfragen wartet. Die Datei "client.cfg" enthält eine Liste aller Ports, an denen ein Client Proxy auf eingehende Anfragen wartet. Zunächst wird diese Liste verwendet, um für jeden angegebenen Port einen TCP/IP-Socket (mit lokaler IP-Adresse und angegebenem Port) zu eröffnen. Sofern in der Datei eine Zuordnung des jeweiligen Ports zu einer Zieladresse (IP-Adresse und Port) existiert, wird diese für das Port-Remapping verwendet. Der Client Proxy ist somit in der Lage, Anfragen an ein und dieselbe lokale IP-Adresse mit verschiedenen Ports auf Anfragen an verschiedene IP-Adressen abzubilden (Remapping). Ist keine Zuordnung vorhanden, erhält der Client Proxy die Zieladresse des Server Proxies aus der Angabe des Caching Proxy.

Für alle erwähnten Features sollte jedoch bei der jeweils verwendeten Client-Applikation (z. B. Browser, Telnet- Terminal) die Adresse des Client Proxies als Proxy eingetragen werden. Für den Fachmann ist es selbstverständlich, dass sowohl URLs als auch komplette Ports umgemapt werden können, insbesondere auf einen entfernten Proxy Server, der im gewohnten Format "<IP-Adresse<:<Port<" angegeben werden sollte. Beim Mapping von URLs sind Wildcards möglich, wie sie auch bei der Absicherung bestimmter URLs verwendet werden können.

Ob für eine gemappte Verbindung eine Verschlüsselung stattfinden soll, hängt beim Mappen eines Ports beispielsweise vom Schlüsselwort "SECURE" oder "INSECURE" ab. Ist "SECURE" angegeben, so wird die Verbindung auf jeden Fall verschlüsselt. Ist "INSECURE" angegeben, so wird die Verbindung normalerweise nur eingeschränkt verschlüsselt. Ist jedoch weiterhin das Schlüsselwort "HTTP" angegeben, so wird versucht, die von der Benutzerapplikation geschickten Daten als HTTP-Anfragen zu deuten. Es wird die URL aus der Anfrage extrahiert; dann erfolgt ein Vergleich mit der "SECURE_URL" Liste. Findet sich die URL der Anfrage in dieser Liste, wird trotz der "INSECURE" Angabe bezüglich des Ports die Kommunikation verschlüsselt durchgeführt.

Ist statt eines Hostnamens und eines Ports das Schlüsselwort "REQUESTED_URL" angegeben, so sollte auch das Schlüsselwort "HTTP" vorhanden sowie der Port als "INSECURE" definiert sein. In diesem Fall werden die Daten, die an diesen Port gesendet werden, als HTTP-Request interpretiert, die URL aus diesem Request extrahiert und transparent an den Zielrechner weitergeleitet.

Falls eine sichere Verbindung zu einem Server bereits vorhanden ist, wird diese für den Datenaustausch vorzugsweise mehrfach verwendet.

Die Art der Verbindung kann dabei auf verschiedene Weise festgelegt werden.

Mit Hilfe des Konfigurationswerkzeuges kann der Benutzer eine Inaktivitätszeit angeben. Die Inaktivitätszeit wird im SP- Client Proxy durch einen Timer gemessen und als die Zeit definiert, die pro Online-Verbindung seit dem letzten Daten- Transfer zwischen SP-Client und Secure Proxy vergangen ist. Wird diese Zeitschwelle erreicht, wird die betreffende Online-Verbindung abgebrochen.

Im Falle des HTTP-Protokolls ist diese Inaktivitätszeit freilich von keinem besonderen Interesse, da beim HTTP- Datentransfer nur kurzfristig andauernde Verbindungen zustande kommen.

Beim Einsatz für den KR oder im KR-Modus wird diese Inaktivitätszeit nur eingeschränkt beachtet, da hier zum Einen ein einseitiger Verbindungsabbau durch den Secure Proxy ausreicht, um keine Verbindung zustande kommen zu lassen, und zum Anderen die Datei "client.cfg" auf Client Seite nur eingeschränkt vor Manipulationen geschützt ist.

Mittels eines Satzes von Umgebungsvariablen (unter Windows von System-Variablen) kann der SP Client auf spezielle System-Gegebenheiten abgestimmt werden. Die folgende Übersicht zeigt die Möglichkeiten des Umgebungs-Tunings auf.

Name der Umgebungsvariablen
Aufgabe/Zweck
"SQRP_PROXY_MODE"	"CLIENT" (für den Client-Modus)
"SQRP_USE_DIR"	"TRUE" oder "FALSE" (Zertifikat des Kommunikationspartners bei DIR prüfen lassen)
SQRP_READ_TIMEOUT	Integer, der die Wartezeit in Sekunden des SP bei Leseoperationen angibt; Default = 60

Nachfolgend wird eine bevorzugte Ausführungsform des Secure Proxies erläutert. In diesem besonders bevorzugten Fall wird ein spezieller Server in einem Rechner durch eine besondere Softwareroutine simuliert, so dass die erste Datenverarbeitungseinheit auch die Funktionen des Proxy- Servers erfüllt.

Der Secure Proxy wird beispielsweise unter Windows als Hintergrund-Prozess beim Logon-Prozess (durch den Autostart- Mechanismus) und unter UNIX als Daemon-Prozess im Hintergrund gestartet. Die vom Secure Proxy zu benutzende PSE wird vom Service aus der Datei "comport.cfg" gelesen, die sich im Installationsverzeichnis des Secure Proxys befindet.

Vorzugsweise fordert der Secure Proxy anschließend den Benutzer zur Eingabe der PIN auf, mit der die geschützten Resourcen der in der Datei "comport.cfg" spezifizierten PSE freigeschaltet werden können. Im Gegensatz zum SP Client wird beim Secure Proxy die PIN während der gesamten Laufzeit des Secure Proxy im Speicher gehalten.

Falls die Verifikation der eingegebenen PIN positiv verläuft - bei den Windows-Versionen wird dies erst beim ersten SSL- Handshake-Protokoll festgestellt -, aktiviert der Secure Proxy die Konfigurationsdaten aus der Datei "server.cfg" im Konfigurationsverzeichnis und übernimmt deren aktuelle Einstellungen.

Im Rahmen einer SSL-Authentisierungsphase erhält der Secure Proxy das Zertifikat vom Client, welches er bei DIR prüfen lässt.

Die Smart Card sollte dauerhaft im Karten-Leser verbleiben, da sonst der Secure Proxy nur eingeschränkt funktionsfähig ist. Beim Entfernen der Chipkarte aus dem Terminal beendet der Secure Proxy automatisch alle über ihn laufenden Aktionen. Insbesondere werden alle Online-Verbindungen abgebrochen. Der Secure Proxy sollte anschließend erneut gestartet werden: Es beginnt erneut eine Startphase mit PIN- Eingabe und -Verifikation, Zertifikatstest und Einlesen der Konfigurationsdatei "server.cfg".

Auf jedem Rechner, der als Secure Proxy bei einer durch SSL abgesicherten Verbindung fungieren soll, sollte ein Secure Proxy-Prozess im Hintergrund gestartet werden. Ein solcher Secure Proxy gleicht in seinem Aufbau dem SP-Client. Er erwartet Verbindungsanfragen von SP-Clients, führt die Authentisierung durch, empfängt die verschlüsselten Datenpakete, entpackt diese und leitet sie an die "regulären" Web-Server weiter. Ebenso werden die Antworten der Server an die entsprechenden SP-Clients weitergeleitet.

Der in Verbindung mit dem Secure Proxy verwendete Web-Server sollte so konfiguriert sein, dass nur Zugriffe vom "localhost" (IP-Adresse: 127.0.0.1) möglich sind. Anderenfalls könnte der Mechanismus der sicheren Datenübertragung umgangen werden, in dem eine Client- Applikation (z. B. ein Browser) seine Anfrage direkt an den Web-Server richtet. Zusätzlich kann eine "Firewall" den entfernten Zugriff auf bestimmte Ports des Web-Servers verhindern.

Der Secure Proxy hat außer der Weiterleitung von Anfragen an den Web-Server und Weiterleitung der Antworten an den SP- Client auch die Überprüfung der Zugriffsrechte des Benutzers durchzuführen.

Beim Aufbau einer sicheren Verbindung erhält der Secure Proxy Informationen über den Benutzer des SP-Clients. Zur Überprüfung der Zugriffsrechte auf bestimmte URLs wird das bei der Authentisierung übertragene Zertifikat des Clients verwendet. Die Zertifikatsnummer sowie den Herausgeber des Zertifikats vergleicht der Secure Proxy mit den in der Datei "access.cfg" abgelegten Daten.

Ist der Besitzer des entsprechenden Zertifikats zugriffsberechtigt, das heißt, das Paar Herausgeber und Zertifikatsnummer ist in der Datei "access.cfg" der angefragten URL zugeordnet, leitet der Secure Proxy die HTTP- Anfrage an den Web-Server weiter. Anderenfalls wird eine entsprechende Fehlermeldung generiert und an den SP-Client in Form eines HTTP-Dokuments versendet.

In Bezug auf die Datei "comport.cfg" besteht auf der Server- Seite kein Unterschied zur Client-Seite.

Nachfolgend ist dargestellt, wie der Inhalt einer "server.cfg"-Datei aussehen kann. Je nach Systemkonfiguration weichen die individuellen Dateiinhalte voneinander ab.
# Proxy Modus:
MODE = KR
# Service Port des Proxys für das Konfigurationswerkzeug:
SERVICE_PORT = 4712
# Log File:
LOG_FILE = /var/log/secureproxy.log
# Inaktivitätszeit in (h : min):
INACTIVITY_TIME = 0 : 30
# DPAG Directory Service als (IP: Port):
DIR = 1.2.3.4:7777
# Liste abzusichernder URLs
# auch Wildcards (* und?) möglich
SECURE_URL = http:/ / www.sicher.de/users/*
SECURE_URL = http:/ / www.sicher.de/public/
SECURE_URL = *:/ / www.sicher.de/
SECURE_URL = http:/ / www.*.??/
# Port Mapping: MAP something TO Port
MAP SECURE PORT = 80 TO 5000 HTTP
MAP INSECURE PORT = 85 TO 5085

Jeder Server Proxy verfügt über eine Datei "server.cfg", welche dessen Basis-Konfiguration enthält. Die einzelnen Parameter werden nachfolgend näher erläutert: Die Datei "server.cfg" kann mit Hilfe der Konfigurations-Tools bearbeitet werden.

Um festzulegen, ob der Proxy im Rahmen des KRs eingesetzt wird oder auch mit Soft-PSEs arbeiten soll, wird in dem Secure Proxy Modus die Variable "MODE" gesetzt. Diese kann einen der drei Werte "KR", "WITHSOFTPSE" oder "Normal" enthalten.

Der Unterschied zwischen dem "NORMAL"-Modus einerseits und den Modi "WITHSOFTPSE" und "KR" anderseits liegt zum einen im unterschiedlichen Format inkludierter Dateien und zum anderen in der Modifikation des HTTP-Requests. Der "NORMAL"-Modus des Secure Proxy nimmt keine Modifikation des HTTP-Requests vor, und die beiden anderen Modi hängen die Seriennummer des Zertifikats des Kommunikationspartners als URL-Parameter an den HTTP-Request an. Der "KR"-Modus allerdings nur, wenn der String "raclient" im HTTP-request gefunden werden kann, der "WITHSOFTPSE"-Modus hingegen modifiziert den HTTP_Request generell.

In einem Service Port wird festgelegt, auf welchem Weg Nachrichten von dem Konfigurationswerkzeug Nachrichten an den Proxy sendet. Vorzugsweise stammen diese Nachrichten von dem Localhost.

Um auch außerhalb des eventLog Mechanismus bei Windows, beziehungsweise des Syslog Mechanismus bei UNIX, weitere Fehlermeldungen nach außen geben zu können, besteht hier mittels der Variablen "LOG_FILE" die Möglichkeit, eine Log Datei anzugeben, in die Fehlermeldungen geschrieben werden können.

Der Variablen "INACTIVITY_TIME" wird mit dem Gleichheitsoperator "=" ein Wert im Format "Stunden : Minuten" zugeordnet. Gültige Werte für die Inaktivitätszeit können zwischen einer Minute (0 : 01) und einem Tag (24 : 00) liegen. Im Server Proxy wird pro gesicherter Verbindung zu einem Client Proxy ein Timer gestartet, welcher die Inaktivitätszeit bezüglich einer Verbindung misst. Die Inaktivitätszeit wird als die Zeit definiert, die seit dem letzten Request des zugehörigen Client Proxies vergangen ist. Nach Ablauf des festgelegten Wertes für die Inaktivitätszeit wird jede Verbindung abgebaut, über die keine Datenübertragung stattgefunden hat.

Falls der Proxy im KR-Modus arbeitet, wird dieser Wert ignoriert.

Zur Verifikation von Zertifikaten wird der Verzeichnis-Dienst von Signtrust genutzt. Dazu sollte der Verzeichnisdienst von Signtrust im Format "<IP-Adresse<:<Port<" per Gleichheitsoperator "=" der Variable "DIR" zugewiesen werden. Der Server Proxy kann so das Zertifikat des Client Proxys, welches dieser im Rahmen des SSL-Handshake-Protokoll- Prozesses an den Server Proxy schickt, bei DIR prüfen.

Alle URLs, deren Anforderung zu einer gesicherten Übertragung führen sollen, werden per Zuweisungsoperator "=" einer Listenvariable "SECURE_URL" hinzugefügt. Auch die Angabe von Wildcards (Verwendung von "*" für beliebige Ausdrücke beliebiger Länge und von "?" für beliebige einzelne Zeichen) ist möglich.

Der Ausdruck "SECURE_URL = http:/ / www.secure.com/" steht dabei nur eingeschränkt für die Absicherung der Daten, die auf diesen Request zurückkommen, jedoch für die Verschlüsselung aller auf diesem Web Server liegenden Seiten; dafür ist es notwendig, das Wildcard Zeichen "*" an die Zeile anzuhängen:
"SECURE_URL = http:/ / www.secure.com/*".

Analog zu den abzusichernden URLs wird hier ein Umlenken sowie ein Absichern von Ports definiert. Ähnlich der Syntax in "client.cfg" wird für ankommende Daten auf einem Port angegeben, ob sie "SECURE" (sicher) oder "INSECURE" (unsicher) sein sollen. Anders geartete Anfragen werden abgelehnt. Ist ein Port als "In-SECURE" definiert, so kann es sein, dass der Proxy die Verbindung ablehnt, obschon das Schlüsselwort "HTTP" gegeben und die URL der HTTP-Anfrage in der Liste der abzusichernden URLs zu finden ist.

Vorzugsweise verfügen die Proxy-Server über eine Datei "access.cfg", welche die Zugriffsrechte auf Web-Server- Inhalte verwaltet. Anhand der bei der Authentisierung übertragenen Zertifikate der Clients wird die Zugriffsberechtigung überprüft. Die Datei enthält eine Gruppierung aller gültigen und zugriffsberechtigten Paare aus Herausgebern und Zertifikatsnummern. Neue Zertifikate und Gruppen können mittels der Konfigurationstools hinzugefügt und anschließend den abzusichernden Web-Inhalten zugewiesen werden.
[ACESS CAS]
CA_1 = "CA-1"
CA_2 = "CA-2"
CA_3 = "CA-3"
[ACCESS_GROUPS]
CHEF_ONLY = 123456789:"CA-1"
MINI_GROUP = 543216789:CA_1/432156789:CA_1
MAXI_GROUP = MINI_GROUP/987654321:CA_2/234567891:"CA-1"
WILDCARD_GROUP_1 = 1234*.*
WILDCARD_GROUP_2 = 1234*:CA_1/5678????:CA_2
WILDCARD_GROUP_3 = 1234???9:CA_3
KR_GROUP = include/etc/man-db-acl
FROM_FILE = include dynamic_group.cfg
VIP_GROUP = ALL:CA_1
[URL]
# abzusichernde URLs
# in Gruppe PUBLIC sind alle user, die sich vorher mit einem
# gültigen Zertifikat authentisiert haben
URL = http:/ / www.server.de/encrypted/users/chef/ALLOWED_TO
CHEF_ONLY
URL = http:/ / www.server.de/encrypted/public/ALLOWED_TO_PUBLIC
URL = http:/ / www.server.de/encrypted/mini/ALLOWED_TO_MINI_GROUP
URL = http:/ / www.server.de/encrypted/mini/ALLOWED_TO_MAXI_GROUP
URL = http:/ / www.from_file.de/*ALLOWED_TO_FROM_FILE
URL = http:/ / www.vip.de/*ALLOWED_TO_VIP_GROUP

Sie einzelnen Parameter werden nachfolgend erläutert: Unter dem Abschnitt [ACCESS_CAS] werden symbolisch Cas (Certification Authorities) definiert. In diesen Ausdrücken sind auch Wildcards ("*" "?") erlaubt.

Unter dem Abschnitt [ACCESS_GROUPS] werden alle Gruppen aufgelistet. Eine Gruppe enthält eine Menge von Paaren, bestehend aus Zertifikatsnummer und Herausgeber (CA), wobei auch Untergruppen erlaubt sind. Die einzelnen Paare sind durch den Separator "/" voneinander getrennt. Gruppennamen müssen zusammenhängend sein (keine Leerzeichen, Tabs) und dürfen nur eingeschränkt das Separatorzeichen enthalten. Neue Gruppen werden unter [ACCESS_GROUPS] eingefügt. Wie dargestellt, können bei der Spezifikation der Zertifikatsnummern auch Wildcards ("*" für eine beliebige Anzahl beliebiger Zeichen und "?" für ein beliebiges Zeichen) benutzt werden. Bei der Angabe des Herausgebers kann sowohl einer der symbolischen Namen aus ACCESS CAS verwendet werden als auch ein in Anführungszeichen gestellter normaler Name der CA.

Ein bevorzugter Verzeichnisdienst wird nachfolgend als CA dargestellt.

Für die Spezifikation aller Kunden einer CA kann auch das Key Word "ALL" verwendet werden. Das Statement "ALL_OF_HERBERT = AL:Herbert" etwa definiert eine Gruppe "ALL_OF_HERBERT", die alle Kunden der CA "Herbert" meint.

Alternativ kann eine Gruppe auch durch den Inhalt einer Datei spezifiziert werden. Diese Datei sollte dann zeilenweise die Paare bestehend aus Zertifikatsnummer und CA Dname (in Anführungszeichen), getrennt wie oben durch einen Doppelpunkt, enthalten. Diese Verfahrensweise macht es leichter, automatisch generierte Listen in die Überprüfung einzubinden. Hierzu wird das Schlüsselwort "include" verwendet. Die unkludierte Datei besteht aus einzelnen Zeilen der Form
<CertNr<:<Issuer Dname<:<Flag<:<Hashwert<

Bei einer bevorzugten Verschlüsselung, beziehungsweise bei einer bevorzugten nicht rückgängig machbaren Datenoperation, wird ein Hash-Wert gebildet. Die Hash-Wert-Bildung erfolgt durch ein mathematisches Verfahren, bei dem eine zu einem Datenstrom eindeutig zuordnende Zeichenkette berechnet wird. Ein Beispiel für ein Hash-Verfahren ist SHA1.

<CertNr< und <Issuer Dname< bezeichnen die Seriennummer und den Herausgeber des Zertifikats. <Flag< steht für eine Zahl, die "0" oder "1" sein kann. Dabei steht "0" für die Information, dass es sich bei dem spezifizierten Zertifikat um ein SigG-Zertifikat einer Smart Card handelt. Das Feld <Hashwert< inklusive des trennenden Doppelpunktes entfällt dann. Ist für <Flas< der Wert "1" angegeben, dann handelt es sich beim Eintrag um die Kennzeichen einer Soft-PSE, und das Feld <Hashwert< ist erforderlich und spezifiziert den Hash- Wert über den öffentlichen Schlüssel des Soft- PSE Zertifikates. Der Hashwert ist dabei mittels SHA1 zu generieren und in der Base-64 kodierten Darstellung hier einzugeben. Beispiele:

12345678:"cn = DPAG CA1"

Dieses Beispiel spezifiziert einen Teilnehmer im KR- oder Normal-Modus.

12345678:"cn = DPAG CA1":0

Dieses Beispiel spezifiziert einen Teilnehmer im Soft-PSE- Modus, der ein SigG-Zertifikat besitzt.

12345678:"cn = Hinz und Kunz":1:abcdefghijklmnopqrst

Dieses Beispiel spezifiziert einen Teilnehmer im Soft-PSE- Modus, der kein SigG-Zertifikat besitzt und via Hashwert identifiziert wird.

Unter dem Abschnitt [URL] werden alle URLs aufgelistet und der entsprechenden Gruppe zugeordnet. Nur Mitglieder dieser Gruppe sind berechtigt, auf die entsprechenden Web-Inhalte zuzugreifen. Neue URLs werden unter [URL] eingefügt.

Nachfolgend werden dynamisch sich ändernde Zugriffslisten auf der Server-Seite dargestellt.

Ein auf der Server-Seite oft vorkommendes Problem ist die Dynamik bei der Gruppe zugriffsberechtigter Personen auf eine bestimmte Resource (URL). Da aber die Datei "access.cfg" nur einmal beim Start des SP Servers von diesem eingelesen wird, sind Modifikationen an dieser Datei erst nach einem Neustart des SP Server wirksam.

Die Möglichkeit, Zugriffe auf eine URL trotzdem ohne Secure Proxy-Neustart dynamisch zu ändern, bietet die Definition einer zugriffsberechtigten Gruppe über eine von "access.cfg" inkludierte Datei.

So wird etwa in der Sektion "[ACCES_GROUPS]" von "access.cfg" aus obigem Beispiel die Gruppe "FROM_FILE = include dynamic_group.cfg" eingetragen, deren Mitglieder sich aus der Datei "dynamic_group.cfg" rekrutieren. Dieser Gruppe wird in der Sektion "[URL]" der Zugriff auf "www.from_file.de/*" gestattet. Bei jeder Zugriffskontrolle auf "www.from file.de/*" prüft der SP Server, ob sich das Modifikationsdatum der Datei "dynamic_group.cfg" geändert hat. Sollte dies der Fall sein, so wird vor Auswertung der Zugriffsrechte diese Datei vom Secure Proxy Server neu eingelesen und damit neu hinzugekommene Einträge neu berücksichtigt. Der SP Server sollte allerdings nur eingeschränkt neu gestartet werden.

Ferner ist es zweckmäßig, auf der Seite der zweiten Datenverarbeitungseinheit, insbesondere falls diese Informationen über Web-Seiten überträgt, VIP-Bereiche einzurichten.

Speziell zum Einrichten von VIP-Bereichen - also Resourcen, die ausschließlich den Kunden einer bestimmten CA zugänglich sein sollen - wurde das Key Word "ALL" eingeführt.

So wird etwa in der Sektion "[ACCESS_GROUPS]" von "access.cfg" aus obigem Beispiel die Gruppe "VIP_GROUP = ALL:CA_!" eingeführt, die alle Kunden der CA "CA_1" meint. In der "[URL]"-Sektion wird die URL www.vip.de/* genau diesen Kunden der "CA_1" ausschließlich zugänglich gemacht.

Mit Hilfe des Konfigurationswerkzeuges kann der Benutzer (hier: Server-Administrator) in der Datei "server.cfg" eine Inaktivitätszeit angeben. Im Secure Proxy wird pro gesicherter Verbindung zu einem SP-Client ein Timer gestartet, welcher die Inaktivitätszeit bezüglich der festgelegten Gültigkeitsdauer misst. Die Inaktivitätszeit wird als die Zeit definiert, die seit dem letzten Datentransfer zum zugehörigen SP-Client vergangen ist.

Bei Überschreitung der Inaktivitätszeit wird die sichere Verbindung zum entsprechenden SP-Client unterbrochen. Erfolgt jedoch innerhalb der Inaktivitätszeit eine neue Anfrage an den Server Proxy, so wird der Timer zurückgesetzt und dieser beginnt erneut mit seiner Zeitmessung.

Nach dem Abbruch einer speziellen Verbindung wird bei einer erneuten Anfrage durch den entsprechenden Client eine neue - falls entsprechend konfiguriert - durch SSL gesicherte Verbindung aufgebaut. Da die PIN beim Server Proxy dauerhaft gespeichert wird, muss diese nicht bei dem nun erforderlichen SSL-Handshake-Protokoll erneut eingegeben werden.

An dieser Stelle wird eine Gesamtübersicht über die Parameterisierung der Laufzeitumgebung des SP Server gegeben.

Mittels eines Satzes von Umgebungsvariablen (unter Windows NT von System-Variablen) kann der SP Server auf spezielle System-Gegebenheiten abgestimmt werden. Die folgende Übersicht zeigt die Möglichkeiten des Umgebungs-Tunings auf.

Name der Umgebungsvariablen
Aufgabe/Zweck
"SQRP_PROXY_MODE"	"SERVER"(für den Server Modus)
"SQRP_USE_DIR"	"TRUE" oder "FALSE" (Zertifikat des Kommunikationspartners bei DIR prüfen lassen)
SQRP_READ_TIMEOUT	Integer, der die Wartezeit in Sekunden des SP bei Leseoperationen angibt; Default = 60
SQRP_WRITE_TIMEOUT	Integer, der die Wartezeit in Sekunden des SP bei Schreiboperationen angibt; Default = 30
SQRP_USE_ITO	"TRUE" oder "FALSE" (ITO-Überwachung ein- und ausschalten)

Die Installation der Softwaremodule wird unter Windows durch das Setup-Programm "InstallShield" und unter UNIX durch die betriebssystemspezifischen Package Handler realisiert und verläuft weitestgehend automatisch.

Durch Anklicken des Programmes setup.exe wird der Installationsvorgang gestartet.

Nach der Bestätigung des Begrüßungsdialoges durch die Schaltfläche "weiter" gelangt man zum Auswahldialog für den Zielordner der Installation. Ohne explizite Auswahl eines Ordners, erfolgt die Installation in das Verzeichnis c:\Programme\DPAG Secure Proxy\SQRP\.

In einem Abschlussdialog hat der Benutzer die Möglichkeit zu entscheiden, ob ein Neustart nach dieser Installation erfolgen soll oder nicht. Wird ein Neustart ausgelöst, so wird dabei der SP automatisch als Hintergrundprozess gestartet.

Wird beim Abschlussdialog kein Neustart gewünscht, so kann der Anwender den SP jederzeit manuell starten.

Die Installation erfolgt bei HP-UX über den HP-UX eigenen Software Depot Installer swinstall.

Eine Installation ist durch einen speziellen Installer, beispielsweise einen HP-UX Installer möglich. Hierbei werden Konfigurationsdateien in einem Inhaltsverzeichnis konfiguriert und ein SQRP installiert.

Die Installation erfolgt bei Computern des Typs Sun-Solaris über den Solaris eigenen Software Package Installer. Dieser wird mit folgendem Befehl aufgerufen:
pkgadd -d. -a noask/cdrom/cdrom0/SQRP_Server- 1.0.i86pc.Solaris.2.7

Der Fachmann weiß, wie er die dazu erforderlichen Schritte, beispielsweise mit einem Einloggen als root-user durchführt.

Bei Einsatz als Hintergrund-Prozess unter Windows wird durch die Installation mit InstallShield der Secure Proxy unter Windows als automatisch beim Systemstart startender Hintergrund-Prozess eingerichtet.

Sollte der SP aus irgendeinem Grund beendet worden sein, so kann er jederzeit über den Start-Button von Windows (Start- Programme) manuell gestartet werden.

Unter Windows ist es möglich, den SP so zu konfigurieren, dass er den Windows Smart Card Resource Manager benutzt. Ansprechbare Card Terminals werden dann als User-friendly names spezifiziert. Um diese User-friendly names kennenzulernen, kann der SP-Client unter Windows zunächst ohne die Datei "comport.cfg" gestartet werden. Er schreibt diese Datei, die nun alle User-friendly names enthält, die das System bereitstellt, dann in sein Installationsverzeichnis und beendet sich.

Bei einem Einsatz als Windows-Hintergrundprogramm kann der Secure Proxy über ein geeignetes Menü, insbesondere ein kontext-sensitives Menü, starten.

Bei Einsatz als Daemon-Prozess unter UNIX wird im Installations-Verzeichnis des Secure Proxy das ausführbare Programm "SQRP" abgelegt.

Ein Neustart des Secure Proxies ist auch hier jederzeit möglich.

Nachfolgend werden geeignete Benutzerschnittstellen erläutert.

Das Erstellen und Bearbeiten der Konfigurationsdateien der Benutzerschnittstellen ist kein notwendiger Bestandteil der eigentlichen SP-Applikation, sondern wird beispielsweise mit dem in [SP_CfgDoc] dokumentierten Konfigurationswerkzeug durchgeführt.

Um die Datensicherheit zu erhöhen, enthält der Proxy Server möglichst wenige direkte Benutzerschnittstellen. Eine mögliche Benutzerschnittstelle ist ein Eingabedialog für einen geeigneten Code, insbesondere eine PIN. Die Schnittstelle dient zu der Eingabe der PIN für die verwendete Chipkarte, mit der sich der Benutzer identifiziert. Ohne erfolgreiche PIN-Eingabe wird der Secure Proxy beendet, beziehungsweise nur eingeschränkt gestartet.

War die eingegebene PIN korrekt, so wird dies in der Mitteilungszeile des Dialoges für ca. eine Sekunde bestätigt, bevor der Dialog geschlossen wird und der SP in den "normalen" Betriebszustand eintritt.

Konnte die eingegebene PIN nur eingeschränkt bestätigt werden, so wird eine entsprechende Meldung in der Mitteilungszeile des Dialoges ausgegeben mit der Aufforderung, die PIN-Eingabe zu wiederholen. Die Schaltfläche "ok" wird deaktiviert und wird erst wieder aktiviert, wenn eine PIN eingegeben wird.

Wurde für die aktuell verwendete Chipkarte mehrmals, beispielsweise zum dritten Mal eine falsche PIN eingegeben, so erscheint eine Meldung, dass die Anzahl der maximalen Fehlversuche erreicht wurde. Die Karte ist nun gesperrt und kann nur noch eingeschränkt verwendet werden.

Nachfolgend wird erläutert, wie der Secure Proxy rekonfiguriert wird. In dem dargestellten Beispiel erfolgt die Rekonfiguration des Secure Proxy durch einen Neustart. Dies ist besonders zweckmäßig, jedoch nicht notwendig.

Mit dem Konfigurationswerkzeug werden lediglich die in den Konfigurationsdateien gespeicherten Informationen eingegeben, beziehungsweise gewartet.

Das Einlesen dieser Konfigurationsinformationen erfolgt durch den Secure Proxy selbst. Dies geschieht entweder beim Start des SP oder kann durch Auswahl der Schaltfläche "Proxy rekonfigurieren" im Hauptmenü des Konfigurationswerkzeuges erzwungen werden. Der SP führt daraufhin einen kompletten Neustart durch, das heißt, alle Verbindungen werden zunächst beendet, anschließend verhält sich der SP wie beim Programmstart: Der PIN-Eingabedialog wird angezeigt. Nach Eingabe der korrekten PIN wird der Secure Proxy mit den nun aktuellen Konfigurationsinformationen gestartet.

Nach erfolgreicher Installation und erfolgreichem Start des SP geht dieser in seinen Wirkbetrieb über. Der SP läuft in seinem Wirkbetrieb autark.

Schwere Fehler führen zum Beenden des SP, da ansonsten die Sicherheitsfunktionalitäten bedroht sein können. Da der SP im reinen Wirkbetrieb (Proxy-Betrieb) keine Benutzerinteraktion vorsieht, werden die Fehlermeldungen nur protokolliert, aber nur eingeschränkt unmittelbar angezeigt. Eine Ausnahme bilden hier Fehlermeldungen, die dem Benutzer als HTML-Seite angezeigt werden, wenn dieser versucht hat, mit einem Web- Browser (Netscape Communicator, beziehungsweise Microsoft Explorer) eine URL auszuwählen, die für ihn in der Zugriffsliste des Secure Proxys ("access.cfg") nur eingeschränkt eingetragen ist, das heißt, für die er keine Berechtigung hat. In einem solchen Fall sendet der Secure Proxy eine Fehlermeldung als HTML-Seite an den SP-Client, die den Benutzer darüber informiert, dass der Zugriff verweigert wurde.

Bei mehreren Betriebssystemen, insbesondere bei Windows NT werden die Meldungen des SP im sogenannten Ereignisprotokoll verzeichnet. Über die folgenden Menüeinträge der Windows-NT Task-Leiste gelangt man zur Anzeige des Ereignisprotokolls: Start-Programme-Verwaltung (Allgemein)-Ereignisanzeige

Die Einträge des SP werden in der Kategorie Anwendungsprotokoll eingetragen. Die Einträge ihrerseits können Fehlermeldung, Warnungen und Informationsmeldungen darstellen.

Unter den UNIX-Betriebssystemen (Solaris, HP-UX, Linus) wurde die Protokollierung von Fehlermeldungen des SP durch Aufruf des Systembefehles "syslog()" realisiert. Die diesem Befehl übergebenen Meldungstexte werden vom Betriebssystem in die sogenannte Syslog-Datei geschrieben. Diese befindet sich beispielsweise bei Solaris im Verzeichnis (var/log/ und bei HP-UX im Verzeichnis /var/adm/syslog/.

Um Meldungen des SP, die in diese Datei geschrieben wurden zu betrachten, wird das Kommando "tail" in einer Shell verwendet. Die dabei erforderlichen Kommandoparameter sind in der nachfolgenden Tabelle aufgelistet:

Betriebssystem	Kommando, um die letzten 50 Meldungen abzurufen
SUN Solaris	tail -50/var/log/syslog
HP-UX	tail -50 /var/adm/syslog/syslog

Claims

1. Verfahren zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit (C) und einer zweiten Datenverarbeitungseinheit (S), dadurch gekennzeichnet, dass die Übertragung über mindestens einen zwischengeschalteten Proxy-Server (SPC; SPS) erfolgt, wobei der Proxy-Server Signaturinformationen erfasst, die Signaturinformationen mit wenigstens einem Teil der Daten verknüpft und hierdurch die Daten beglaubigt und/oder verschlüsselt.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Signaturinformationen einem digitalen Signaturschlüssel entsprechen.

3. Verfahren nach einem oder beiden der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass der Proxy-Server die Signaturinformationen von einer Smart- Card (SC1; SC2) liest.

4. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Proxy-Server (SP; SPC), der die Daten durch Verknüpfung mit der Signaturinformation authentisiert und/oder verschlüsselt, die verschlüsselten Daten an einen Authentisierungsserver (AS) übermittelt.

5. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass ein weiterer Proxy-Server (SPS), der mit der Signaturinformation authentisierte und/oder verschlüsselte Daten empfängt, die verschlüsselten und/oder authentisierten Daten an den Authentisierungs- Server (AS) überträgt.

6. Verfahren nach einem oder beiden der Ansprüche 4 oder 5, dadurch gekennzeichnet, dass der Authentisierungs-Server eine Authentisierungsinformation an den Proxy-Server (SP; SPC) sendet, der unter Einsatz der Signaturinformation die Daten verschlüsselt und/oder authentisiert.

7. Verfahren nach einem oder mehreren der Ansprüche 4 bis 6, dadurch gekennzeichnet, dass der Authentisierungs-Server die Authentisierungsinformation an den weiteren Server (SP; SPS) sendet, der die mit der Signaturinformation verschlüsselten und/oder authentisierten Daten empfängt.

8. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass ein Aufbau einer sicheren Datenverbindung mittels eines Authentisierungsmechanismus eingeleitet wird.

9. Verfahren nach Anspruch 8, dadurch gekenn zeichnet, dass ein Secure Sockets Layer- Handshake-Protokoll als Authentisierungsmechanismus dient.

10. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Proxy-Server (SPC) von der ersten Datenverarbeitungseinheit (C) als ein virtueller Rechner simuliert wird.

11. Verfahren nach einem oder mehreren der vorangegangenen Ansprüche, dadurch gekennzeichnet, dass der Proxy-Server (SPS) durch die zweite Datenverarbeitungseinheit (S) als ein virtueller Rechner simuliert wird.

12. Verfahren nach einem oder beiden der Ansprüche 11 oder 12, dadurch gekennzeichnet, dass der Proxy-Server (SPC; SPS) in einem geschützten Bereich der Datenverarbeitungseinheit (C; S) betrieben wird.

13. Proxy-Server mit einem Eingang zum Empfang von Daten von einer ersten Datenverarbeitungseinheit (C) und zur Übertragung der Daten an eine zweite Datenverarbeitungseinheit (S), dadurch ge kennzeichnet, dass der Proxy-Server eine Signaturinformation einliest, mit der Signaturinformation die Daten verschlüsselt und/oder authentisiert und die verschlüsselten und/oder authentisierten Daten an die zweite Datenverarbeitungseinheit (5) übermittelt.

14. Datenübertragungssystem zur Übertragung von Daten zwischen einer ersten Datenverarbeitungseinheit (C) und einer zweiten Datenverarbeitungseinheit (S), dadurch gekennzeichnet, dass die erste Datenverarbeitungseinheit (C) mit einem ersten Proxy-Server (SPC) verbunden ist, dass die zweite Datenverarbeitungseinheit (S) mit einem weiteren Proxy- Server (SPS) verbunden ist, dass der erste Proxy-Server (SPC) mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, dass der weitere Proxy-Server (SPS) mit Mitteln zum Verschlüsseln und/oder Authentisieren von Daten versehen ist, und dass zwischen dem ersten Proxy-Server (SPC) und dem weiteren Proxy- Server (SPS) verschlüsselte und/oder authentisierte Daten übertragen werden.

15. Datenübertragungssystem, nach Anspruch 14, dadurch gekennzeichnet, dass wenigstens einzelne Daten durch einen Authentisierungs-Server beglaubigt werden.