DE102016103963A1

DE102016103963A1 - Verfahren zur Signaturgenerierung für die Übertragung von Daten

Info

Publication number: DE102016103963A1
Application number: DE102016103963.2A
Authority: DE
Inventors: Michael Schunk
Original assignee: Ppi AG Informationstechnologie
Current assignee: PPI AG, DE
Priority date: 2016-03-04
Filing date: 2016-03-04
Publication date: 2017-09-07

Abstract

Bei einem Verfahren zur Signaturgenerierung für die Übertragung von Daten wird von einer auf einem Server bereitgestellten Web-Anwendung für zu übertragende Signaturbildungsdaten unter Verwendung eines privaten Web-Anwendung-Schlüssels eine Signatur erzeugt, um die die Signaturbildungsdaten ergänzt werden, die so ergänzten Signaturbildungsdaten in optische und/oder akustische Informationen umgewandelt und über ein erstes Netzwerk an ein erstes Datenverarbeitungsgerät übermittelt. Die die um die erste Signatur ergänzte Signaturbildungsdaten enthaltenden optischen und/oder akustischen Informationen werden durch die Ausgabeeinrichtung des ersten Datenverarbeitungsgerätes ausgegeben und von einer Aufzeichnungseinrichtung eines zweiten Datenverarbeitungsgerätes aufgezeichnet. Anschließend ermittelt ein auf dem zweiten Datenverarbeitungsgerät bereitgestelltes Anwendungsprogramm die Signaturbildungsdaten und die zugehörige Signatur aus den optischen und/oder akustischen Informationen, prüft die Signatur unter Verwendung eines öffentlichen Web-Anwendung-Schlüssels, erzeugt für die Signaturbildungsdaten unter Verwendung eines ersten privaten Anwendungsprogramm-Schlüssels eine Vergleichssignatur, bildet aus der Vergleichssignatur und dem ersten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendung-Schlüssels verschlüsselte Rückgabedaten und übermittelt diese vom zweiten Datenverarbeitungsgerät an die Web-Anwendung. Von der Web-Anwendung werden dann die Rückgabedaten unter Verwendung des privaten Web-Anwendung-Schlüssels entschlüsselt und die zweite Signatur unter Verwendung eines öffentlichen Anwendungsprogramm-Schlüssels geprüft, ob die Vergleichssignatur mit der Signatur übereinstimmt.

Description

HINTERGRUND DER ERFINDUNG
Die Erfindung betrifft ein Verfahren zur Signaturgenerierung für die Übertragung von Daten.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist eine Aufgabe der vorliegenden Erfindung, ein Verfahren der eingangs genannten Art vorzuschlagen, das eine Signaturgenerierung ermöglicht, ohne hierfür eine lokal auf dem System des Benutzers zu installierende Sicherheitsdatei oder eine Spezialhardware wie insbesondere einen Chipkartenleser verwenden zu müssen.
Zur Lösung dieser Aufgabe wird gemäß einem ersten Aspekt der Erfindung vorgeschlagen ein Verfahren zur Signaturgenerierung für die Übertragung von Daten, mit den Schritten,

I. eine Web-Anwendung auf einem Server bereitzustellen, der über ein erstes Netzwerk mit einem ersten Datenverarbeitungsgerät verbindbar ist, das eine Ausgabeeinrichtung zur Ausgabe von optischen und/oder akustischen Informationen aufweist,
II. ein Anwendungsprogramm auf einem zweiten Datenverarbeitungsgerät bereitzustellen, das über ein vom ersten Netzwerk separat betriebenes zweites Netzwerk mit dem Server verbindbar ist und eine Aufzeichnungseinrichtung zur Aufzeichnung von optischen und/oder akustischen Informationen aufweist,
III. im Anwendungsprogramm einen öffentlichen Web-Anwendung-Schlüssel und mindestens einen ersten privaten Anwendungsprogramm-Schlüssel zu hinterlegen,
IV. in der Web-Anwendung einen dem öffentlichen Web-Anwendung-Schlüssel zugeordneten privaten Web-Anwendung-Schlüssel und einen dem ersten privaten Anwendungsprogramm-Schlüssel zugeordneten ersten öffentlichen Anwendungsprogramm-Schlüssel zu hinterlegen,
V. von der Web-Anwendung für in die Web-Anwendung eingegebene Daten Signaturbildungsdaten zu erzeugen und für diese Signaturbildungsdaten unter Verwendung des privaten Web-Anwendung-Schlüssels eine Signatur zu erzeugen, um die die Signaturbildungsdaten ergänzt werden,
VI. die so ergänzten Signaturbildungsdaten in optische und/oder akustische Informationen umzuwandeln und an das erste Datenverarbeitungsgerät zu übermitteln,
VII. die die um die Signatur ergänzten Signaturbildungsdaten enthaltenden optischen und/oder akustischen Informationen durch die Ausgabeeinrichtung des ersten Datenverarbeitungsgerätes auszugeben und von der Aufzeichnungseinrichtung des zweiten Datenverarbeitungsgerätes aufzuzeichnen,
VIII. vom Anwendungsprogramm die Signaturbildungsdaten und die zugehörige Signatur aus den optischen und/oder akustischen Informationen zu ermitteln, die Signatur unter Verwendung des öffentlichen Web-Anwendung-Schlüssels zu prüfen, für die Signaturbildungsdaten unter Verwendung des ersten privaten Anwendungsprogramm-Schlüssels eine Vergleichssignatur zu erzeugen, aus der Vergleichssignatur und dem ersten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendungs-Schlüssels verschlüsselte Rückgabedaten zu bilden und vom zweiten Datenverarbeitungsgerät an die Web-Anwendung zu übermitteln, und
IX. von der Web-Anwendung die Rückgabedaten unter Verwendung des privaten Web-Anwendungs-Schlüssels zu entschlüsseln und die Vergleichssignatur unter Verwendung des ersten öffentlichen Anwendungsprogramm-Schlüssels zu prüfen, ob die Vergleichssignatur mit der Signatur übereinstimmt.

Erfindungsgemäß findet demnach die notwendige Übertragung der Daten, die zur Signaturbildung erforderlich sind, optisch und/oder akustisch vom ersten Datenverarbeitungsgerät zum zweiten Datenverarbeitungsgerät statt.
Mithilfe der Erfindung ergeben sich folgende Vorteile:

– Es muss kein Hardwaretreiber für die Nutzung von Chipkartenlesern auf dem Computer des Benutzers, der die Signatur leisten soll, installiert werden.
– Der im Computer des Benutzers zur Eingabe der Daten und zur Freigabe der Daten per Signatur benutzte Browser benötigt keine Erweiterung (Plug-in), sodass auch in diesem Zusammenhang keine zusätzliche Installation erforderlich ist.
– Die Eingabe der Daten, bei denen es sich bevorzugt um sog. Auftragsdaten handelt, und deren spätere manuelle Freigabe erfolgen auf zwei unabhängigen Systemen und die Übertragung der Daten und der Signatur auf zwei unabhängigen Kanälen, was einen Manipulationsversuch für Angreifer signifikant erschwert. Insoweit bedient sich die Erfindung hier des Prinzips des sog. Medienbruches, worunter der Übergang von einem Medium, insbesondere dem Internet, zu einem anderen Medium, hier erfindungsgemäß die Verwendung einer optischen und/oder akustischen Übertragung, zu verstehen ist; hierdurch wird die Angreifbarkeit des Verfahrens reduziert, da für eine Manipulation beide Übertragungskanäle angegriffen werden müssten.
– Durch die Erfindung wird eine Kopplung zwischen Anwendungsprogramm, zweitem Datenverarbeitungsgerät und steuernder Web-Anwendung realisiert, wodurch die Nutzung einer unerlaubt kopierten mobilen Anwendung erkannt und bei Bedarf abgelehnt werden kann.

Bevorzugte Ausführungen und Weiterbildungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Bevorzugt sind die in die Web-Anwendung eingegebenen Daten zur Verarbeitung in einer gewünschten Fach-Anwendung bestimmt und werden von der Web-Anwendung, nachdem diese festgestellt hat, dass die Vergleichssignatur mit der Signatur übereinstimmt, an diese Fach-Anwendung weitergeleitet. Bei dieser Fach-Anwendung handelt es sich somit um eine Anwendung zur Verarbeitung der erwähnten Daten. Somit unterscheidet sich diese Fach-Anwendung von der Übertragung der für die in die Web-Anwendung eingegebenen Daten erzeugten Signaturbildungsdaten zur Aufzeichnung auf dem zweiten Datenverarbeitungsgerät gemäß den Schritten V bis VII, wobei eine solche Übertragung grundsätzlich ebenfalls als Fach-Anwendung bezeichnet werden kann. Bei einer Weiterbildung dieser Ausführung wird im Schritt IV zusätzlich in der Web-Anwendung ein der gewünschten Fach-Anwendung zugeordneter öffentlicher Fach-Anwendung-Schlüssel und in der gewünschten Fach-Anwendung ein dem öffentlichen Fach-Anwendung-Schlüssel zugeordneter privater Fach-Anwendung-Schlüssel hinterlegt und werden die zur Verarbeitung in der gewünschten Fach-Anwendung bestimmten Daten unter Verwendung des öffentlichen Fach-Anwendung-Schlüssels verschlüsselt.
Bei einer alternativen Ausführung enthalten die in die Web-Anwendung eingegebenen Daten mindestens erste Daten und zweite Daten, von denen die ersten Daten zur Verabeitung in einer ersten Fach-Anwendung und die zweiten Daten zur Verabeitung in einer zweiten Fach-Anwendung bestimmt sind, und werden von der Web-Anwendung, nachdem diese festgestellt hat, dass die Vergleichssignatur mit der Signatur übereinstimmt, die ersten Daten an die erste Fach-Anwendung und die zweiten Daten an die zweite Fach-Anwendung weitergeleitet. Bevorzugt werden von der Web-Anwendung, nachdem diese festgestellt hat, dass die Vergleichssignatur mit der Signatur übereinstimmt, zunächst die ersten Daten an die erste Fach-Anwendung und anschließend die zweiten Daten an die zweite Fach-Anwendung weitergeleitet. Außerdem kann das Verfahren gemäß dieser alternativen Ausführung auch für mehr als zwei Fach-Anwendungen entsprechend eingesetzt werden, indem dann eine entsprechende Anzahl von Daten verarbeitet wird.
Des Weiteren wird zur Lösung der zuvor genannten Aufgabe gemäß einem zweiten Aspekt der Erfindung vorgeschlagen ein Verfahren zur Signaturgenerierung für die Übertragung von Daten, mit den Schritten,

I. eine Web-Anwendung auf einem Server bereitzustellen, der über ein erstes Netzwerk mit einem ersten Datenverarbeitungsgerät verbindbar ist, das eine Ausgabeeinrichtung zur Ausgabe von optischen und/oder akustischen Informationen aufweist,
II. ein Anwendungsprogramm auf einem zweiten Datenverarbeitungsgerät bereitzustellen, das über ein vom ersten Netzwerk separat betriebenes zweites Netzwerk mit dem Server verbindbar ist und eine Aufzeichnungseinrichtung zur Aufzeichnung von optischen und/oder akustischen Informationen aufweist,
III. Im Anwendungsprogramm einen öffentlichen Web-Anwendung-Schlüssel sowie einen ersten privaten Anwendungsprogramm-Schlüssel und mindestens einen zweiten privaten Anwendungsprogramm-Schlüssel zu hinterlegen, wobei der erste private Anwendungsprogramm-Schlüssel im Hinblick auf eine erste Fach-Anwendung zur Verarbeitung von ersten Daten und der zweite private Anwendungsprogramm-Schlüssel im Hinblick auf eine zweite Fach-Anwendung zur Verarbeitung von zweiten Daten zu verwenden ist,
IV. in der Web-Anwendung einen dem öffentlichen Web-Anwendung-Schlüssel zugeordneten privaten Web-Anwendung-Schlüssel sowie einen dem ersten privaten Anwendungsprogramm-Schlüssel zugeordneten ersten öffentlichen Anwendungsprogramm-Schlüssel und einen dem zweiten privaten Anwendungsprogramm-Schlüssel zugeordneten zweiten Anwendungsprogramm-Schlüssel zu hinterlegen,
V. von der Web-Anwendung für in die Web-Anwendung eingegebene erste Daten erste Signaturbildungsdaten und für die in die Web-Anwendung eingegebene zweite Daten zweite Signaturbildungsdaten zu erzeugen und unter Verwendung des privaten Web-Anwendung-Schlüssels für die ersten Signaturbildungsdaten eine erste Signatur, um die die ersten Signaturbildungsdaten ergänzt werden, und für die zweiten Signaturbildungsdaten eine zweite Signatur, um die die Signaturbildungsdaten ergänzt werden, zu erzeugen,
VI. die so ergänzten Signaturbildungsdaten in optische und/oder aktustische Informationen umzuwandeln und an das erste Datenverarbeitungsgerät zu übermitteln,
VII. die die um die jeweilige Signatur ergänzten Signaturbildungsdaten enthaltenden optischen und/oder aktustischen Informationen durch die Ausgabeeinrichtung des ersten Datenverarbeitungsgerätes auszugeben und von der Aufzeichnungseinrichtung des zweiten Datenverarbeitungsgerätes aufzuzeichnen,
VIII. vom Anwendungsprogramm die Signaturbildungsdaten und die zugehörige Signatur aus den optischen und/oder aktustischen Informationen zu ermitteln, die Signaturen unter Verwendung des öffentlichen Web-Anwendung-Schlüssels zu prüfen, für die ersten Signaturbildungsdaten unter Verwendung des ersten privaten Anwendungsprogramm-Schlüssels eine erste Vergleichssignatur und für die zweiten Signaturbildungsdaten unter Verwendung des zweiten privaten Anwendungsprogramm-Schlüssels eine zweite Vergleichssignatur zu erzeugen, aus der ersten Vergleichssignatur und dem ersten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendung-Schlüssels erste verschlüsselte Rückgabedaten und aus der zweiten Vergleichssignatur und dem zweiten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendung-Schlüssels zweite verschlüsselte Rückgabedaten zu bilden und die Rückgabedaten vom zweiten Datenverarbeitungsgerät an die Web-Anwendung zu übermitteln,
IX. in der Web-Anwendung die Rückgabedaten unter Verwendung des privaten Web-Anwendung-Schlüssels zu entschlüsseln und die erste Vergleichssignatur unter Verwendung des ersten öffentlichen Anwendungsprogramm-Schlüssel zu prüfen, ob die erste Vergleichssignatur mit der ersten Signatur übereinstimmt, und die zweite Vergleichssignatur unter Verwendung des zweiten öffentlichen Anwendungsprogramm-Schlüssels zu prüfen, ob die zweite Vergleichssignatur mit der zweiten Signatur übereinstimmt, und
X. von der Web-Anwendung im Falle einer Übereinstimmung der ersten Vergleichssignatur mit der ersten Signatur die ersten Daten an die erste Fach-Anwendung und im Falle einer Übereinstimmung der zweiten Vergleichssignatur mit der zweiten Signatur die zweiten Daten an die zweite Fach-Anwendung weiterzuleiten.

Bevorzugt werden beim zweiten Aspekt der Erfindung im Schritt X von der Web-Anwendung zunächst die ersten Daten an die erste Fach-Anwendung und anschließend die zweiten Daten an die zweite Fach-Anwendung weitergeleitet.
Eine weitere bevorzugte Ausführung des zweiten Aspektes der Erfindung zeichnet sich dadurch aus, dass
im Schritt IV zusätzlich in der Web-Anwendung ein der ersten Fach-Anwendung zugeordneter erster öffentlicher Fach-Anwendung-Schlüssel und ein der zweiten Fach-Anwendung zugeordneter zweiter öffentlicher Fach-Anwendung-Schlüssel, in der ersten Fach-Anwendung ein dem ersten öffentlichen Fach-Anwendung-Schlüssel zugeordneter erster privater Fach-Anwendung-Schlüssel und in der zweiten Fach-Anwendung ein dem zweiten öffentlichen Fach-Anwendung-Schlüssel zugeordneter zweiter privater Fach-Anwendung-Schlüssel hinterlegt wird, und
die ersten Daten unter Verwendung des ersten öffentlichen Fach-Anwendung-Schlüssels und die zweiten Daten unter Verwendung des zweiten öffentlichen Fach-Anwendung-Schlüssels verschlüsselt werden.
Ein solches Verfahren gemäß dem zweiten Aspekt der Erfindung lässt sich im Übrigen auch für mehr als zwei Fach-Anwendungen entsprechend einsetzen, indem dann eine entsprechende Anzahl von Daten, Anwendungsprogramm-Schlüsselpaaren, Signaturbildungsdaten, Signaturen, Vergleichssignaturen und Rückgabedaten erzeugt bzw. verwendet werden.
Bevorzugt wird als erstes Datenverarbeitungsgerät ein Computer, insbesondere ein Personalcomputer, mit darauf installiertem Browser verwendet, dessen Ausgabeeinrichtung für den Fall, dass im Schritt VI die ergänzten Signaturbildungsdaten als optische Informationen an das erste Datenverarbeitungsgerät übermittelt werden, einen Monitor und für den Fall, dass im Schritt VI die ergänzten Signaturbildungsdaten als akustische Informationen an das erste Datenverarbeitungsgerät übermittelt werden, einen Lautsprecher aufweist.
Bevorzugt wird als zweites Datenverarbeitungsgerät ein mobiles Endgerät, vorzugsweise ein Smartphone, verwendet, dessen Aufzeichnungseinrichtung für den Fall, dass im Schritt VII optische Informationen ausgegeben werden, eine Kamera und für den Fall, dass im Schritt VII akustische Informationen ausgegeben werden, ein Mikrofon aufweist, und ist das zweite Netzwerk ein Mobilfunknetzwerk.
Bevorzugt werden im Schritt VI die optischen Informationen als QR-Code gebildet.
Vorzugsweise können die Signaturbildungsdaten zusätzlich eine Internetadresse der Web-Anwendung und/oder einen Anzeigetext zur Anzeige auf dem zweiten Datenverarbeitungsgerät enthalten, wobei als Internetadresse eine variable Internetadresse verwendet werden kann.
Vorzugsweise enthalten die Rückgabedaten zusätzlich einen Signaturzählwert.
KURZBESCHREIBUNG DER FIGUREN
Nachfolgend werden bevorzugte Ausführungsbeispiele der Erfindung anhand der beiliegenden Zeichnungen näher erläutert. Es zeigen:
1 schematisch den Vorgang einer Einrichtung per Postbriefe durch den Anbieter;
2 schematisch den Vorgang eines Ladens eines mobilen Anwendungsprogrammes aus einem App-Store;
3 schematisch ein Ablaufdiagramm für eine Erstanmeldung und eine Synchronisation des mobilen Anwendungsprogrammes für den Fall einer symmetrischen Verschlüsselung;
4 schematisch den Vorgang einer Erstanmeldung eines neuen Benutzers;
5 schematisch den Vorgang einer Ersteinrichtung des mobilen Anwendungsprogrammes;
6 schematisch den Vorgang einer Synchronisation zwischen mobilem Anwendungsprogramm und Web-Anwendung;
7 schematisch ein Ablaufdiagramm für die Erstanmeldung und die Synchronisation des mobilen Anwendungsprogrammes für den Fall einer asymmetrischen Verschlüsselung;
8 schematisch ein Ablaufdiagramm für die Anmeldung mit Signatur per mobilem Anwendungsprogramm für den Fall einer symmetrischen Verschlüsselung;
9 schematisch den Vorgang einer Anmeldung an der Web-Anwendung;
10 schematisch ein Ablaufdiagramm für die Anmeldung mit Signatur per mobilem Anwendungsprogramm für den Fall einer asymmetrischen Verschlüsselung;
11 schematisch ein Ablaufdiagramm für eine Anmeldung per mobilem Anwendungsprogramm und Schlüsseleinreichung bei einer Fach-Anwendung für den Fall einer symmetrischen Verschlüsselung;
12 schematisch ein Ablaufdiagramm für die Anmeldung per mobilem Anwendungsprogramm und Schlüsseleinreichung bei der Fach-Anwendung für den Fall einer asymmetrischen Verschlüsselung;
13 schematisch ein Ablaufdiagramm für das Unterschreiben von erfassten Aufträgen für den Fall einer symmetrischen Verschlüsselung;
14 schematisch den Vorgang einer Erfassung von signierpflichtigen Aufträgen;
15 schematisch den Vorgang des Unterschreibens mit Hilfe des mobilen Anwendungsprogrammes;
16 schematisch ein Ablaufdiagramm für das Unterschreiben der erfassten Aufträge für den Fall einer asymmetrischen Verschlüsselung;
17 schematisch ein Ablaufdiagramm für den Fall einer sog. Tunnelung einer zweiten Fach-Anwendung am Beispiel einer Anmeldung per mobilem Anwendungsprogramm und Schlüsseleinreichung bei der Fach-Anwendung für den Fall einer asymmetrischen Verschlüsselung; und
18 schematisch ein Ablaufdiagramm für die Anmeldung mit Signatur per mobilem Anwendungsprogramm für den Fall einer asymmetrischen Verschlüsselung und einer Kommunikation über TLS.
BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSBEISPIELE
Das im Folgenden beschriebene Verfahren gemäß bevorzugter Ausführungsbeispiele nutzt eine zentrale Web-Anwendung, die auf einem Server eines Anbieters oder Betreibers installiert ist, zur Verarbeitung und Weiterleitung der eingegebenen und bearbeiteten Daten an die jeweilige Fach-Anwendung bzw. das jeweilige Fach-Verfahren vorgesehen ist und somit auch die Funktion eines Portals hat, und ein mobiles Anwendungsprogramm, das auf einem mobilen Endgerät wie insbesondere einem Smartphone oder Tablet arbeitet und auch als sog. „Signaturanwendung“ und abgekürzt als „App“ bzw. „APP“ bezeichnet wird. Das zu verwendende mobile Endgerät muss über eine mobile Internetkonnektivität (bevorzugt zur Verbindung mit einem drahtlosen lokalen Netzwerk (WLAN) oder einem mobilen Datennetz) und über eine Kamera verfügen, wobei außerdem auf dem mobilen Endgerät das genannte mobile Anwendungsprogramm installiert sein muss. Zusätzlich ist es zumindest optional auch denkbar, dass das mobile Endgerät noch ein Mikrofon aufweist. Sofern diese zuvor aufgeführten Eigenschaften gewährleistet sind, kann anstelle eines Smartphones oder Tablets auch jedes andere mobile Endgerät zur Verwendung in Betracht kommen.
Zusätzlich zu einem mobilen Endgerät wird auf Seiten des Benutzers noch ein Computer, insbesondere ein Personal Computer, verwendet, der als Peripheriegeräte mindestens über einen Monitor und eine Tastatur verfügen muss.
Die Kommunikation zwischen dem Server und somit der darauf installierten Web-Anwendung einerseits und dem Computer auf Seiten des Benutzers andererseits findet über ein erstes Netzwerk statt, bei dem es sich bevorzugt um ein DSL-Festnetz handelt. Demgegenüber findet die Kommunikation zwischen dem Server und der auf diesem installierten Web-Anwendung einerseits und dem mobilen Endgerät und somit dem darauf installierten mobilen Anwendungsprogramm andererseits über ein mobiles zweites Netzwerk statt, bei dem es sich zweckmäßigerweise um ein UMTS- bzw. 3G- oder LTE- bzw. 4G-Mobilfunknetzwerk handelt.
Das auf dem mobilen Endgerät installierte Anwendungsprogramm lässt sich über das mobile zweite Netzwerk mit der Web-Anwendung auf einem Server koppeln, was nachfolgend noch im Einzelnen näher erläutert wird. Hierzu wird eine SSL-gesicherte http-Kommunikation mit dem Anwendungsprogramm auf dem mobilen Endgerät benötigt. Des Weiteren ist der Austausch und die Speicherung von kryptografischen Schlüsseln zur Kopplung von mobilem Anwendungsprogramm und Web-Anwendung erforderlich. Eine sog. APP-ID zur Identifizierung eines auf einem individuellen mobilen Endgerät eines bestimmten Benutzers installierten Anwendungsprogrammes oder alternativ ein öffentlicher Schlüssel pro synchronisiertem Anwendungsprogramm eines Benutzers ist entsprechend von der Web-Anwendung auf dem Server zu verwalten. Des Weiteren ist die Speicherung und Prüfung einer streng sequenziellen Einreichung von Signaturen gewünscht, wozu ein Signatur-Zähler bzw. ein Signatur-Zählwert verwendet wird. Bevorzugt sind auch Auftragsbeschreibungen in Textform zu erzeugen. Ebenfalls müssen zur Signaturbildung notwendige Bytefolgen, ggf. über zusätzliche protokollspezifische Bibliotheken der Fach-Anwendung, erzeugt werden. Außerdem sind bevorzugt protokollspezifische Schlüsselaustauschfunktionen (wie EBICS, FinTS etc.) zu verwenden. Schließlich ist ein spezifiziertes Bild für den Transport von Daten zur Signaturbildung zu erzeugen, wobei für diesen Zweck alternativ oder optional auch eine spezifizierte Tonfolge erzeugt werden kann.
Nachfolgend wird beispielhaft der komplette Ablauf mit einer optischen Variante unter Nutzung eines QR-Codes als optische Informationen bzw. Bildinformationen beschrieben. Die geschilderten und gezeigten Abläufe und die erläuterten Daten können jedoch auch auf andere Art und Weise in Form von optischen Informationen und/oder akustischen Informationen bzw. Tonfolgen transportiert werden.
In den nachfolgend beschriebenen Verfahren werden folgende wichtige Schlüssel für unterschiedliche Aufgaben verwendet:
RSAKEY
Hierbei handelt es sich um ein asymmetrisches Schlüsselpaar zur Erzeugung von verfahrensspezifischen Signaturen für unterschiedliche Fach-Anwendungen (wie beispielsweise FinTS, EBICS etc.). Die Schlüsseltiefe (in Form einer Bitfolge) wird durch Inhalte der Verfahrenskennzeichen (sog. ID-Signaturverfahren) bei der Erzeugung bestimmt. In Abhängigkeit vom gewünschten Verfahren kann ein spezifisches Schlüsselpaar vorliegen. Dieser Schlüssel dient zusätzlich zur Signaturbildung für übertragene Daten, damit die empfangene Web-Anwendung die manipulationsfreie Übertragung unter Wahrung der Datenintegrität sowie den Absender in Form des mobilen Anwendungsprogrammes eindeutig identifizieren kann. Auch ein sog. Reply-Schutz ist darüber vorgesehen. Dieses Schlüsselpaar wird vom mobilen Anwendungsprogramm erzeugt, wobei der private Schlüssel dieses Schlüsselpaares im Anwendungsprogramm und der öffentliche Schlüssel dieses Schlüsselpaares in der Web-Anwendung hinterlegt wird.
CLIENTKEY
Hierbei handelt es sich um ein asymmetrisches Schlüsselpaar, das nur im alternativen Verfahren mit asymmetrischer Verschlüsselung zur Anwendung kommt, vom mobilen Anwendungsprogramm erzeugt wird und zur Verschlüsselung des QR-Codes durch den Server dient.
SERVERKEY
Hierbei handelt es sich um ein asymmetrisches Schlüsselpaar zur Erzeugung von Signaturen der Web-Anwendung. Dabei dient der private Schlüssel zur Signaturerstellung durch die Web-Anwendung und zur Entschlüsselung von Nachrichten, die vom mobilen Anwendungsprogramm gesendet werden, sodass nur die Web-Anwendung den privaten Schlüssel kennt. Der öffentliche Schlüssel wird hingegen vom mobilen Anwendungsprogramm benutzt, um Datenübertragungen nur genau für die zugehörige Web-Anwendung zu verschlüsseln, und ist bereits im Programmcode des mobilen Anwendungsprogrammes enthalten. Dieses Schlüsselpaar wird vom mobilen Anwendungsprogramm für die Überprüfung von serverseitigen Signaturen zum Schutz gegen Manipulation (Datenintegrität) sowie für die Überprüfung der Authentizität der absendenden Web-Anwendung genutzt, wobei somit im mobilen Anwendungsprogramm der öffentliche Schlüssel dieses Schlüsselpaares und in der Web-Anwendung der private Schlüssel dieses Schlüsselpaares hinterlegt wird.
APP-ID
Die APP-ID stellt einen symmetrischen Schlüssel dar, der durch die Web-Anwendung vergeben und im mobilen Anwendungsprogramm des jeweiligen Benutzers gespeichert wird. Es handelt sich um eine eindeutige ID, die für eine in Bezug auf das mobile Anwendungsprogramm spezielle symmetrische Verschlüsselung genutzt wird, sofern nicht ein asymmetrisches Verfahren mit dem CLIENTKEY eingesetzt wird. Bei Verwendung von asymmetrischer Verschlüsselung eines QR-Codes mit dem öffentlichen Schlüssels des Benutzers (Verwendung des CLIENTKEY) hat die APP-ID nur die Funktion eines Einmal-Transport-Passwortes und kann nach der Initialisierung gelöscht werden. Der APP-ID (bei symmetrischer Verschlüsselung) oder dem CLIENTKEY (bei asymmetrischer Verschlüsselung) ist ein Signaturzähler zugeordnet.
Für die optische Datenübertragung wird ein auswertbares Bildformat verwendet, wobei nachfolgend die Prozesse anhand eines Bildes beschrieben werden, das einen QR-Code enthält. Zur Anwendung gelangen zwei unterschiedliche Typen von Bildern bzw. QR-Codes, die sich nur durch die enthaltenen Daten und Absicherungen unterscheiden und im Folgenden kurz beschrieben werden und auf die in der nachfolgenden Beschreibung der Prozesse immer wieder Bezug genommen wird:
Bild (QR-Code) zur Synchronisation
In einem an den Benutzer zu versendenden Brief zur Synchronisation des mobilen Anwendungsprogramms mit der Web-Anwendung ist ein Bild bzw. QR-Code abgedruckt, das bzw. der Verfahrensdaten (ID, Version, Daten für ID-Signaturverfahren, Daten für ID-Fach-Anwendung etc.) sowie die APP-ID zur Nutzung als für das mobile Anwendungsprogramm spezifischen symmetrischen Schlüssel enthalten, wobei für die asymmetrische Verschlüsselung anstelle der APP-ID der öffentliche CLIENTKEY verwendet wird. Dabei sind diese Daten mit dem privaten Schlüssel der Web-Anwendung (SERVERKEY) signiert und können durch den im mobilen Anwendungsprogramm hinterlegten öffentlichen Schlüssel der Web-Anwendung (SERVERKEY) auf Manipulation und Korrektheit geprüft werden.
Funktionen des mobilen Anwendungsprogramms bei Synchronisation
Mithilfe des mobilen Anwendungsprogrammes wird auf Seiten des Benutzers mit der Kamera des mobilen Endgerätes das Bild bzw. der QR-Code eingescannt und werden die darin enthaltenen Daten übernommen.
Anschließend werden folgende Funktionen ausgeführt:

1. Die enthaltene Signatur der Web-Anwendung wird mit dem öffentlichen SERVERKEY geprüft, der im Programmcode des mobilen Anwendungsprogramms enthalten ist.
2. Sofern die Signatur korrekt ist, werden die Verfahrensdaten übernommen und gespeichert.
3. Die enthaltene APP-ID wird entnommen (und ggf. für ein symmetrische Verschlüsselung dauerhaft gespeichert).

Mit einer solchen Signaturprüfung wird sichergestellt, dass nur die berechtigte Web-Anwendung die enthaltenen Daten und damit auch die korrekte APP-ID senden konnte.
Bild (QR-Code) zur Signaturbildung
Zur Anforderung einer Signatur veranlasst die Web-Anwendung auf dem Server nach Übermittlung über das erste Netzwerk eine Darstellung des Bildes bzw. des QR-Codes auf dem Monitor des Computers auf Seiten des Benutzers, wobei das Bild bzw. der QR-Code folgende Daten enthält:

– Verfahrensdaten (ID, Version, Daten für ID-Signaturverfahren, Daten für ID-Fach-Anwendung etc.)
– Variable Internetadresse (URL) als Ziel zur Datenübermittlung
– Bytefolge als Eingabe der Signaturerzeugung mit dem RSAKEY
– Anzeigetext für den Benutzer des mobilen Anwendungsprogramms auf dessen mobilem Endgerät

Die Daten "variable Internetadresse", "Bytefolge" und "Anzeigetext" werden mit der symmetrischen APP-ID von der Web-Anwendung verschlüsselt und können nur von dem mit der APP-ID bezeichneten mobilen Anwendungsprogramm korrekt entschlüsselt werden, wobei ja die APP-ID schon im QR-Code zur Synchronisation übermittelt worden ist.
Sämtliche zuvor aufgeführten Daten werden von der Web-Anwendung mit dem privaten SERVERKEY signiert. Diese Signatur ist Bestandteil der Daten, die zur Erzeugung des QR-Codes genutzt werden, und kann stets mit dem im mobilen Anwendungsprogramm vorliegenden öffentlichen SERVERKEY verifiziert werden.
Funktionen des mobilen Anwendungsprogramms während der Signaturbildung
Mithilfe des mobilen Anwendungsprogrammes wird von der Kamera des mobilen Endgerät der QR-Code eingescannt. Das mobile Anwendungsprogramm wandelt dann den Inhalt der Daten um und beginnt auf den so erhaltenen Daten folgende Funktionen auszuführen:

1. Es wird die Signatur der Web-Anwendung unter Verwendung des öffentlichen Schlüssels der Web-Anwendung (SERVERKEY) geprüft.
2. Es werden die im QR-Code verschlüsselten Daten bei symmetrischer Verschlüsselung mit der APP-ID und bei asymmetrischer Verschlüsselung mit dem privaten CLIENTKEY entschlüsselt.
3. Der Anzeigetext wird auf einem Display des mobilen Endgerätes dem Benutzer zur Bestätigung angezeigt.
4. Die Bytefolge wird, sofern vorhanden, mit dem eigenen privaten RSAKEY signiert, wenn der Benutzer die Korrektheit der Anzeige auf dem mobilen Endgerät bestätigt.
5. Das mobile Anwendungsprogramm erzeugt eine Antwort in Form von sog. Rückgabedaten, die einen aktuellen Signaturzählwert, einen öffentlichen RSA-Schlüssel (RSAKEY) aus einem Schlüsselspeicher, eine verfahrensgemäße Signatur (RSAKEY) über den ggf. erhaltenen Binärwert (optional) für die mit der Web-Anwendung gekoppelte Fach-Anwendung sowie eine Signatur (RSAKEY) über erhaltene Daten (Signaturzählwert, öffentlicher RSA-Schlüssel, variable Internetadresse, Anzeigetext und ggf. vorhandene Signatur über den Binärwert) zur Sicherstellung der Datenintegrität und Abwehr von Reply-Attacken enthalten.
6. Das mobile Anwendungsprogramm verschlüsselt alle Rückgabedaten mit dem öffentlichen Schlüssel der Web-Anwendung (SERVERKEY) und sendet diese Nachricht vom mobilen Endgerät des Benutzers über das mobile zweite Netzwerk an die Web-Anwendung im Server unter der variablen Internetadresse aus dem QR-Code.

Funktionen der Web-Anwendung beim Erhalt einer Signatur
Die Web-Anwendung erhält auf der variablen Internetadresse die Rückgabedaten über das mobile zweite Netzwerk vom mobilen Anwendungsprogramm, welche sie auf dem Server wie folgt verarbeitet:

1. Die erhaltenen Rückgabedaten werden mit dem privaten Schlüssel der Web-Anwendung (SERVERKEY) entschlüsselt.
2. Über die erhaltenen Daten Signaturzähler, öffentlicher RSA-Schlüssel (RSAKEY), variable Internetadresse, Anzeigetext und Signatur über den Binärwert wird die Signatur geprüft.

Ist die Signatur korrekt, wird weiterverarbeitet, da alle bekannten Daten (Signaturzählwert, variable Internetadresse, Anzeigetext) und der übergebene öffentliche Schlüssel korrekt zur erhaltenen Signatur passen.
Erstanmeldung und Synchronisation des Anwendungsprogrammes
Zunächst muss der Benutzer seine Berechtigung für die Nutzung des Verfahrens beim zuständigen Anbieter beantragen. Dieser Vorgang ist schematisch in 1 dargestellt.
In einem ersten Brief vom Anbieter wird dem Benutzer die ihm zugeordnete neue Online-Kennung mitgeteilt, mit der er sich künftig an der Web-Anwendung anmelden kann, welche auf einem Server des Anbieters bereitgestellt ist.
Für eine erfolgreiche Anmeldung benötigt der Benutzer jedoch noch einen zweiten Brief. In einem zweiten Brief vom Anbieter und Betreiber des Servers wird dem Benutzer ein ihm individuell zugeordneter persönlicher QR-Code zur Synchronisation mitgeteilt. Der im zweiten Brief abgedruckte QR-Code zur Synchronisation enthält die zuvor genannten Daten. Des Weiteren enthält dieser zweite Brief Angaben, woher der Benutzer das mobile Anwendungsprogramm erhält.
Der Benutzer folgt den Anweisungen im zweiten Brief und lädt sich aus der angegebenen Quelle (App-Store) das mobile Anwendungsprogramm auf sein mobiles Endgerät, was in 2 schematisch dargestellt ist.
Der Benutzer startet auf seinem mobilen Endgerät das neu geladene mobile Anwendungsprogramm und vergibt dabei zunächst sein persönliches App-Passwort, mit dem das mobile Anwendungsprogramm vor unberechtigter Nutzung geschützt wird.
Das heruntergeladene mobile Anwendungsprogramm enthält bereits in seinem Programmcode den öffentlichen SERVERKEY der Web-Anwendung sowie die Internetadresse (URL), unter der das mobile Anwendungsprogramm mit der Web-Anwendung auf dem Server des Anbieters kommunizieren kann.
Hinsichtlich der einzelnen Schritte im Prozess wird nachfolgend Bezug genommen auf die in 3 angegebene Nummerierung der Schritte.
Beim ersten Start des mobilen Anwendungsprogrammes gemäß Schritt 1 von 3 vereinbart der Benutzer zunächst sein App-Passwort gemäß Schritt 2, welches er bei jedem Start des mobilen Anwendungsprogrammes eingeben muss. Wenn dieses vereinbart ist, wird der Benutzer aufgefordert, zur Synchronisation des mobilen Anwendungsprogrammes den QR-Code aus dem zweiten Brief zu scannen, wodurch das installierte mobile Anwendungsprogramm mit dem im QR-Code codierten Daten versorgt wird. Somit übernimmt das mobile Anwendungsprogramm die Daten aus dem QR-Code zur Synchronisation, wie durch den Schritt 3 in 3 angedeutet ist.
Hierbei erzeugt das mobile Anwendungsprogramm nun passend zu den erhaltenen Verfahrenskennzeichen ein passendes asymmetrisches RSAKEY-Schlüsselpaar – und im Falle einer asymmetrischen Verschlüsselung auch ein asymmetrisches CLIENTKEY-Schlüsselpaar – und legt dieses in einem Schlüsselspeicher im mobilen Endgerät des Benutzers ab. Ein für dieses Schlüsselpaar vorgesehener Signaturzähler wird dabei auf null initialisiert.
Anschließend wird dem Benutzer die erfolgreiche Synchronisation des mobilen Anwendungsprogrammes auf dem Display seines mobilen Endgerätes gemäß Schritt 4 von 3 signalisiert.
Wenn sich nun der Benutzer an der Web-Anwendung über eine Tastatur oder sonstige Eingabemittel an seinem Computer sowie über das erste Netzwerk das erste Mal gemäß Schritt 5 anmeldet, wozu ergänzend auch auf 4 verwiesen wird, wird ihm von der Web-Anwendung über das erste Netzwerk auf dem Monitor seines Computers ein QR-Code zur Signaturbildung gemäß Schritt 6 von 3 angezeigt, mit dem er den vorher eingeleiteten Prozess der Synchronisation zwischen dem mobilen Anwendungsprogramm auf seinem mobilen Endgerät und der Web-Anwendung auf dem Server des Anbieters abschließen muss.
Dann fordert die Web-Anwendung eine Signatur mit dem privaten RSAKEY des mobilen Anwendungsprogrammes an. Hierzu startet der Benutzer auf seinem mobilen Endgerät das mobile Anwendungsprogramm gemäß Schritt 7 von 3 und scannt mit der Kamera des mobilen Endgerätes den auf dem Monitor seines Computers angezeigten QR-Code gemäß Schritt 8 ein, wozu ergänzend auch auf 5 verwiesen wird. Anschließend muss der Benutzer den auf dem Display seines mobilen Endgerätes angezeigten Anzeigetext gemäß Schritt 9 von 3 bestätigen und dann die damit verbundene Signaturbildung über den Anzeigetext mit dem privaten RSAKEY vornehmen. Die daraus entstandene Signatur wird vom mobilen Anwendungsprogramm im mobilen Endgerät des Benutzers über das mobile zweite Netzwerk an die Web-Anwendung im Server gemäß Schritt 10 von 3 übermittelt.
Im Anzeigetext sollten benutzerspezifische Daten enthalten sein, die nur dem Benutzer bekannt und beispielsweise auch mit Datum und Uhrzeit versehen sind. So kann der Benutzer erkennen, was er gerade macht, und die Web-Anwendung später prüfen, ob der Benutzer genau den im QR-Code übermittelten Text gesehen hat.
Der von der Web-Anwendung erzeugte QR-Code zur Signaturbildung enthält die oben genannten Daten.
Wie zuvor beschrieben, führt das mobile Anwendungsprogramm die Funktionen zur Signaturbildung aus, während die Web-Anwendung die Funktionen zur Prüfung der Signatur oder Weitergabe der Signatur an eine Fach-Anwendung ausführt.
Die Web-Anwendung prüft des Weiteren, ob die erhaltene Signatur zu dem im vorherigen QR-Code übergegebenen Anzeigetext passt. Wenn alle Daten korrekt sind, erfolgt die Erhöhung des Signaturzählers um den Wert "1" – also beim ersten Mal von "0" auf "1" – und eine Speicherung des Zählerstandes des Signaturzählers in der APP-ID für die nächste Signaturprüfung.
Nun ist die Initialisierung des mobilen Anwendungsprogrammes abgeschlossen, wie 6 schematisch zeigt, und sind alle notwendigen Schlüsselwerte ausgetauscht, wobei die Datenintegrität und die Absenderauthentizität geprüft wurde.
Die Web-Anwendung signalisiert die erfolgreiche Einrichtung an das mobile Anwendungsprogramm gemäß Schritt 11 von 3, und das mobile Anwendungsprogramm meldet dem Benutzer durch Anzeige auf dem Display seines mobilen Endgerätes die erfolgreiche Synchronisation gemäß Schritt 12 von 3. Der Benutzer bestätigt dann noch auf der auf dem Monitor seines Computers angezeigten Web-Seite durch entsprechende Eingabe über die Tastatur oder sonstige Eingabemittel auf seinem Computer und Übermittlung über das erste Netzwerk, dass die Einreichung und Synchronisation des mobilen Anwendungsprogrammes erfolgreich war, gemäß Schritt 13 von 3 und erhält eine abschließende Erfolgsmeldung von der Web-Anwendung auf dem Display seines mobilen Endgerätes gemäß Schritt 14 von 3.
Im Fall einer asymmetrischen Verschlüsselung wird im Schritt 10 vom mobilen Anwendungsprogramm ein zusätzliches Schlüsselpaar CLIENTKEY erzeugt und der öffentliche Schlüssel dieses Schlüsselpaares zusätzlich über das mobile zweite Netzwerk an die Web-Anwendung übertragen, wozu auf 7 verwiesen wird, die sich hinsichtlich des übrigen Ablaufes von 3 nicht unterscheidet.
Anmelden mit Signatur an der Web-Anwendung
Im Folgenden wird nun der Prozess der Anmeldung an der Web-Anwendung mit dem initialisierten mobilen Anwendungsprogramm unter Bezugnahme auf die in 8 gezeigten Schritte beschrieben, wobei ergänzend auch auf die Darstellung von 9 verwiesen wird.
Zunächst meldet sich der Benutzer durch Eingabe seiner Benutzerkennung über die Tastatur oder sonstige Eingabemittel an seinem Computer sowie durch Übermittlung über das erste Netzwerk an der Web-Anwendung gemäß Schritt 1 von 8 an. Daraufhin erkennt die Web-Anwendung, dass das mobile Anwendungsprogramm auf dem mobilen Endgerät des Benutzers korrekt initialisiert ist.
Auf dem Monitor des Computers auf Seiten des Benutzers baut die Web-Anwendung durch Übermittlung über das erste Netzwerk eine Web-Seite auf, in der der erzeugte QR-Code zur Signaturbildung angezeigt wird (Schritt 2 von 8).
Der Benutzer startet das mobile Anwendungsprogramm auf seinem mobilen Endgerät und gibt das App-Passwort gemäß Schritt 3 von 8 ein und scannt anschließend den auf dem Monitor des Computers angezeigten QR-Code mit der Kamera seines mobilen Endgerätes gemäß Schritt 4 von 8 ein. Anschließend zeigt das mobile Anwendungsprogramm auf dem Display des mobilen Endgerätes des Benutzers den Anzeigetext gemäß Schritt 5 von 8 an, und der Benutzer bestätigt den Anzeigetext über die Tastatur oder sonstige Eingabemittel auf seinem mobilen Endgerät gemäß Schritt 6 von 8. Daraufhin findet durch das mobile Anwendungsprogramm auf dem mobilen Endgerät des Benutzers die Signaturbildung mit dem privaten RSAKEY statt und wird diese Signatur gemäß Schritt 7 von 8 vom mobilen Anwendungsprogramm im mobilen Endgerät des Benutzers über das mobile zweite Netzwerk an die wartende Web-Anwendung übermittelt. Somit führt das mobile Anwendungsprogramm auf dem mobilen Endgerät die Funktionen zur Signaturbildung aus, während die Web-Anwendung die Funktionen zur Prüfung der Signatur des Binärwertes mit dem öffentlichen RSAKEY des mobilen Anwendungsprogrammes ausführt. Hinsichtlich weiterer Einzelheiten zum Schritt 7 von 8 wird auf den Schritt 10 von 3 und die diesbezügliche Beschreibung verwiesen.
Erkennt die Web-Anwendung, dass die Signatur des Binärwertes korrekt ist, wird von ihr über das mobile zweite Netzwerk das mobile Anwendungsprogramm hierüber gemäß Schritt 8 von 8 benachrichtigt. Der Benutzer bestätigt dann über eine Eingabe auf der Tastatur oder sonstige Eingabemöglichkeiten seines Computers und durch entsprechende Übermittlung über das erste Netzwerk an die Web-Anwendung, dass der QR-Code eingelesen wurde (Schritt 9 von 8), woraufhin der Benutzer von der Web-Anwendung Zugang zur Web-Anwendung gemäß Schritt 10 von 8 erhält.
Im Fall einer asymmetrischen Verschlüsselung wird der öffentliche CLIENTKEY im Schritt 2 verwendet, wie 10 erkennen lässt, welche hinsichtlich der übrigen Abläufe der 8 entspricht.
Anmeldung per mobilem Anwendungsprogramm und Schlüsseleinreichung bei der Fach-Anwendung
Ist ein Benutzer an der Web-Anwendung angemeldet, bietet die Web-Anmeldung dem Benutzer die Möglichkeit, seinen öffentlichen RSAKEY an eine angeschlossene Fach-Anwendung zu senden. Hierzu wird auf die Nummerierung der in 11 gezeigten Schritte Bezug genommen.
Zunächst meldet sich der Benutzer mit seiner Benutzerkennung bei der Web-Anwendung gemäß Schritt 1 von 11 an.
Die Web-Anwendung erzeugt einen prozessspezifischen Anzeigetext und bildet einen einmaligen Binärwert, den der Benutzer nun mit dem korrekten – der Web-Anwendung bekannten – Schlüssel unterzeichnen soll.
Die Web-Anwendung erzeugt durch entsprechende Übermittlung über das erste Netzwerk auf dem Monitor des Computers des Benutzers eine Web-Seite, in der der erzeugte QR-Code, der die bereits zuvor genannten Daten enthält, zur Signaturbildung angezeigt wird (Schritt 2 von 11).
Nun startet der Benutzer auf seinem mobilen Endgerät das mobile Anwendungsprogramm, gibt das App-Passwort gemäß Schritt 3 von 11 ein und scannt mit der Kamera seines mobilen Endgerätes den von der Web-Anwendung auf dem Bildschirm seines Computers angezeigten QR-Code gemäß Schritt 4 von 11.
Daraufhin zeigt das mobile Anwendungsprogramm auf dem Display des mobilen Endgerätes des Benutzers den Anzeigetext gemäß Schritt 5 von 11 an, und der Benutzer bestätigt diesen Anzeigetext über eine Tastatur oder sonstige Eingabemittel seines mobilen Endgerätes gemäß Schritt 6 von 11. Daraufhin erfolgt im mobilen Anwendungsprogramm eine Signaturbildung über den Anzeigetext mit dem privaten RSAKEY und wird die Signatur vom mobilen Anwendungsprogramm im mobilen Endgerät über das mobile zweite Netzwerk an die Web-Anwendung im Server gemäß Schritt 7 übermittelt. Hinsichtlich weiterer Einzelheiten wird auf die Beschreibung der Schritte 8 bis 10 von 3 verwiesen.
Das mobile Anwendungsprogramm im mobilen Endgerät des Benutzers führt somit die Funktionen zur Signaturbildung aus, während die Web-Anwendung auf dem Server des Anbieters die Funktionen zur Prüfung der Signatur des Binärwertes mit dem öffentlichen RSAKEY des mobilen Anwendungsprogrammes ausführt.
Die erhaltene Signatur wird von der Web-Anwendung im Server über das mobile zweite Netzwerk an das mobile Anwendungsprogramm im mobilen Endgerät des Benutzers gemäß Schritt 8 von 11 signalisiert. Der Benutzer bestätigt über die Tastatur oder sonstige Eingabemittel am Terminal seines Computers gemäß Schritt 9 von 11, dass die Signatur geleistet wurde.
Der übergebene öffentliche RSAKEY wird von der Web-Anwendung mit weiteren spezifischen Daten für eine Fach-Anwendung angereichert und an diese Fach-Anwendung als Schlüsseleinreichung gemäß Schritt 10 von 11 übermittelt. Die Fach-Anwendung bestätigt den technisch erfolgreichen Empfang des öffentlichen RSAKEY an die Web-Anwendung gemäß Schritt 11 von 11.
Die Web-Anwendung erzeugt daraufhin einen sog. INI-Brief und stellt diesen dem Benutzer über eine über das erste Netzwerk übermittelte Web-Seite auf seinem Computer zum Ausdrucken zur Verfügung (Schritt 12 von 11). Der INI-Brief wird vom Benutzer gemäß Schritt 13 von 11 ausgedruckt und unterschrieben und an einen Sachbearbeiter der Fach-Anwendung per Post gesendet. Der INI-Brief enthält einen sog. Fingerprint des eingereichten öffentlichen Schlüssels und dient später zur asynchronen Prüfung innerhalb der Fach-Anwendung, ob der elektronische eingereichte öffentliche RSAKEY identisch mit dem auf postalischem Weg übermittelten Fingerprint des RSAKEY ist (Schritt 14 von 11).
Im Fall einer asymmetrischen Verschlüsselung wird im Schritt 2 anstelle der APP-ID der öffentliche CLIENTKEY verwendet, wie 12 erkennen lässt, welche hinsichtlich der übrigen Abläufe mit 11 identisch ist.
Erfasste Aufträge unterschreiben
Ist ein Benutzer an der Web-Anwendung angemeldet, hat er die Möglichkeit, über Web-Formulare Aufträge zu erfassen. Hierzu wird nachfolgend auf die Nummerierung der in 13 gezeigten Schritte Bezug genommen, wobei ergänzend auch auf die Darstellungen der 14 und 15 verwiesen wird.
Die Web-Anwendung nimmt die Auftragsdaten entgegen und erzeugt daraus ein fachspezifisches Nachrichtenformat, das in der Regel zu signieren und dann gemeinsam an die Fach-Anwendung zu senden ist.
Zunächst werden die Auftragsdaten vom Benutzer über eine Tastatur oder eine sonstige Eingabemöglichkeit am Terminal seines Computers eingegeben und von dort über das erste Netzwerk an die Web-Anwendung im Server gemäß Schritt 1 von 13 übermittelt, wo sie gesammelt und in ein gewünschtes Nachrichtenformat (z.B. EBICS) umgewandelt werden.
Weiterhin erzeugt die Web-Anwendung eine Beschreibung des Auftrages, sodass ein Benutzer damit erkennen kann, dass er diesen Auftrag genauso wie beschrieben ausführen kann. Hierbei handelt es sich um den Anzeigetext im noch zu erzeugenden QR-Code.
Außerdem ermittelt die Web-Anwendung die variable Internetadresse (URL), unter der sie auf die dann vom mobilen Anwendungsprogramm übermittelte Signatur warten will. Schließlich erzeugt die Web-Anwendung noch Verfahrensdaten, mit denen sie signalisiert, welche Art der Signatur sie vom mobilen Anwendungsprogramm erzeugt haben will.
Über dieses Nachrichtenformat wird dann eine Bytefolge (Hashwert) gebildet. Diese Bytefolge ist u.a. ein Bestandteil des zu erzeugenden QR-Codes zur Signaturbildung. Enthalten darin sind die bereits zuvor erwähnten Daten.
Nun wird auf der durch Übermittlung über das erste Netzwerk auf dem Monitor des Computers auf Seiten des Benutzers angezeigten Web-Seite von der Web-Anwendung der QR-Code zur Signaturbildung gemäß Schritt 2 von 13 abgebildet.
Der Benutzer startet gemäß Schritt 3 von 13 das mobile Anwendungsprogramm auf seinem mobilen Endgerät, gibt sein App-Passwort ein und scannt gemäß Schritt 4 von 13 mit der Kamera seines mobilen Endgerätes den angezeigten QR-Code ein.
Daraufhin zeigt das mobile Anwendungsprogramm auf dem Display des mobilen Endgerätes den Anzeigetext mit Auftragsdetails gemäß Schritt 5 von 13 an, was der Benutzer über eine Tastatur oder eine sonstige Eingabemöglichkeit an seinem mobilen Endgerät dem Anwendungsprogramm gemäß Schritt 6 von 13 bestätigt.
Daraufhin führt das mobile Anwendungsprogramm auf dem mobilen Endgerät die Signaturbildung über den Anzeigetext mit dem privaten RSAKEY durch und übermittelt vom mobilen Endgerät des Benutzers über das mobile zweite Netzwerk diese Signatur an die wartende Web-Anwendung im Server (Schritt 7 von 13).
Der Erhalt der Signatur wird von der Web-Anwendung über das mobile zweite Netzwerk an das mobile Anwendungsprogramm im mobilen Endgerät gemäß Schritt 8 von 13 signalisiert, und das mobile Anwendungsprogramm zeigt dem Benutzer auf dem Display seines mobilen Endgerätes die erfolgreiche Übermittlung der Signatur gemäß Schritt 9 von 13 an.
Bei der übergebenen Signatur über den Binärwert handelt es sich um den noch fehlenden Wert, den die Web-Anwendung dem im Übrigen schon vorbereiteten Nachrichtenformat hinzufügen muss.
Nach Bestätigung durch den Benutzer über eine Tastatur oder eine sonstige Eingabemöglichkeit an seinem Computer gemäß Schritt 10 von 13 erstellt die Web-Anwendung dann die Nachricht syntaktisch korrekt für die Fach-Anwendung und überträgt die den Auftrag und die Signatur enthaltende Nachricht an die Fach-Anwendung gemäß Schritt 11 von 13. Die Fach-Anwendung wiederum signalisiert der Web-Anwendung den Erhalt des Auftrages gemäß Schritt 12 von 13.
Die Web-Anwendung zeigt dann dem Benutzer über das erste Netzwerk auf dem Monitor seines Computers gemäß Schritt 13 von 13 an, dass sein Auftrag technisch erfolgreich an die Fach-Anwendung übertragen wurde.
In der Regel findet in der Fach-Anwendung dann eine asynchrone Verifizierung der erhaltenen Signatur zu den enthaltenen Auftragsdaten statt, und zwar unter Verwendung des dort bekannten öffentlichen RSAKEY.
Im Fall einer asymmetrischen Verschlüsselung wird anstelle der APP-ID der öffentliche CLIENTKEY im Schritt 2 verwendet, wie in 16 gezeigt ist, welche hinsichtlich der übrigen Abläufe mit 13 identisch ist.
Tunnelung mindestens einer weiteren Fach-Anwendung
Das Verfahren gemäß den zuvor beschriebenen Ausführungsbeispielen eignet sich für die Verwendung eines einzigen RSAKEY-Schlüsselpaares für die Anmeldung bei der Web-Anwendung und einer Signatur für die jeweilige Fach-Anwendung. Sofern Fach-Anwendungen unterschiedliche Schlüssellängen erfordern, ist die Verwendung unterschiedlicher Schlüsselpaare RSAKEY_1,...n zwingend notwendig. Grundsätzlich soll im beschriebenen Verfahren für jede Fach-Anwendung ein eigenes Schlüsselpaar mit jeweils einem eigenen Signaturzähler genutzt werden. Die Wahl des richtigen Schlüsselpaares erfolgt anhand der Daten der Fach-Anwendungen.
Dies hat folgende Vorteile:

– Bei Korrumpierung eines Schlüsselpaares sind nicht alle Fach-Anwendungen betroffen.
– Bei Anpassung oder Änderung einer einzelnen Fach-Anwendung kann allein der für diese Fach-Anwendung genutzte Schlüssel gewechselt werden, ohne dass andere Fach-Anwendungen betroffen sind.

In diesen beiden Fällen sollte mit den anderen Fach-Anwendungen, gegebenenfalls auch über alternative Kanäle, ohne Unterbrechung weitergearbeitet werden.
Um dies zu erreichen, kann mithilfe des zuvor beschriebenen Verfahrens bevorzugt ein zusätzlicher Schlüssel für eine zweite Fach-Anwendung generiert und ausgetauscht werden. Die zu signierenden Informationen der zweiten Fach-Anwendung können in der ersten Fach-Anwendung unverfälscht durchgetunnelt und dann gemäß den Vorgaben der zweiten Fach-Anwendung (z.B. betreffend Kryptoverfahren, Padding, Hashing, besondere Schlüssellängen etc.) autorisiert und wieder zurückgetunnelt werden. Die Verwendung eines zweiten Schlüssels für die zweite Fach-Anwendung dient insbesondere dazu, diese zweite Fach-Anwendung unabhängig zu halten, sowie gegebenenfalls des Weiteren dazu, vorhandene Notwendigkeiten der zweiten Fach-Anwendung abzubilden. So kann bei Bedarf für eine Fach-Anwendung ein Schlüsselwechsel erfolgen, ohne dass die andere Fach-Anwendung dadurch betroffen ist. Grundsätzlich kann die zweite Fach-Anwendung auch ein Verfahren einer dritten Anwendung verkörpern, an die der Server nur weiterleitet.
Der Vorteil einer solchen Tunnelung soll an einem einfachen Beispiel wie folgt verdeutlicht werden:
Im Zahlungsverkehr gibt es das EBICS-Verfahren. Dazu werden von einem Client Zahlungsdaten an eine Bank gegeben und parallel dazu der zugehörige signierte Hashwert als Autorisierung an die Bank übermittelt. Gewöhnlich handelt es sich hierbei um recht große Datenmengen, wodurch die Erfassung auf einem mobilen Endgerät problematisch und somit nicht sinnvoll ist. Stattdessen findet die Erfassung auf einem Personal Computer statt, wo nun der Hashwert signiert wird. Diesen signierten Hashwert gesichert zusammen mit den relevanten Daten in Klarschrift zur Sichtprüfung auf einer Anzeige an das mobile Endgerät zu übertragen, ist Aufgabe der ersten Fach-Anwendung. Somit ermöglicht die Kombination von zwei Fach-Anwendungen die Nutzung beispielsweise von EBICS auf einem mobilen Endgerät.
Die Tunnelung an die jeweilige Fach-Anwendung erfolgt über die Web-Anwendung für die anwendungsspezifischen Initialisierungen, wozu auf die Schritte 10 ff. in den 11 und 12 verwiesen wird, sowie für die Signaturen in der jeweiligen Fach-Anwendung, wozu auf die Schritte 11 ff. in den 13 und 16 verwiesen wird.
In 17 ist beispielhaft die Tunnelung des Schlüssels RSAKEY_EBICS für die Fach-Anwendung "EBICS" an das verarbeitende EBICS-System durch die Web-Anwendung dargestellt, und zwar am Beispiel einer Anmeldung über das mobile Anwendungsprogramm und Initialisierung durch Schlüsseleinreichung bei der Fach-Anwendung für den Fall einer asymmetrischen Verschlüsselung. Im Gegensatz zu dem in 12 gezeigten Verfahren erfolgt im Schritt 7 durch das mobile Anwendungsprogramm nicht nur eine Signaturbildung mit dem privaten RSAKEY und eine Übermittlung zusammen mit dem zugehörigen öffentlichen RSAKEY, sondern zusätzlich auch eine Übermittlung eines weiteren öffentlichen RSAKEY für eine weitere Fach-Anwendung, hier nämlich des öffentlichen RSAKEY_EBICS für die EBICS-Fach-Anwendung, über das mobile zweite Netzwerk an die Web-Anwendung im Server und wird im Schritt 10 der übergebene öffentliche RSAKEY_EBICS von der Web-Anwendung mit weiteren spezifischen Daten für die EBICS-Fach-Anwendung angereichert und an diese Fach-Anwendung als Schlüsseleinreichung übermittelt.
In diesem Zusammenhang sei abschließend noch angemerkt, dass im Fall einer symmetrischen Verschlüsselung im Schritt 2 anstelle des öffentlichen CLIENTKEY die APP-ID verwendet wird, wie beispielsweise auch ein Vergleich von 11 mit 12 erkennen lässt.
Alternative Kommunikation über TLS
Anmeldung, Schlüsseleinreichung beim Fach-Verfahren und Unterschreiben von erfassten Aufträgen können grundsätzlich alternativ statt durch Nutzung eines QR-Codes auch durch per TLS (Transport Layer Security) übertragene Kryptogramme erfolgen. Dieses Verfahren bildet im Übrigen einen weiteren eigenständigen Erfindungsgedanken.
18 zeigt eine Kommunikation über TLS am Beispiel einer Anmeldung an der Web-Anwendung im Fall einer asymmetrischen Verschlüsselung. Die in 18 dargstellten Abläufe entsprechen der in 10 dargestellten Abläufe mit dem Unterschied, dass im Schritt 2 in der Web-Anwendung ein Kryptogramm bereitgestellt wird, das mit dem SERVERKEY signiert und mit dem öffentlichen CLIENTKEY verschlüsselt ist und insbesondere die Verfahrensdaten, eine variable URL und einen Anzeigetext enthält, und im Schritt 4 vom mobilen Anmeldungsprogramm das Kryptogramm via TLS über die URL des Portals und somit an der Web-Anwendung abgeholt wird.

Claims

Verfahren zur Signaturgenerierung für die Übertragung von Daten, mit den Schritten, I. eine Web-Anwendung auf einem Server bereitzustellen, der über ein erstes Netzwerk mit einem ersten Datenverarbeitungsgerät verbindbar ist, das eine Ausgabeeinrichtung zur Ausgabe von optischen und/oder akustischen Informationen aufweist, II. ein Anwendungsprogramm auf einem zweiten Datenverarbeitungsgerät bereitzustellen, das über ein vom ersten Netzwerk separat betriebenes zweites Netzwerk mit dem Server verbindbar ist und eine Aufzeichnungseinrichtung zur Aufzeichnung von optischen und/oder akustischen Informationen aufweist, III. im Anwendungsprogramm einen öffentlichen Web-Anwendung-Schlüssel und mindestens einen ersten privaten Anwendungsprogramm-Schlüssel zu hinterlegen, IV. in der Web-Anwendung einen dem öffentlichen Web-Anwendung-Schlüssel zugeordneten privaten Web-Anwendung-Schlüssel und einen dem ersten privaten Anwendungsprogramm-Schlüssel zugeordneten ersten öffentlichen Anwendungsprogramm-Schlüssel zu hinterlegen, V. von der Web-Anwendung für in die Web-Anwendung eingegebene Daten Signaturbildungsdaten zu erzeugen und für diese Signaturbildungsdaten unter Verwendung des privaten Web-Anwendung-Schlüssels eine Signatur zu erzeugen, um die die Signaturbildungsdaten ergänzt werden, VI. die so ergänzten Signaturbildungsdaten in optische und/oder akustische Informationen umzuwandeln und an das erste Datenverarbeitungsgerät zu übermitteln, VII. die die um die Signatur ergänzten Signaturbildungsdaten enthaltenden optischen und/oder akustischen Informationen durch die Ausgabeeinrichtung des ersten Datenverarbeitungsgerätes auszugeben und von der Aufzeichnungseinrichtung des zweiten Datenverarbeitungsgerätes aufzuzeichnen, VIII. vom Anwendungsprogramm die Signaturbildungsdaten und die zugehörige Signatur aus den optischen und/oder akustischen Informationen zu ermitteln, die Signatur unter Verwendung des öffentlichen Web-Anwendung-Schlüssels zu prüfen, für die Signaturbildungsdaten unter Verwendung des ersten privaten Anwendungsprogramm-Schlüssels eine Vergleichssignatur zu erzeugen, aus der Vergleichssignatur und dem ersten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendungs-Schlüssels verschlüsselte Rückgabedaten zu bilden und vom zweiten Datenverarbeitungsgerät an die Web-Anwendung zu übermitteln, und IX. von der Web-Anwendung die Rückgabedaten unter Verwendung des privaten Web-Anwendungs-Schlüssels zu entschlüsseln und die Vergleichssignatur unter Verwendung des ersten öffentlichen Anwendungsprogramm-Schlüssels zu prüfen, ob die Vergleichssignatur mit der Signatur übereinstimmt.
Verfahren nach Anspruch 1, bei welchem die in die Web-Anwendung eingegebenen Daten zur Verarbeitung in einer gewünschten Fach-Anwendung bestimmt sind und von der Web-Anwendung, nachdem diese festgestellt hat, dass die Vergleichssignatur mit der Signatur übereinstimmt, an diese Fach-Anwendung weitergeleitet werden.
Verfahren nach Anspruch 2, bei welchem im Schritt IV zusätzlich in der Web-Anwendung ein der gewünschten Fach-Anwendung zugeordneter öffentlicher Fach-Anwendung-Schlüssel und in der gewünschten Fach-Anwendung ein dem öffentlichen Fach-Anwendung-Schlüssel zugeordneter privater Fach-Anwendung-Schlüssel hinterlegt wird und die zur Verarbeitung in der gewünschten Fach-Anwendung bestimmten Daten unter Verwendung des öffentlichen Fach-Anwendung-Schlüssels verschlüsselt werden.
Verfahren nach Anspruch 1, bei welchem die in die Web-Anwendung eingegebenen Daten mindestens erste Daten und zweite Daten enthalten, von denen die ersten Daten zur Verarbeitung in einer ersten Fach-Anwendung und die zweiten Daten zur Verarbeitung in einer zweiten Fach-Anwendung bestimmt sind, und von der Web-Anwendung, nachdem diese festgestellt hat, dass die Vergleichssignatur mit der Signatur übereinstimmt, die ersten Daten an die erste Fach-Anwendung und die zweiten Daten an die zweite Fach-Anwendung weitergeleitet werden.
Verfahren nach Anspruch 4, bei welchem von der Web-Anwendung, nachdem diese festgestellt hat, dass die Vergleichssignatur mit der Signatur übereinstimmt, zunächst die ersten Daten an die erste Fach-Anwendung und anschließend die zweiten Daten an die zweite Fach-Anwendung weitergeleitet werden.
Verfahren zur Signaturgenerierung für die Übertragung von Daten, mit den Schritten, I. eine Web-Anwendung auf einem Server bereitzustellen, der über ein erstes Netzwerk mit einem ersten Datenverarbeitungsgerät verbindbar ist, das eine Ausgabeeinrichtung zur Ausgabe von optischen und/oder akustischen Informationen aufweist, II. ein Anwendungsprogramm auf einem zweiten Datenverarbeitungsgerät bereitzustellen, das über ein vom ersten Netzwerk separat betriebenes zweites Netzwerk mit dem Server verbindbar ist und eine Aufzeichnungseinrichtung zur Aufzeichnung von optischen und/oder akustischen Informationen aufweist, III. Im Anwendungsprogramm einen öffentlichen Web-Anwendung-Schlüssel sowie einen ersten privaten Anwendungsprogramm-Schlüssel und mindestens einen zweiten privaten Anwendungsprogramm-Schlüssel zu hinterlegen, wobei der erste private Anwendungsprogramm-Schlüssel im Hinblick auf eine erste Fach-Anwendung zur Verarbeitung von ersten Daten und der zweite private Anwendungsprogramm-Schlüssel im Hinblick auf eine zweite Fach-Anwendung zur Verarbeitung von zweiten Daten zu verwenden ist, IV. in der Web-Anwendung einen dem öffentlichen Web-Anwendung-Schlüssel zugeordneten privaten Web-Anwendung-Schlüssel sowie einen dem ersten privaten Anwendungsprogramm-Schlüssel zugeordneten ersten öffentlichen Anwendungsprogramm-Schlüssel und einen dem zweiten privaten Anwendungsprogramm-Schlüssel zugeordneten zweiten Anwendungsprogramm-Schlüssel zu hinterlegen, V. von der Web-Anwendung für in die Web-Anwendung eingegebene erste Daten erste Signaturbildungsdaten und für die in die Web-Anwendung eingegebene zweite Daten zweite Signaturbildungsdaten zu erzeugen und unter Verwendung des privaten Web-Anwendung-Schlüssels für die ersten Signaturbildungsdaten eine erste Signatur, um die die ersten Signaturbildungsdaten ergänzt werden, und für die zweiten Signaturbildungsdaten eine zweite Signatur, um die die Signaturbildungsdaten ergänzt werden, zu erzeugen, VI. die so ergänzten Signaturbildungsdaten in optische und/oder aktustische Informationen umzuwandeln und an das erste Datenverarbeitungsgerät zu übermitteln, VII. die die um die jeweilige Signatur ergänzten Signaturbildungsdaten enthaltenden optischen und/oder aktustischen Informationen durch die Ausgabeeinrichtung des ersten Datenverarbeitungsgerätes auszugeben und von der Aufzeichnungseinrichtung des zweiten Datenverarbeitungsgerätes aufzuzeichnen, VIII. vom Anwendungsprogramm die Signaturbildungsdaten und die zugehörige Signatur aus den optischen und/oder aktustischen Informationen zu ermitteln, die Signaturen unter Verwendung des öffentlichen Web-Anwendung-Schlüssels zu prüfen, für die ersten Signaturbildungsdaten unter Verwendung des ersten privaten Anwendungsprogramm-Schlüssels eine erste Vergleichssignatur und für die zweiten Signaturbildungsdaten unter Verwendung des zweiten privaten Anwendungsprogramm-Schlüssels eine zweite Vergleichssignatur zu erzeugen, aus der ersten Vergleichssignatur und dem ersten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendung-Schlüssels erste verschlüsselte Rückgabedaten und aus der zweiten Vergleichssignatur und dem zweiten privaten Anwendungsprogramm-Schlüssel unter Verwendung des öffentlichen Web-Anwendung-Schlüssels zweite verschlüsselte Rückgabedaten zu bilden und die Rückgabedaten vom zweiten Datenverarbeitungsgerät an die Web-Anwendung zu übermitteln, IX. in der Web-Anwendung die Rückgabedaten unter Verwendung des privaten Web-Anwendung-Schlüssels zu entschlüsseln und die erste Vergleichssignatur unter Verwendung des ersten öffentlichen Anwendungsprogramm-Schlüssel zu prüfen, ob die erste Vergleichssignatur mit der ersten Signatur übereinstimmt, und die zweite Vergleichssignatur unter Verwendung des zweiten öffentlichen Anwendungsprogramm-Schlüssels zu prüfen, ob die zweite Vergleichssignatur mit der zweiten Signatur übereinstimmt, und X. von der Web-Anwendung im Falle einer Übereinstimmung der ersten Vergleichssignatur mit der ersten Signatur die ersten Daten an die erste Fach-Anwendung und im Falle einer Übereinstimmung der zweiten Vergleichssignatur mit der zweiten Signatur die zweiten Daten an die zweite Fach-Anwendung weiterzuleiten.
Verfahren nach Anspruch 6, bei welchem im Schritt X von der Web-Anwendung zunächst die ersten Daten an die erste Fach-Anwendung und anschließend die zweiten Daten an die zweite Fach-Anwendung weitergeleitet werden.
Verfahren nach Anspruch 6 oder 7, bei welchem im Schritt IV zusätzlich in der Web-Anwendung ein der ersten Fach-Anwendung zugeordneter erster öffentlicher Fach-Anwendung-Schlüssel und ein der zweiten Fach-Anwendung zugeordneter zweiter öffentlicher Fach-Anwendung-Schlüssel, in der ersten Fach-Anwendung ein dem ersten öffentlichen Fach-Anwendung-Schlüssel zugeordneter erster privater Fach-Anwendung-Schlüssel und in der zweiten Fach-Anwendung ein dem zweiten öffentlichen Fach-Anwendung-Schlüssel zugeordneter zweiter privater Fach-Anwendung-Schlüssel hinterlegt wird, und die ersten Daten unter Verwendung des ersten öffentlichen Fach-Anwendung-Schlüssels und die zweiten Daten unter Verwendung des zweiten öffentlichen Fach-Anwendung-Schlüssels verschlüsselt werden.
Verfahren nach mindestens einem der vorangegangenen Ansprüche, bei welchem als erstes Datenverarbeitungsgerät ein Computer, insbesondere ein Personalcomputer, mit darauf installiertem Browser verwendet wird, dessen Ausgabeeinrichtung für den Fall, dass im Schritt VI die ergänzten Signaturbildungsdaten als optische Informationen an das erste Datenverarbeitungsgerät übermittelt werden, einen Monitor und für den Fall, dass im Schritt VI die ergänzten Signaturbildungsdaten als akustische Informationen an das erste Datenverarbeitungsgerät übermittelt werden, einen Lautsprecher aufweist.
Verfahren nach mindestens einem der vorangegangenen Ansprüche, bei welchem als zweites Datenverarbeitungsgerät ein mobiles Endgerät, vorzugsweise ein Smartphone, verwendet wird, dessen Aufzeichnungseinrichtung für den Fall, dass im Schritt VII optische Informationen ausgegeben werden, eine Kamera und für den Fall, dass im Schritt VII akustische Informationen ausgegeben werden, ein Mikrofon aufweist, und das zweite Netzwerk ein Mobilfunknetzwerk ist.
Verfahren nach mindestens einem der vorangegangenen Ansprüche, bei welchem im Schritt VI die optischen Informationen als QR-Code gebildet werden.
Verfahren nach mindestens einem der vorangegangenen Ansprüche, bei welchem die Signaturbildungsdaten zusätzlich eine Internetadresse der Web-Anwendung und/oder einen Anzeigetext zur Anzeige auf dem zweiten Datenverarbeitungsgerät enthalten.
Verfahren nach Anspruch 12, bei welchem als Internetadresse eine variable Internetadresse verwendet wird.
Verfahren nach mindestens einem der vorangegangenen Ansprüche, bei welchem die Rückgabedaten zusätzlich einen Signaturzählwert enthalten.