-
Die Erfindung betrifft ein Verfahren für einen browserbasierten lesenden und schreibenden Fernzugriff auf ein mit einer Verarbeitungseinrichtung und einer Speichereinrichtung ausgestattetes Hardware-Sicherheitsmodul (im Weiteren auch HSM), welches lokal mit einem computerbasierten Endgerät (im Weiteren auch CEG) genutzt wird. Entsprechend einem bevorzugten Anwendungsfall und einer entsprechenden Ausgestaltung des Verfahrens bezieht sich die Erfindung insbesondere darauf, technischen Einrichtungen einer autorisierten Zertifizierungsstelle die Möglichkeit zu verschaffen, im Wege eines solchen browserbasierten Fernzugriffs digitale Zertifikate und andere Daten auf einer lokal, beispielsweise mittels eines über eine USB-Schnittstelle gekoppelten Kartenlesers genutzten, als Smartcard ausgebildeten Signaturkarte abzulegen.
-
Elektronische Hardware-Sicherheitsmodule finden in der Praxis zur Absicherung digitaler Übertragungsvorgänge, aber auch zur Legitimierung im Wege einer elektronischen Kommunikation abgewickelter Rechtsgeschäfte eine immer stärkere Bedeutung und Verwendung. Im Hinblick auf elektronisch ausgeführte Rechtsgeschäfte werden in zunehmendem Maße HSM in Form von Signaturkarten eingesetzt, welche hierbei zur Erzeugung einer elektronische Unterschrift als Ersatz für die handschriftliche Unterschrift des Karteninhabers verwendet werden. Mit Blick auf den bevorzugten Einsatzzweck des erfindungsgemäßen Verfahrens zur Ablage elektronischer Zertifikate auf solchen Signaturkarten im Wege eines Fernzugriffs beziehen sich die weiteren Darstellungen im Zusammenhang mit der Beschreibung der Erfindung insbesondere auf den lesenden und schreibenden Fernzugriff auf Smartcards beziehungsweise Signaturkarten, ohne jedoch hierauf beschränkt zu sein. Vielmehr sei an dieser Stelle ausdrücklich darauf hingewiesen, dass das erfindungsgemäße Verfahren für den lesenden und schreibenden Fernzugriff auf lokal mit einem computerbasierten Endgerät genutzte Hardware-Sicherheitsmodule (HSM) im Grunde jedweder Art einsetzbar ist.
-
Gemäß der Erfindung erfolgt der Fernzugriff auf ein lokal mit einem CEG genutztes HSM, wie bereits ausgeführt, browserbasiert. Das heißt, das vorgenannte CEG, mit welchem das HSM lokal genutzt wird, führt einen Browser aus, über welchen, von dem CEG mittels des Browsers kontaktierte technische Einrichtungen einer dazu autorisierten Instanz (TEAZ - technische Einrichtungen autorisierte Zentralinstanz) Zugriff auf ein lokal mit dem CEG genutztes HSM, wie insbesondere eine Signaturkarte, erhalten. Allerdings ist es so, dass es lokal auf einem CEG ausgeführten Webbrowsern grundsätzlich nicht ohne weiteres möglich ist, auf Hardwareressourcen zuzugreifen, welche über entsprechende Schnittstellen mit dem jeweiligen, den Browser ausführenden computerbasierten Endgerät (CEG), wie beispielsweise einem PC, genutzt werden. Daher werden Signaturkarten gegenwärtig mit den für ihren bestimmungsgemäßen Gebrauch auf ihnen zu hinterlegenden digitalen beziehungsweise elektronischen Zertifikaten bei einer diese Zertifikate erzeugenden zentralen Instanz (Zertifizierungsstelle beziehungsweise CA - Certificate Authority) unmittelbar vor Ort mittels entsprechender technischer Einrichtungen der betreffenden zentralen Instanz mit den Zertifikaten beschrieben.
-
Jedoch wäre es im Hinblick auf die Möglichkeiten einer Arbeitsteilung zwischen den Erzeugern (CA) vertrauenswürdiger Zertifikate, den Herstellern von Signaturkarten beziehungsweise deren Konfiguration im Sinne des Beschreibens mit Zertifikaten vornehmenden Unternehmen und den Signaturkarten zur Nutzung ihrer Dienstleistungen ausgebenden Unternehmen oder Institutionen wünschenswert, hierbei über mehr Flexibilität zu verfügen.
-
Zumindest für einen lesenden Fernzugriff auf Signaturkarten und vergleichbare HSM gab es in der Vergangenheit bereits einige Lösungen. Gemäß einer solchen Lösung wurde dazu durch einen, von einem ein HSM verwendenden Endgerät ausgeführten Browser ein den Zugriff auf das HSM ermöglichendes Java-Applet gestartet. Jedoch wurde aus sicherheitstechnischen Erwägungen die Unterstützung des insoweit erforderlichen Java-Plugins im Grunde durch alle aktuell im Einsatz befindlichen Browser aufgekündigt.
-
Eine andere Lösung besteht in einem Zugriff auf eine externe Software mittels HTTP-Protokoll, wobei dafür durch die betreffende Software ein Webserver auf dem PC (dem das HSM lokal verwendenden Endgerät) bereitgestellt wird. Diese Lösung weist jedoch eine Reihe von Nachteilen auf. So muss der Kunde, also ein entsprechender Nutzer, das vorgenannte Programm nach der Abkündigung von JavaWebStart selbst starten. Zudem kann die Kommunikation bei dieser Lösung nicht verschlüsselt erfolgen, was bei einigen Browsern zu einer Warnung führt, wonach Webinhalte über eine unverschlüsselte Verbindung übertragen würden und daher nicht vertrauenswürdig seien. Zudem kann die gleichzeitige Kommunikation des Browsers mit mehreren Webseiten, nämlich mit einem ein jeweiliges Zertifikat bereitstellenden Webportal und der lokalen Anwendung, von einem Browser fälschlicherweise als CrossSiteScripting interpretiert und daher unterbunden werden oder zumindest zu einer Warnmeldung führen. Falls es nicht zur Erkennung eines vermeintlichen CrossSiteScripting kommt, erfolgt alternativ eine Weiterleitung von dem Webportal auf den Webserver der lokalen Anwendung sowie nach dem Abschluss des Datenaustauschs mit der Signaturkarte eine Weiterleitung zurück auf das Webportal. Jedoch kann hierbei je nach Konfiguration keine Kommunikation mit dem lokalen Webserver mittels HTTP möglich sein, sofern beispielsweise aller Netzverkehr des Browsers über einen zentralen Proxyserver geleitet wird.
-
Aufgabe der Erfindung ist es, eine Lösung bereitzustellen, welche einen lesenden und schreibenden Fernzugriff auf ein lokal mit einem computerbasierten Endgerät verwendetes Hardwaresicherheitsmodul, wie insbesondere eine Signaturkarte, auch unter Berücksichtigung der vorgenannten Randbedingungen und unter Vermeidung insoweit gegebener Nachteile ermöglicht. Hierzu ist ein entsprechendes Verfahren anzugeben.
-
Die Aufgabe wird durch ein Verfahren mit den Merkmalen des Patentanspruchs 1 gelöst. Vorteilhafte Aus- beziehungsweise Weiterbildungen des erfindungsgemäßen Verfahrens sind durch die Unteransprüche gegeben.
-
Das zur Lösung der Aufgabe vorgeschlagene Verfahren für einen browserbasierten lesenden und schreibenden Fernzugriff auf ein Hardware-Sicherheitsmodul (HSM), welches mit einem computerbasierten Endgerät (CEG) lokal genutzt wird, geht von einem HSM aus, welches zumindest eine Verarbeitungseinrichtung und eine Speichereinrichtung aufweist. Entsprechendes ist zum Beispiel bei Chipkarten beziehungsweise bei in der Form von Smartcards ausgeführten Signaturkarten gegeben. Das Verfahren geht weiterhin davon aus, dass der Fernzugriff auf das HSM durch technische Einrichtungen einer dazu autorisierten, zentralen Instanz (TEAZ) über einen auf dem vorgenannten CEG ausgeführten Browser ermöglicht wird, wobei die TEAZ ein zur Initiierung eines Datenaustausches zwischen dem TEAZ und dem HSM mittels des Browsers ansprechbares Webportal umfassen.
-
Erfindungsgemäß umfasst das Verfahren
- a) das Bereitstellen eines Startelements durch das Webportal, nämlich eines durch den vom CEG ausgeführten Browser visualisierten Bedienelements zum Starten einer Datenkommunikation zwischen den TEAZ und dem HSM,
- b) das Starten einer durch die TEAZ bereitgestellten, auf dem CEG innerhalb des Browsers als Skript ausgeführten App nach einer Betätigung des vorgenannten Startelements,
- c) den Aufbau eines gesicherten, Ende-zu-Ende verschlüsselten, über eine Native-Messaging Schnittstelle des vom CEG ausgeführten Browsers geführten Kommunikationskanals zwischen den TEAZ und dem HSM durch die App, wobei die Native-Messaging Schnittstelle durch die gemäß b) gestartete App mittels eines zur Laufzeit eingebundenen Native-Messaging Plugins des Browsers gesteuert wird,
- d) einen Datenaustausch zwischen den TEAZ und dem HSM über den sie verbindenden gesicherten Kommunikationskanal, wobei von den TEAZ an das HSM übertragene Nutzdaten in der Speichereinrichtung des HSM zur späteren Verwendung gespeichert werden.
-
Vorsorglich sollen an dieser Stelle die vorstehend, nachfolgend sowie in den Patentansprüchen zur Vereinfachung gebrauchten Abkürzungen und deren Bedeutung zusammenfassend nochmals wie folgt aufgeführt werden:
- HSM Hardware-Sicherheitsmodul, nämlich lokal an einem computerbasierten Endgerät verwendetes Hardware-Sicherheitsmodul mit Verarbeitungseinrichtung und Speichereinrichtung, wie beispielsweise an dem Endgerät mit einem Kartenlesegerät verwendete Signaturkarte,
- CEG computerbasiertes Endgerät, zum Beispiel PC, Workstation oder aber auch mobiles Endgerät, wie beispielsweise Laptop oder Tablet-PC,
- TEAZ technische Einrichtungen einer autorisierten zentralen Instanz, nämlich beispielsweise technische Einrichtungen einer insbesondere zur Erstellung vertrauenswürdiger Zertifikate autorisierten Stelle oder Behörde, wie einer Zertifizierungsstelle und damit grundsätzlich für einen Fernzugriff auf zur Aufnahme von Zertifikaten vorgesehene HSM autorisierte technische Einrichtungen, wobei diese Einrichtungen Hardware-Komponenten, wie insbesondere Server und Schnittstellen, sowie Software-Komponenten, wie durch Software auf als Hardware ausgebildeten Servern virtualisierte Server, Datenbanken, Steuerungssoftware, Kommunikationssoftware und Anwendungssoftware verschiedenster Art, umfassen.
-
Unter Bezug auf den angesprochenen Datenaustausch zwischen den TEAZ und dem HSM und auf die Speicherung von Nutzdaten in der Speichereinrichtung des HSM sei an dieser Stelle Folgendes ausgeführt. Bei den zwischen den TEAZ und dem HSM im Zusammenhang mit dem Ablauf der skriptbasierten App innerhalb des Browsers ausgetauschten Daten kann es sich um Daten sehr unterschiedlichen Typs handeln. Insoweit handelt es sich bei den Daten insbesondere um den Ablauf des Verfahrens betreffende Steuerdaten, durch welche die Kommunikation zwischen den TEAZ und dem HSM im Rahmen des Verfahrens gesteuert wird und die vorgenannten Einheiten einander Anforderungs- und Quittierungskommandos (wie beispielsweise Anforderung eines Zertifikats durch das HSM bei den TEAZ) übermitteln und andererseits um Nutzdaten, wie Daten, welche kryptographische Schlüssel oder Zertifikate repräsentieren.
-
Soweit Nutzdaten, wie beispielsweise die vorgenannten Zertifikate, an das HSM übermittelt und in dessen Speichereinrichtung gespeichert werden, werden die betreffenden Daten in dem HSM persistent und manipulationssicher gespeichert. Die entsprechende, dafür erforderliche Auslegung der Einheiten des HSM, nämlich der Verarbeitungseinrichtung und der Speichereinrichtung sowie deren Zusammenwirken, betrifft Gestaltungsfragen und Implementierungen des jeweiligen HSM, die als solches bekannt und nicht Gegenstand der Erfindung sind, so dass sie an dieser Stelle nicht Gegenstand weiterer Betrachtungen sein sollen.
-
Entsprechend dem bereits mehrfach angesprochenen Einsatzzweck des Verfahrens wird gemäß einer Ausbildungsform der Erfindung mittels dieses Verfahrens bei dem zwischen den TEAZ und dem lokal mit dem CEG verwendeten HSM erfolgenden Datenaustausch eine Signaturkarte konfiguriert oder rekonfiguriert. Hierbei werden in die Speichereinrichtung der in Form einer Smartcard ausgebildeten Signaturkarte ein oder mehrere durch das CEG über das Webportal bei den TEAZ angeforderte Zertifikate eingeschrieben. Im Zuge einer entsprechenden Verfahrensgestaltung wird zum Konfigurieren oder Rekonfigurieren der Signaturkarte durch deren Verarbeitungseinrichtung mindestens ein Schlüssel erzeugt und dieser Schlüssel in der Speichereinrichtung der Signaturkarte unter Zuordnung zu einem durch die TEAZ zu dem Schlüssel erzeugten Zertifikat abgelegt.
-
Vorzugsweise werden durch die Verarbeitungseinrichtung der Signaturkarte ein aus einem öffentlichen Schlüssel und einem geheimen Schlüssel bestehendes kryptographisches Schlüsselpaar gebildet und durch die TEAZ ein Zertifikat zu dem öffentlichen Schlüssel dieses Schlüsselpaares erzeugt. Der im Zusammenhang mit der Erläuterung des grundsätzlichen Verfahrensablaufs weiter oben sowie in dem Patentanspruch 1 genannte Verfahrensschritt d) umfasst hierbei zumindest Folgendes:
- d1) die Übermittlung von Daten von den TEAZ zum HSM, das heißt zu der Signaturkarte, welche ein die Verarbeitungseinrichtung zur Erzeugung eines Schlüsselpaares veranlassendes Steuerkommando ausbilden,
- d2) das Abspeichern des durch die Verarbeitungseinrichtung des HSM aufgrund des empfangenen Steuerkommandos erzeugten Schlüsselpaares in dessen Speichereinrichtung sowie die Übermittlung von Daten, welche den öffentlichen Schlüssel des durch die Verarbeitungseinrichtung des HSM erzeugten Schlüsselpaares repräsentieren, von dem HSM an die TEAZ,
- d3) die Übermittlung von Daten, welche ein durch die TEAZ zu dem empfangenen öffentlichen Schlüssel erzeugtes Zertifikat ausbilden, durch die TEAZ an das HSM,
- d4) das Abspeichern des von dem HSM zu dem erzeugten öffentlichen Schlüssel empfangenen Zertifikats in der Speichereinrichtung des HSM in Zuordnung zu dem öffentlichen Schlüssel.
-
Insbesondere mit Blick auf den zuletzt genannten Einsatzzweck, einer Übertragung von Zertifikaten und deren Speicherung auf oder in einem HSM, aber auch unabhängig davon, kann das Verfahren entsprechend einer möglichen Ausbildungsform der Erfindung so gestaltet sein, dass dem Starten der durch die TAEZ bereitgestellten, im Browser des CEG ausgeführten App die Eingabe einer Auftragsnummer vorausgehen muss. In der Praxis wird es hierbei so sein, dass die Möglichkeit einer Nutzung des erfindungsgemäßen Verfahrens das Bestehen eines Vertragsverhältnisses zwischen einem Nutzer des HSM und der die TAEZ unterhaltenden und betreibenden oder deren Unterhalt und Betrieb durch Partner (Provider) beauftragenden zentralen Instanz voraussetzt. Typischerweise (aber nicht zwingend) wird dabei ein entsprechendes Vertragsverhältnis derzeit noch auf schriftlichem Weg (beispielsweise auch unter Nutzung des Postversands zugehöriger Dokumente), das heißt insbesondere durch Unterschrift des Verwenders des HSM, begründet werden. Ruft dann der in einem solchen Vertragsverhältnis stehende Nutzer mittels eines das HSM lokal verwendenden CEG das Webportal in dem durch dieses CEG ausgeführten Browser auf, wird gemäß der hier betrachteten Verfahrensgestaltung eine Aufforderung zur Eingabe einer Auftragsnummer vom Browser visualisiert. Eine weitere Ausführung des Verfahrens setzt dann voraus, dass die Eingabe einer gültigen Auftragsnummer und deren Übermittlung an die TEAZ erfolgt sowie ein Abgleich mit einer von den TEAZ gehaltenen Auftragsdatenbank ergibt, dass zu der betreffenden Auftragsnummer tatsächlich ein Auftrag vorliegt.
-
Außer den im Hinblick auf den bevorzugten Einsatzzweck vorstehend genannten Zertifikaten können durch die TAEZ einer Zertifizierungsstelle oder einer anderen entsprechend autorisierten zentralen Instanz als Nutzdaten auch andere Daten, für deren Übertragung es eines gesicherten (Ende-zu-Ende verschlüsselten) Kommunikationskanals bedarf, an das HSM übertragen und durch dieses gespeichert werden. Zu denken ist hierbei beispielsweise an die Übertragung einer neuen Firmware für das HSM oder, sofern es sich bei dem HSM um ein durch mehrere Nutzer verwendbares Sicherheitsmodul handelt, an Daten für die Nutzerverwaltung. Daten der vorgenannten Art werden in diesem Zusammenhang auch als Nutzdaten angesehen.
-
Unabhängig von dem jeweiligen Einsatzzweck des Verfahrens kann dieses zudem so ausgestaltet sein, dass durch die gemäß dem Verfahrensschritt b) gestartete App zunächst eine Prüfung erfolgt, ob auf dem CEG ein Native-Messaging Plugin verfügbar ist. Das heißt, es erfolgt hierbei eine Prüfung darauf, ob für den durch das CEG ausgeführten, zum Aufruf des Webportals der TEAZ genutzten Browser das entsprechende Native-Messaging Plugin installiert ist. Gemäß einer solchen Verfahrensgestaltung werden die Verfahrensschritte c) und d) im Anschluss an den Verfahrensschritt b) nur im Falle eines positiven Ergebnisses der Prüfung auf die Verfügbarkeit des Native-Messaging Plugins ausgeführt.
-
Im Falle eines negativen Ergebnisses der vorgenannten Prüfung ist das Verfahren dabei vorzugsweise so gestaltet, dass dieses mit der Ausgabe einer Fehlermeldung durch den Browser des CEG abgebrochen wird, mit welcher auf das Fehlen des Native-Messaging Plugins hingewiesen wird. Entsprechend einer besonders bevorzugten Weiterbildung kann im Zusammenhang mit einer entsprechenden Fehlermeldung außerdem ein durch den ausgeführten Browser ausgegebener Link an das CEG übermittelt werden, dessen Betätigung (Anklicken des Links) auf eine Webseite zum Bezug sowie zur Installation des Native-Messaging Plugins führt.
-
Gemäß einer Alternative der die Prüfung der Verfügbarkeit des Native-Messaging Plugins betreffenden Verfahrensgestaltung kann es gegebenenfalls auch vorgesehen sein, dass durch die TEAZ über den durch das CEG ausgeführten Browser ein Bedienelement bereitgestellt wird, durch dessen Betätigung (vorzugsweise Anklicken) ein das CEG verwendender Nutzer sein Einverständnis zum Bezug und zur Installation des Native-Messaging Plugins erklärt, so dass dieses Plugin im unmittelbaren Nachgang auf dem CEG für den gerade ausgeführten Browser installiert wird und im Anschluss daran das Verfahren mit den Verfahrensschritten c) und d) fortgesetzt werden kann. Letzteres setzt allerdings voraus, dass Entsprechendes, nämlich eine mehr oder weniger automatische Installation von Browser Plugins durch den jeweiligen, auf dem CEG bei der Nutzung des Verfahrens verwendeten Browser unterstützt wird. Insbesondere bei Standardbrowsern wird nach derzeitigem Stand eine solche Unterstützung aus Sicherheitsgründen möglicherweise nicht gegeben sein. Jedoch sind dies außerhalb des erfindungsgemäßen Verfahrens liegende Implementierungsfragen bezüglich für das Verfahren verwendeter Browser.
-
Gemäß einer praxisgerechten Ausgestaltung des Verfahrens kann es weiterhin vorgesehen sein, dass Bereitstellung des Startelements durch das Webportal der TEAZ ein Authentifizierungsprozess vorausgeht, bei welchem ein das CEG zur Kontaktierung des Webportals verwendender Nutzer sich gegenüber den TEAZ zunächst authentifizieren muss. In diesem Falle erfolgt eine Fortsetzung des Verfahrens selbstverständlich nur im Falle einer erfolgreichen Authentifizierung des Nutzers. Alternativ kann eine Authentifizierung auch unmittelbar beim Kontaktieren des Webportals mittels eines Browsers gefordert und das Startelement zum Starten des eigentlichen Verfahrensablaufs durch das Webportal nur nach einer erfolgreichen Authentifizierung über den Browser präsentiert, das heißt bereitgestellt, werden
-
Die 1 veranschaulicht beispielhaft eine mögliche Architektur eines in Umsetzung des Verfahrens temporär entstehenden Universal Smartcard Browser Gateways (USCBG) und die Einbettung dieser Architektur in die Umgebung eines lokal genutzten CEG sowie der mit diesem bei der Ausführung des Verfahrens kommunizierenden TEAZ einer zentralen Instanz. Im Hinblick auf die unter Bezugnahme auf die 1 erfolgenden Erläuterungen wird beispielhaft von einer mittels eines Kartenlesers an einem PC, als dem CEG, lokal verwendeten, das HSM ausbildenden Signaturkarte sowie von mit dieser Signaturkarte, das heißt mit deren Verarbeitungseinrichtung, kommunizierenden TEAZ einer Zertifizierungsstelle (CA = Certificate Authority), also eines Trustcenters, ausgegangen. Das in der 1 im Schema gezeigte, die Architektur des USCBG einschließende System umfasst demnach die nachfolgend im Einzelnen angegebenen und bezüglich ihres Zusammenwirkens bei der Durchführung des erfindungsgemäßen Verfahrens näher betrachteten Komponenten.
-
Die durch eine Strich-Punkt-Linie eingefassten TEAZ umfassen im Wesentlichen die Funktionsblöcke MAST/CE, Zertifikatsmodul, Produktionsserver (TCP/IP), Application-Server und Apache, wohingegen die Funktionsblöcke Browser, Native-Messaging Plugin, TCOS Card-Manager und Smartcard (HSM) lokal verortet sind, nämlich auf einem computerbasierten Endgerät (CEG), wie einem PC, ausgeführt beziehungsweise mit diesem genutzt werden. Aufgrund ihrer Ausführung auf dem oder ihrer Verwendung mit dem computerbasierten Endgerät sind in der Darstellung alle lokal angesiedelten Soft- und Hardware-Komponenten ebenfalls durch eine Strich-Punkt-Linie eingefasst und mit dem Bezeichner „CEG mit HSM“ gekennzeichnet worden.
-
Der Funktionsblock MAST/CA bezeichnet hierbei eine Auftragsdatenbank MAST und eine oder mehrere technische Einrichtungen, nämlich vorzugsweise mindestens einen durch eine Certificate Authority (CA) betriebenen Server, zur Zertifikatsproduktion. Beide Teile, MAST und CA, werden über eine gemeinsame Schnittstelle, nämlich ein Application Interface (API), angesprochen und sind daher hier nicht getrennt dargestellt. Die Schnittstelle dient zum Abrufen von Auftragsdaten und Kundendaten aus der Kundendatenbank (das ist einer der ersten Schritte im Prozess der Zertifikatsproduktion), zur Übergabe der Schlüssel an die CA, damit diese daraus ein Zertifikat erzeugt, sowie zu Statusrückmeldungen der einzelnen Schritte an die Auftragsdatenbank MAST.
-
Der Start des Produktionsprozesses erfolgt durch den auch als Webportal fungierenden Application Server, nach einem seitens des CEG mittels des Browsers erfolgenden Aufruf des Webportals und Betätigung eines durch dieses bereitgestellten Buttons (Startelement) zur Abforderung eines Zertifikats. Der Application Server ist in dem hier gezeigten Beispiel auf einen Apache Server (Apache) aufgesetzt. Die innerhalb des Application Server gezeichneten kleinen Kästen „A“ und „B“ dienen zur Symbolisierung unterschiedlicher Prozesse für unterschiedliche Aufgaben. Es gibt beispielsweise den Produktionsprozess „App B“ (durchgezogene Linie) oder auch andere Prozesse „App A“ (gestrichelte Linie), wobei letztere unter Umständen ohne Kommunikation mit der Auftragsdatenbank auskommen. Ein Beispiel für einen Prozess der letztgenannten Art wäre etwa die Änderung der PIN der Karte durch den Kunden. Dabei handelt es sich aber nur um einen Nebenaspekt, der hier nicht weiter betrachtet werden soll.
-
Nachdem die ersten Voraussetzungen (zum Beispiel der Kunde hat überhaupt einen Auftrag gestellt) geklärt sind, wird die Kommunikation auf Websockets (zwischen Apache und Browser) umgestellt. Im Gegensatz zu normalen http-Aufrufen ergibt sich daraus der Vorteil einer bidirektionale Software-Schnittstelle über die viele Anforderungen (Requests) nacheinander in derselben Session behandelt werden können. Jeder Websocket Prozess, im Bild als WS1, WS2,... WSn gekennzeichnet, verbindet sich mit dem Produktionsserver. Der Produktionsserver startet für jede Session einen eigenen Thread, T1, T2,... Tn. Durch die Websocket-Verbindung verläuft ein proprietäres Protokoll. Der Initiator der Kommunikation sind JS Bibliotheken (Java Script Bibliotheken) innerhalb des Browsers des Kunden. Die Anweisungen, was zu tun ist, kommen aber vom Produktionsserver. Bei diesen Anweisungen handelt es sich um Low-Level Befehle für die Signaturkarte, das heißt für die Smartcard als lokal genutztem HSM (beispielsweise Datei lesen, Datei schreiben, Schlüssel erzeugen, usw.). Alle Anweisungen werden durch einen sicheren Kanal zwischen Produktionsserver und Smartcard übertragen. Die beiden Komponenten, Produktionsserver und Smartcard, authentisieren sich gegenseitig.
-
Die JS Bibliotheken im Browser des Kunden holen sich die verschlüsselten Anweisungen vom Produktionsserver und gibt diese, ohne sie entschlüsseln zu können, an die Smartcard weiter. Dabei wird die Native-Messaging Schnittstelle, welche aktuelle Browser ihren Plugins zur Verfügung stellen, mittels eines zur Laufzeit eingebundenen Native-Messaging Plugin genutzt, wobei dieses sicherlich intern in den verschiedenen Browsern unterschiedlich umgesetzt wird. Die API zur Nutzung ist jedoch dieselbe. Der Doppelpfeil zwischen den JS Bibliotheken und dem Native-Messaging Plugin bildet die nachrichtenbasierte Kommunikation in JavaScript ab. Dies ist ein Standardmechanismus, der auch für andere Dinge genutzt wird.
-
Der Doppelpfeil zwischen dem Native-Messaging Plugin und dem TCOS Card-Manager symbolisiert die eigentliche native Schnittstelle (Native-Messaging Schnittstelle). Der Browser kommuniziert hier mit einer externen Anwendung mittels Standardeingabe und Standardausgabe dieser Anwendung. Das sind zwei Kommunikationskanäle, über die jede Anwendung verfügt. Die Aufgabe des TCOS Card-Managers ist die Umsetzung des Protokolls des Produktionsservers in das Protokoll der Smartcard. Auch dabei werden die verschlüsselten Befehle nicht entschlüsselt. Diese sind als verschlüsselter Datenblock Bestandteil des Protokolls des Produktionsservers. Außerdem ist der TCOS Card-Manager die Schnittstelle zwischen dem PC mit von diesem verwendeter Smartcard (SC) und dem Browser. Dieser kann die PC/SC Schnittstelle nicht direkt verwenden, sondern nur mit einer Anwendung über Standardeingabe und Standardausgabe kommunizieren.
-
Der Doppelpfeil zwischen dem TCOS Card-Manager und der Smartcard bildet die die PC/SC-Schnittstelle des Betriebssystems. Über diese Schnittstelle werden die Befehle und die Daten an die Smartcard übertragen, wobei dies eigentlich unter Verwendung eines Kartenlesers erfolgt, der hier allerdings als transparent angesehen wird und daher nicht dargestellt ist. Die Smartcard entschlüsselt den jeweils bei ihr eingehenden Befehl, führt ihn aus, verschlüsselt die Rückmeldung und sendet alles über den gleichen Weg zurück an den Produktionsserver. Dessen Rückmeldung ist der nächste auszuführende Befehl.
-
Nach der Anforderung eines Zertifikats durch das CEG bei den TEAZ werden im Zusammenhang mit dem vorstehend angesprochenen Austausch von Befehlen und Rückmeldungen (mit gegebenenfalls von diesen jeweils umfassten Daten), unter anderem durch die (im Detail nicht gezeigte) Verarbeitungseinrichtung der hier das HSM darstellenden Smartcard, aufgrund entsprechenden Befehls des Produktionsservers ein Schlüsselpaar erzeugt, der öffentliche Schlüssel dieses Schlüsselpaars an die TEAZ übertragen, durch die TEAZ ein Zertifikat zu diesem öffentlichen Schlüssel erzeugt, das Zertifikat durch den Produktionsserver an die Smartcard in Form entsprechender Daten übertragen und dort das Zertifikat in Zuordnung zu dem öffentlichen Schlüssel (in der ebenfalls nicht gezeigten) Speichereinrichtung des HSM abgespeichert.
