DE102006023436A1 - Authentisierung für entfernte Funktionsaufrufe - Google Patents

Authentisierung für entfernte Funktionsaufrufe Download PDF

Info

Publication number
DE102006023436A1
DE102006023436A1 DE200610023436 DE102006023436A DE102006023436A1 DE 102006023436 A1 DE102006023436 A1 DE 102006023436A1 DE 200610023436 DE200610023436 DE 200610023436 DE 102006023436 A DE102006023436 A DE 102006023436A DE 102006023436 A1 DE102006023436 A1 DE 102006023436A1
Authority
DE
Germany
Prior art keywords
rpc
command
secure messaging
records
secure
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE200610023436
Other languages
English (en)
Inventor
Stephan Dr. Spitz
Gisela Dr. Meister
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Priority to DE200610023436 priority Critical patent/DE102006023436A1/de
Priority to EP07725303A priority patent/EP2025119A1/de
Priority to PCT/EP2007/004388 priority patent/WO2007134784A1/de
Publication of DE102006023436A1 publication Critical patent/DE102006023436A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357Cards having a plurality of specified features
    • G06Q20/3574Multiple applications on card
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1016Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80Wireless

Abstract

Die vorliegende Erfindung betrifft ein Verfahren, einen mobilen Datenträger (C), eine Vorrichtung, ein System und ein Computerprogrammprodukt zur gesicherten Datenübertragung zwischen einer rufenden Instanz (R<SUB>i</SUB>) und einer gerufenen Instanz (G<SUB>i</SUB>), wobei die gerufene Instanz (G<SUB>i</SUB>) zur Ausführung eines RPC-Befehls (RPC-B) ausgelegt ist. Erfindungsgemäß wird die Übertragung des RPC-Befehls (RPC-B) mit den entsprechend erforderlichen Parametern mit einer Authentisierungsinformation (A) in Bezug auf die jeweiligen Instanzen (R<SUB>i</SUB>, G<SUB>i</SUB>) kombiniert. Dabei wird die Authentisierungsinformation (A) entweder mit dem RPC-Befehl (RPC-B) oder mit dem Ergebnis (RPC-E) auf den entsprechenden Befehl übertragen.

Description

  • Die Erfindung liegt auf dem Gebiet der Datenübertragung in Bezug auf mobile Datenträger, wie z.B. Chipkarten, unter Verwendung von Sicherheitsmechanismen, wie insbesondere Authentisierungsverfahren.
  • Die Erfindung betrifft insbesondere ein Verfahren zum gesicherten Datenaustausch zwischen zumindest zwei Instanzen, die unter anderem ihre Daten über so genannte entfernte Funktionsaufrufe oder Remote-Procedure-Calls (im Folgenden kurz als RPC-Befehle bezeichnet) austauschen, wobei bei dem Austausch von RPC-Befehlen ein zusätzlicher Sicherheits-Mechanismus vorgesehen ist.
  • Eine Chipkarte kann neben der Funktion als Datenspeicher auch als Berechtigungsträger für bestimmte Informationen und/oder für die Ausführung bestimmter Befehle dienen. Ein wichtiger Aspekt bei der Datenübertragung betrifft deshalb die Sicherstellung von Integrität und Authentizität von zu übertragenden Nachrichten und gegebenenfalls eine Vertraulichkeit und Verbindlichkeit der Nachrichten. Das Überprüfen der Authentizität hat den Zweck, einerseits eine eindeutige Zuordnung zwischen Sender und Empfänger der Nachricht sicherzustellen und andererseits nachzuweisen, dass eine vom Empfänger erhaltene Nachricht während ihrer Übertragung nicht verändert worden ist.
  • Die Überprüfung der Authentizität spielt im Rahmen einer Authentisierung eine wesentliche Rolle. Zweck einer Authentisierung ist es, die Identität und Authentizität eines Kommunikationspartners bei der Datenübertragung zu überprüfen.
  • Im Stand der Technik ist in diesem Zusammenhang eine Vielzahl von Verfahren und Mechanismen entwickelt worden, um insgesamt die Sicherheit der Datenübertragung im Zusammenhang mit Chipkarten zu erhöhen. Diese Mechanismen und Verfahren fallen unter den Oberbegriff "Secure Messaging". Bei der Anwendung von Secure-Messaging-Verfahren auf die Chipkartentechnik ist zu berücksichtigen, dass die Rechenleistung zumindest einer der beiden Kommunikationspartner und/oder die Übertragungsgeschwindigkeit zwischen den beiden Kommunikationspartnern gegebenenfalls Einschränkungen unterliegen können. Ein Verfahren für ein Secure Messaging ist in der Norm ISO/IEC 7816-4 und erweiterte Funktionen hierzu in der Norm ISO/IEC-Norm 7816-8 standardisiert worden. Zweck einer gesicherten Datenübertragung ist es insbesondere, die Authentizität und bei Bedarf auch die Vertraulichkeit der zu übertragenden Nachricht sicherzustellen. In diesem Zusammenhang ist es bekannt, einen gesicherten Kanal zur Chipkarte aufzubauen und die Daten dann über diesen gesicherten Kanal zu übertragen. Ein Secure Messaging (auch als SECM-Verfahren bezeichnet) betrifft also die Datenübertragung über eine Schnittstelle, die gegen Manipulationen und/oder gegen Abhören gesichert ist.
  • Um die Flexibilität und Funktionalität von Applikationen oder Services zu erhöhen, ist es im Stand der Technik des Weiteren bekannt, entfernte Funktionsaufrufe, so genannte Remote Procedure Calls (kurz auch als RPC bezeichnet), zu verwenden. Allerdings sind bisher im Stand der Technik noch keine Verfahren bekannt, wie eine gesicherte Datenübertragung bei einem Einsatz von RPC-Befehlen gewährleistet werden kann, ohne dass z.B. jeweils ein eigener gesicherter Kanal für jede beteiligte Instanz aufgebaut werden muss (was mit deutlichen Nachteilen bezüglich der Ressourcen verbunden ist).
  • Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, um entfernte Funktionsaufrufe (Remote Procedure Calls), die direkt auf dem mobilen Datenträger – insbesondere auf der Chipkarte – ausgeführt werden, mit einem zusätzlichen Sicherheits-Mechanismus zu kombinieren, während die Ressourcen der beteiligten Instanzen in möglichst beschränktem Umfang beansprucht werden. Insbesondere soll die Flexibilität und die Performance beim Einsatz von RPC-Befehlen auf einem mobilen Datenträger erhöht werden, ohne dass Einbußen im Hinblick auf die Sicherheit entstehen. Des Weiteren sollen die vorstehend erwähnten Grenzen und Nachteile aus dem Stand der Technik überwunden werden.
  • Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren zur Authentisierung zwischen zumindest zwei Instanzen, die einem mobilen Datenträger, insbesondere einer Chipkarte, zugeordnet sind, wobei ein Ausführen von RPC-Befehlen in Zusammenhang mit dem mobilen Datenträger unterstützt wird, indem eine rufende Instanz den RPC-Befehl an eine gerufene Instanz zur Ausführung sendet, und wobei das Verfahren auf Sicherheits-Mechanismen, insbesondere Secure Messaging, basiert, die zumindest die Authentizität und bei Bedarf die Vertraulichkeit der zu übertragenden Daten oder Teilen davon sicherstellen, mit folgenden Verfahrensschritten:
    • – Erzeugen und/oder Erfassen von Secure Messaging-Datensätzen, insbesondere von einer Authentisierungsinformation in Bezug zumindest eine der beteiligten Instanzen, insbesondere in Bezug auf die rufende Instanz
    • – Übertragen von Parametern für den RPC-Befehl und Übertragen des RPC-Befehls von der rufenden Instanz an die gerufene Instanz,
    • – Generieren von Ergebnissen des RPC-Befehls durch Ausführen desselben auf der gerufenen Instanz und insbesondere auf dem mobilen Datenträger und
    • – Übertragen von Ergebnissen des RPC-Befehls von der gerufenen Instanz an die rufende Instanz,
    wobei mit dem Übertragen der Parameter für den RPC-Befehl und/oder mit dem Übertragen der Ergebnisse für den RPC-Befehl die Secure-Messaging-Datensätze übertragen werden und wobei während des Verfahrens eine Überprüfung der Secure Messaging-Datensätze erfolgt.
  • Die vorliegende Erfindung wird nachstehend in Bezug auf die verfahrensgemäße Lösung der Aufgabe beschrieben. Die hier erwähnten alternativen Ausführungsformen, Vorteile und besonderen Merkmale der Erfindung sind ebenso auf die anderen Lösungen und insbesondere auf die vorrichtungs- und systembezogenen Lösungen und auf die Lösung durch das Computerprogrammprodukt zu übertragen.
  • Vorab sei an dieser Stelle darauf hingewiesen, dass die vorliegende Erfindung nicht auf die Aufzählungsreihenfolge der Verfahrensschritte beschränkt ist. Die in der Beschreibung und/oder in den Ansprüchen erwähnte Aufzählungsreihenfolge soll deshalb nicht einschränkend für den Schutzbereich verstanden werden. In alternativen Ausführungsformen der Erfindung ist auch eine andere Reihenfolge denkbar oder es ist möglich, einzelne Verfahrensschritte teilweise oder vollständig parallel oder ineinander verzahnt (in einem interleaved Modus) auszuführen.
  • Bei der gesicherten Datenübertragung handelt es sich um eine Datenübertragung, die Sicherheits-Mechanismen berücksichtigt. Die in diesem Zusammenhang anwendbaren Mechanismen und Verfahren können auch als Secure Messaging bezeichnet werden. Darunter zählen Verfahren, die die Authentizität eines Kommunikationspartners, die Identität eines Kommunikationspartners, die Vertraulichkeit der zu übertragenden Daten und/oder die Verbindlichkeit der zu übertragenden Daten und/oder die Geheimhaltung der zu übertragenden Daten sicherstellen. Unter dem Begriff "Verbindlichkeit" der übertragenen Daten soll in diesem Zusammenhang die Möglichkeit des Absenders verstanden werden, zu überprüfen, ob ein bestimmter Empfänger eine Nachricht erhalten hat. Ein Abstreiten des Empfangs einer Nachricht ist bei einer verbindlichen Datenübertragung nicht mehr möglich. Welche der vorstehend erwähnten Mechanismen im Rahmen der gesicherten Datenübertragung erfindungsgemäß angewendet werden, kann auf den jeweiligen Anwendungsfall hin dynamisch und flexibel bestimmt werden. Üblicherweise wird für das Secure Messaging ein gesicherter Kanal aufgebaut, über den die zu übertragenden Daten ausgetauscht werden. Ein wichtiger Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass es ausreichend ist, einen gesicherten Kanal zur Datenübertragung zur Verfügung zu stellen, über den dann ein Zugriff gegebenenfalls verschiedener Instanzen auf gesicherte Weise erfolgt. Es ist also nicht notwendig, dass für jede (auf entfernte bzw. auf „fremde" Datensätze zugreifende) Instanz ein separater, eigener gesicherter Kanal aufgebaut werden muss. Damit können die Ressourcen des gesamten Systems deutlich geschont werden.
  • "Secure-Messaging-Datensätze" sind im Rahmen dieser Erfindung Datensätze, die im Zusammenhang mit einem Sicherheits-Mechanismus für die Datenübertragung relevant sind. Erfindungsgemäß können jedoch unterschiedliche Sicherheits-Mechanismen angewendet werden, so dass der Inhalt der Secure-Messaging-Datensätze inhaltlich unterschiedlich gestaltet sein kann.
  • Üblicherweise umfasst der Secure-Messaging-Datensatz jedoch eine Authentisierungsinformation. In einer vorteilhaften Weiterbildung der Erfindung umfasst der Secure-Messaging-Datensatz zusätzlich Vertraulichkeitsinformationen. Dieses Merkmal ist jedoch optional. Zweck der Authentisierung ist die Überprüfung der Authentizität und/oder der Identität der jeweiligen Partnerinstanz. Die Authentisierungsinformation dient also insbesondere dazu, festzustellen, ob es sich bei der Karte oder bei dem Terminal tatsächlich um eine echte Karte oder um ein echtes Terminal handelt. Die Authentisierungsinformation bzw. der Authentisierungs-Datensatz verweist somit eindeutig auf eine Instanz oder eine Person. Im Sinne dieser Erfindung ist der Begriff der „Identifikation" von dem Begriff „Authentisierung" umfasst.
  • Auf welchen Authentisierungsverfahren die erfindungsgemäße Authentisierungsinformation basiert, ist von Anwendungsfall zu Anwendungsfall unterschiedlich. Grundsätzlich können erfindungsgemäß unterschiedliche Authentisierungsverfahren eingesetzt werden, insbesondere eine asymmetrische oder symmetrische Authentisierung, eine einseitige oder gegenseitige sowie eine statische oder dynamische Authentisierung.
  • Abhängig von dem verwendeten Protokoll für die Übertragung der RPC-Befehle kann der Authentisierungs-Datensatz bzw. die Authentisierungsinformation unterschiedliche Formate haben. Bei der Übertragung der RPC-Befehle über die Protokolle SOAP (SOAP: Simple Object Access Protocol) oder über XML-RPC kann die Authentisierungsinformation aus einer digitalen XML-Signatur über die zu übertragenden Daten bestehen. Die Authentisierungsinformation kann in anderen Fällen jedoch auch auf einem anderen Protokoll basieren und somit eine modifizierte digitale Signatur umfassen. In einer komplexen Weiterbildung der Erfindung kann die Authentisierungsinformation alternativ oder kumulativ von einer signierenden Zertifizierungsinstanz signierte Zertifikate oder andere Identifikations-Mechanismen umfassen.
  • Im Sinne dieser Erfindung kann ein mobiler Datenträger eine Chipkarte, eine Smartkarte oder eine sonstige Karte mit einem Mikroprozessor sein oder er kann auch ein komplexes elektronisches Bauteil oder Gerät sein, wie z.B. ein Sicherheitstoken oder anderer mobiler Träger von digitalen Daten, die jeweils mit entsprechenden Schnittstellen zur Datenkommunikation ausgestattet sind.
  • Unter einer "Instanz" sind im Rahmen dieser Erfindung alle Einheiten bzw. Module zu verstehen, die bei einer Datenübertragung beteiligt sind. Insbesondere gibt es eine rufende Instanz, die Daten von einer anderen Instanz anfordert und zum Empfang dieser Daten bestimmt ist. Daneben gibt es eine gerufene Instanz, die einen bestimmten Befehl empfängt und zur Ausführung dieses Befehls bestimmt ist. Nach Ausführung des Befehls auf der gerufenen Instanz wird das Ergebnis des Befehls an die rufende Instanz zurückgesendet. Insbesondere dienen die rufende Instanz zur Ausgabe eines RPC-Befehls und die gerufene Instanz zur Ausführung des RPC-Befehls und zur Ausgabe eines Ergebnisses. Selbstverständlich ist im Rahmen der gesamten Datenübertragung zwischen den Instanzen neben den RPC-Befehlen auch jede andere Art von Datenaustausch möglich. Bei einer Instanz kann es sich um Funktionen, Prozeduren oder komplexere Programmteile bzw. Programme, aber auch um separate elektronische Geräte oder Bauteile handeln. Eine Instanz kann unmittelbar oder direkt auf dem mobilen Datenträger ablaufen. Darüber hinaus ist es möglich, dass eine Instanz nicht unmittelbar auf dem mobilen Datenträger abläuft, sondern diesem nur indirekt zugeordnet ist, indem sie auf einer externen Einheit abläuft, die in Datenaustausch mit dem mobilen Datenträger steht. Dabei kann es sich z. B. um ein Chipkartenterminal oder um ein sonstiges Back-Office handeln.
  • Erfindungsgemäß werden als Kommunikationsmechanismus RPC-Befehle eingesetzt. In einer Ausführungsform der Erfindung werden für den gesamten Datenaustausch ausschließlich RPC-Befehle verwendet. Alternativ dazu können in anderen Ausführungsformen auch weitere Kommunikations-Strukturen vorgesehen sein.
  • Das grundlegende Prinzip der RPC-Befehle besteht darin, die Möglichkeit bereitzustellen, dass auch Funktionen auf entfernten Instanzen, Einheiten, Plattformen oder Rechnern (also nicht lokal) ausgeführt werden können. Damit können Programmfunktionen auch über Rechnergrenzen hinweg und zusammen mit anderen Applikationen genutzt werden. Es gibt verschiedene Varianten für die Ausführung von RPC-Calls, wie z.B. die auf dem Java-Standard basierenden RMIs (remote method invocations) oder so genannte Web-Services, die z.B. auf Protokollen wie SOAP (SOAP: Simple Object Access Protocol) oder XML-RPC basieren. Eine RPC-Struktur basiert auf einem RPC-Client und einem RPC-Server. Im Rahmen dieser Erfindung sind in der Regel die rufende Instanz als RPC-Client und die gerufenen Instanz als RPC-Server ausgebildet.
  • Mit der Verwendung von RPC-Befehlen kann vorteilhafterweise eine wesentlich höhere Funktionalität und Komplexität des Gesamtsystems zur Verfügung gestellt werden.
  • Erfindungsgemäß und angewendet auf die Chipkarten-Technologie bedeutet dies, dass auch auf Prozeduren zugegriffen werden kann, die entweder bei Multi-Applikations-Systemen (also bei Systemen, bei denen mehrere Applikationen auf einer Karte betrieben werden können) einer anderen Applikation auf derselben Karte zugeordnet sind oder die von einer externen Instanz direkt auf der Chipkarte ausgeführt werden sollen. Der RPC-Client und/oder der RPC-Server können also auf demselben oder einem anderen mobilen Datenträger oder in einem (Chipkarten) Terminal vorgesehen sein.
  • Bei den vorstehend erwähnten Multi-Applikations-Betriebssystemen der neuen Generation ist es möglich, mehrere Applikationen auf einer Karte zu vereinen und zu kombinieren (wie z. B. die Applikationen einer Gesundheitskarte, einer Telefonkarte etc.). Auch für diese Multi-Applikations-Betriebssysteme ist es erfindungsgemäß möglich, dass direkt RPC-Befehle auf der Chipkarte ausgeführt werden. In diesem Zusammenhang sind beispielsweise bestimmte Web-Services zu erwähnen, die einen Zugriff auf unterschiedlichste Dienste über internet-basierte Protokolle ermöglichen. Je nach Anwendungsfall und insbesondere bei der Datenübertragung von sicherheitskritischen Informationen ist es erforderlich, zusätzliche Sicherheits-Mechanismen vorzusehen, selbst wenn zuvor bereits ein gesicherter Kanal aufgebaut worden ist. Im Hinblick auf diese Technologie ist also erfindungsgemäß ein Zugriff verschiedener Instanzen innerhalb eines gesicherten Kanals möglich, der durch zusätzliche Sicherheitsmechanismen gesichert wird. Damit kann neben der Flexibilität auch die Performance gesteigert werden, da der ressourcen-intensive Aufbau eines separaten, eigenen, gesicherten Kanals für jede Instanz nicht notwendig ist.
  • In der bevorzugten Ausführungsform läuft die gerufene Instanz, die zur Ausführung des RPC-Befehls dient, auf dem mobilen Datenträger, insbesondere auf der Chipkarte ab. Bei dem Aufruf einer RPC-Funktion soll diese also direkt auf der Chipkarte ausgeführt werden. Zum Zwecke eines Secure Messaging wird erfindungsgemäß dieser RPC-Aufruf mit dem Secure-Messaging-Datensatz kombiniert. Mit anderen Worten wird erfindungsgemäß neben dem eigentlichen entfernten Funktionsaufruf und/oder neben den Parametern für den Funktionsaufruf noch ein weiterer Datensatz übertragen. Dieser weitere Datensatz betrifft die Secure-Messaging-Daten, insbesondere die Authentisierungsinformation, in Bezug auf die beteiligten Instanzen.
  • Es ist möglich, dass sich die Authentisierungsinformation auf den vollständigen Satz von zu übertragenden Parametern für den RPC-Befehl bezieht. Alternativ ist es ebenso möglich, dass die Authentisierungsinformation nur einen Teil der zu übermittelnden Parameter in Bezug auf den RPC-Befehl betrifft. Dies hat den Vorteil, dass der Umfang der zu übertragenden Daten im Rahmen der Ausführung des RPC-Befehls verringert werden kann.
  • Erfindungsgemäß sind mehrere Möglichkeiten vorgesehen, von welcher Instanz die Authentisierungsinformation bereitgestellt und/oder generiert wird.
  • Einerseits ist es möglich, dass die Authentisierungsinformation von der rufenden Instanz angegeben wird. Alternativ dazu ist es andererseits möglich, dass die Authentisierungsinformation nicht von der rufenden Instanz bereitgestellt wird, sondern automatisiert von einer Middleware generiert wird. Als "Middleware" soll im Rahmen dieser Erfindung eine Technologie verstanden werden, die anwendungs-unabhängig ist und unterschiedliche Dienstleistungen zur Vermittlung zwischen separaten Applikationen anbietet. Es handelt sich sozusagen um eine von der eigentlichen Anwendung entkoppelte Plattform zur Vermittlung von Funktionsaufrufen zwischen einzelnen Instanzen und organisiert den Transport komplexer Daten. Es ist also möglich, Remote Procedure Calls über eine Middleware abzuwickeln.
  • In diesem Fall kann die Authentisierungsinformation automatisiert von der Middleware generiert werden.
  • Erfindungsgemäß wird die Authentisierungsinformation in Kombination mit der Übermittlung der Parameter für den entfernten Funktionsaufruf, also dem RPC-Befehl, übertragen. Dafür sind wiederum unterschiedliche Möglichkeiten vorgesehen. Einerseits ist es möglich, die Authentisierungsinformation mit der Übersendung der Parameter für den Funktionsaufruf und/oder mit der Übersendung des Funktionsaufrufes an sich zu kombinieren. Vorzugsweise ist die Authentisierungsinformation an die Übermittlung der Parameter eines Funktionsaufrufes zur Chipkarte gebunden. In diesem Fall kann die Authentisierungsinformation insbesondere in das Marshalling eingebunden werden (dabei bezeichnet "Marshalling" die Entgegennahme und das Umwandeln einer Menge von strukturierten Datenelementen in ein Format, welches erforderlich ist, um die Datenelemente in einer Nachricht an einen Empfänger zu schicken).
  • Andererseits ist es möglich, die Authentisierungsinformation an das Ergebnis des RPC-Befehls zu binden. In diesem Fall ist die Authentisierungsinformation an die Antwort der Chipkarte auf den RPC-Befehl gebunden. Als „Ergebnis" des RPC-Befehls sollen hier alle Rückgabewerte auf den RPC-Befehl verstanden werden, die gegebenenfalls neben der eigentlichen Antwort zurück gesendet werden.
  • Alternativ dazu können die Authentisierungsinformationen auch nach der Übertragung des eigentlichen RPC-Befehls erfolgen, insbesondere in einem Abspann nach der RPC-Sequenz.
  • Erfindungsgemäß umfasst das Verfahren eine Überprüfung der Authentisierungsinformation. Für die Überprüfung sind erfindungsgemäß ebenfalls unterschiedliche Varianten vorgesehen. So ist es möglich, dass die Überprüfung direkt auf der Chipkarte oder auf dem Sicherheits-Device erfolgt, an die/das der RPC-Befehl adressiert worden ist. In alternativen Ausführungsformen kann es jedoch auch vorgesehen sein, die Überprüfung der Authentisierung in anderen Instanzen oder auf einem externen Modul ausführen zu lassen.
  • Es ist auch möglich, die Funktionalität zur Überprüfung der Authentisierung verteilt zu realisieren. In diesem Fall wird die Authentisierung sowohl auf der Chipkarte als auch auf zumindest einer externen Einheit ausgeführt. Bei der externen Einheit kann es sich um ein Chipkarten-Terminal oder um ein sonstiges Back-Office im Zusammenhang mit der Übertragung einer Chipkarte handeln.
  • In einer weiteren vorteilhaften Weiterbildung der Erfindung ist es vorgesehen, dass nach der Authentisierung eine Autorisierung für weitere Aktionen erfolgt, insbesondere auf Basis der mit dem RPC-Befehl übermittelten Daten. Mit anderen Worten können nach der Überprüfung der Authentisierung auf dem mobilen Datenträger, insbesondere auf dem Sicherheits-Device, Folgeberechtigungen vergeben werden. Möglichkeiten, wie dies technisch realisiert werden kann, sind in der Druckschrift DE-102 34 158 erwähnt, deren Inhalt in diesem Zusammenhang vollinhaltlich miteinbezogen wird.
  • Ein Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass das Verfahren grundsätzlich an das gewählte Übertragungsprotokoll angepasst werden kann. Dies wird erreicht, indem unterschiedliche Formate für den Secure-Messaging-Datensatz, insbesondere für die Authentisierungsinformation, vorgesehen sind. Abhängig von dem jeweils verwendeten RPC-Protokoll kann dann das Format für den Authentisierungs-Datensatz dynamisch eingestellt werden.
  • Ein weiterer Vorteil der erfindungsgemäßen Lösung ist darin zu sehen, dass eine erhöhte Flexibilität erreicht werden kann, indem den unterschiedlichen Instanzen jeweils separat und/oder unabhängig voneinander ein Secure-Messaging-Datensatz zugeordnet werden kann. Damit wird es möglich, unterschiedliche Instanzen jeweils separat hinsichtlich der Sicherheits-Mechanismen zu überprüfen. Insbesondere ist es möglich, unterschiedliche Instanzen jeweils separat und/oder jeweils getrennt voneinander zu authentisieren. Erfindungsgemäß können also mit den Funktionsaufrufen, insbesondere mit den RPC-Strukturen, flexible Authentisierungen von unterschiedlichen Instanzen verbunden werden – und zwar unabhängig von dem gesicherten Kanal, über den die Datenübertragung erfolgt, insbesondere über den die Funktionsaufrufe abgewickelt werden.
  • Das erfindungsgemäße Verfahren betrifft auch die Abwicklung und/oder Verwaltung von RPC-Strukturen bei der Datenübertragung von oder zu einer Chipkarte. Dafür sind vorteilhafterweise unterschiedliche Varianten vorgesehen, je nachdem, wie die Chipkarte betrieben wird. Für das Betreiben einer Chipkarte gibt es heute unterschiedliche Kategorien von Betriebssystemen. Die üblichen Betriebssysteme basieren auf einer Anwendung pro Chipkarte und können auch als Single-Application-Systems bezeichnet werden. Im Unterschied dazu ist bei moderneren Systemen ein gleichzeitiger Betrieb von mehreren Anwendungen bzw. Applikationen auf einer Chipkarte vorgesehen. Diese Systeme werden Multi-Applikations-Systeme genannt. Als Beispiel ist hier die kombinierte Anwendung einer GSM-Applikation, einer Scheduling-Applikation und/oder Applikationen zum Transfer von elektronischen Geldeinheiten zu nennen. Solche multi-tasking-fähigen Betriebssysteme basieren in der Regel auf einem Multi-Tasking-Kernel. Ein weiterer wesentlicher Vorteil der erfindungsgemäßen Lösung ist in diesem Zusammenhang darin zu sehen, dass die Erfindung sowohl im Rahmen der bisher üblichen Single-Application-Systeme als auch bei den modernen Multi-Applikations-Systemen angewendet werden kann.
  • Zumindest eine der beiden Kommunikations-Instanzen läuft auf dem mobilen Datenträger, insbesondere auf der Chipkarte, ab. Üblicherweise ist dies die gerufene Instanz, die zur Ausführung des RPC-Befehls dient. Handelt es sich um ein Multi-Applikations-System, so kann die jeweils andere Instanz, also die rufende Instanz, einer anderen Applikation auf derselben Chipkarte zugeordnet sein. Bei einem Betriebssystem, das nur jeweils eine einzelne Anwendung unterstützt, kann die rufende Instanz einer externen Umgebung zugeordnet sein. Bei der externen Umgebung kann es sich um jede andere beliebige Instanz handeln, die in Datenaustausch mit der Chipkarte steht. Insbesondere sind hier Web-Services zu nennen, die auf einer Datenübertragung über das Internet basieren. Dieses Merkmal betrifft vor allem netzwerkfähige Internet-Chipkarten. Bei modernen multi-tasking-fähigen oder multi-user-fähigen Chipkarten-Betriebssystemen kann erfindungsgemäß ein weiteres Einsatzgebiet abgedeckt werden, indem mit entfernten Funktionsaufrufen flexible Authentisierungen von unterschiedlichen Instanzen unabhängig von dem gesicherten Kanal zur Datenübertragung, über den die Funktionsaufrufe übertragen werden, kombiniert werden können.
  • Eine weitere Aufgabenlösung besteht in einem mobilen Datenträger, insbesondere in einer Chipkarte, in einem Sicherheitstoken oder in einem Chipkarten-Modul gemäß Anspruch 12, in einer komplexeren Vorrichtung, die mit einem solchen mobilen Datenträger ausgestattet ist, entsprechend Patentanspruch 13. Bei der Vorrichtung kann es sich um ein beliebiges elektronisches Gerät handeln, vorzugsweise um ein tragbares Gerät wie ein Handy oder ein PDA, das mit einem mobilen Datenträger ausgestattet ist. Weitere Aufgabenlösungen sind in einem System gemäß Patentanspruch 14 und in einem Computerprogrammprodukt gemäß Patentanspruch 15 zu sehen.
  • Es ist möglich, dass das erfindungsgemäße Verfahren als separates bzw. selbständiges Modul in Form eines Software-Moduls oder einer Applikation ausgebildet ist, die das bisherige Übertragungsverfahren erfindungsgemäß erweitert. Ebenso ist es möglich, dass alle oder einzelne Verfahrensschritte in Hardware-Bauteilen realisiert werden können.
  • Eine alternative Aufgabenlösung sieht eine Schnittstelle in Bezug auf einen mobilen Datenträger vor, die gemäß dem vorstehend beschriebenen Verfahrens gesteuert und/oder betrieben wird.
  • Zusätzliche vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
  • In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. Es zeigen:
  • 1 eine schematische Darstellung von übertragenen Remote Procedure Calls gemäß einer bevorzugten Ausführungsform der Erfindung,
  • 2 eine schematische Darstellung eines Protokollstacks, der bei einer bevorzugten Ausführungsform der Erfindung zum Einsatz kommt und
  • 3 eine übersichtsartige Darstellung von Modulen gemäß einer bevorzugten Ausführungsform der Erfindung.
  • Die Erfindung betrifft ein Verfahren zur gesicherten Datenübertragung zwischen mehreren Instanzen Ri, Gi, wobei zumindest eine gerufene Instanz Gi auf einem mobilen Datenträger, insbesondere auf einer Chipkarte C abläuft. Die Datenübertragung kann eine Ausführung von entfernten Funktionsaufrufen, nämlich Remote Procedure Calls RPC-B, RPC-E umfassen.
  • In der bevorzugten Ausführungsform ist zumindest eine rufende Instanz Ri vorgesehen, die einen RPC-Befehl RPC-B absetzt und zur Ausführung an eine entsprechende gerufene Instanz Gi auf der Chipkarte C sendet. Die gerufene Instanz Gi auf der Chipkarte C führt den RPC-Befehl RPC-B aus und sendet eine Antwort bzw. ein Ergebnis RPC-E auf den RPC-Befehl RPC-B an die rufende Instanz Ri zurück.
  • Grundsätzlich werden mit dem RPC-Befehl RPC-B weitere Informationen in Bezug auf denselben übertragen. Dabei handelt es sich um Meta-Informationen, z.B. wann und von wem der RPC-Befehl ausgeführt werden soll etc. Diese Meta-Informationen werden hier und im Folgenden Parameter genannt.
  • In 3 ist die erfindungsgemäße Datenübertragung schematisch dargestellt. Eine RPC-Befehlsstruktur basiert auf einem Client-Server-Ansatz und wird üblicherweise synchron abgewickelt. Das heißt, dass eine rufende In stanz Ri einen RPC-Befehl RPC-B absetzt und so lange wartet, bis sie von der gerufenen Instanz Gi das entsprechende Ergebnis RPC-E auf den RPC-Befehl RPC-B empfängt. Während die rufende Instanz Ri wartet, arbeitet die gerufene Instanz Gi den RPC-Befehl ab.
  • Damit bei der Abarbeitung von RPC-Befehlen Sicherheits-Mechanismen eingesetzt werden können, ohne dass die Ressourcen der beteiligten Instanzen Ri, Gi unnötig stark in Anspruch genommen werden, ist es erfindungsgemäß vorgesehen, dass ein Aufruf von zumindest einer entfernten Funktion über einen RPC-Befehl RPC-B, der direkt auf der Chipkarte C ausgeführt werden soll, mit einem Secure Messaging-Datensatz kombiniert wird. In der bevorzugten Ausführungsform handelt es sich bei dem Secure Messaging-Datensatz um eine Authentisierungsinformation A. In alternativen Ausführungsformen der Erfindung können neben der Authentisierungsinformation A noch weitere sicherheitsrelevante Datensätze berücksichtigt werden. Die Authentisierungsinformation A dient unter anderem zur Identifizierung und verweist in der bevorzugten Ausführungsform auf die jeweils rufende Instanz Ri. In alternativen Ausführungsformen der Erfindung verweist die Authentisierungsinformation auf die gerufene Instanz Gi oder auf beide Instanzen Ri, Gi.
  • Üblicherweise wird die Authentisierungsinformation A zusammen mit Parametern kombiniert, die in Zusammenhang mit dem Funktionsaufruf RPC-B übermittelt werden. Alternativ oder kumulativ kann die Antwort von der Chipkarte C, also das Ergebnis RPC-E des RPC-Befehls RPC-B, mit einer Authentisierungsinformation A versehen sein.
  • Erfindungsgemäß ist es vorgesehen, dass die Authentisierungsinformation A überprüft wird. Die Überprüfung kann entweder auf der Chipkarte C oder auf einer anderen Einheit erfolgen, an die der RPC-Befehl RPC-B adressiert worden ist.
  • Wie in 3 dargestellt, ist es möglich, dass der Datenaustausch zwischen den beteiligten Instanzen Ri und Gi über eine so genannte Middleware abgewickelt wird, die die entsprechenden Befehle umsetzt. In dieser Ausführungsform können die RPC-Daten einschließlich der notwendigen Parameter und die Authentisierungsinformationen A auch getrennt voneinander übertragen werden. Wird als Übertragungsprotokoll ein Protokoll nach dem Standard ISO/IEC 7816-4 verwendet, so sind die Übertragungseinheiten als APDU's (APDU steht für Application Protocol Data Unit) ausgebildet. In diesem Fall können die RPC-Daten mit den Authentisierungsinformationen A in mehreren unterschiedlichen APDU-Sequenzen übermittelt werden. In der Regel ist die Authentisierungsinformation A auf mehrere zu übertragende Dateneinheiten der Anwendungsschicht (insbesondere auf mehrere APDU's) verteilt (siehe in diesem Zusammenhang ISO 7816 und ISO WD 24727 Teil 2, Generic Card Edge oder RMI im Javacard 2 Standard).
  • Wie in 1 gezeigt, ist es möglich, dass mehrere unterschiedliche rufende Instanzen Ri vorgesehen sind. In 1 ist der Fall dargestellt, dass es zwei rufende Instanzen R1 und R2 gibt, die entsprechende RPC-Befehle RPC-B an die Chipkarte C übermitteln. Nach Abarbeitung des RPC-Befehls auf der Chipkarte C kann von dieser die Antwort bzw. ein Ergebnis RPC-E an die rufende Instanz Ri zurück übertragen werden. Abhängig von der Konfiguration des Verfahrens wird die Authentisierungsinformation A mit der RPC-Anfrage RPC-B und/oder mit der RPC-Antwort RPC-E übertragen.
  • Ein besonderer Vorteil der erfindungsgemäßen Lösung ist deshalb darin zu sehen, dass die erfindungsgemäße Übertragung dynamisch konfiguriert werden kann. Hierzu können entsprechende Einstellungen über Konfigurations-Parameter getroffen werden, die z. B. angeben, welches RPC-Protokoll verwendet wird, in welchem Format der Authentisierungs-Datensatz A vorliegen soll, ob die Authentisierungsinformation A alle oder nur einen Teil der zu übermittelnden Parameter betrifft, ob die Authentisierungsinformation A mit dem RPC-Befehl RPC-B und/oder mit dem RPC-Ergebnis RPC-E übertragen werden sollen und/oder auf welcher Instanz Ri, Gi eine Überprüfung der Authentisierung erfolgen soll.
  • In alternativen Ausführungsformen sind hier noch weitere Einstellungen über die jeweiligen Konfigurations-Parameter möglich. Damit kann das erfindungsgemäße Verfahren dynamisch an den jeweiligen Anwendungsfall angepasst werden. Erfindungsgemäß können also flexible Authentisierungen unterschiedlicher Instanzen Ri, Gi verbunden werden, unabhängig von dem gesicherten Kanal, über den die Funktionsaufrufe RPC-B, RPC-E abgewickelt werden.
  • Wie in 1 dargestellt, ist es erfindungsgemäß möglich, einzelne RPC-Strukturen (zumindest bestehend aus einem Befehl und/oder einem Befehlsergebnis) RPC-B, RPC-E mit einer jeweils individuellen Authentisierungsinformation A zu versehen. Es gibt also eine individuelle erste Authentisierungsinformation A1 für die erste RPC-Struktur RPC-B1/RPC-E1 der ersten Instanz R1 und eine zweite Authentisierungsinformation A2 für die zweite RPC-Struktur RPC-B2/RPC-E2 der zweiten Instanz R2. Der Aufbau bzw. das Bereitstellen eines zusätzlichen gesicherten Kanals ist vorteilhafterweise nicht zwingend erforderlich. Ein solcher zusätzlicher Kanal, der ebenfalls auf einer Authentisierung beruht, ist lediglich optional.
  • In 2 ist ein Protokoll-Stack dargestellt, der bei dem erfindungsgemäßen Verfahren gemäß einer bevorzugten Ausführungsform zum Einsatz kommt. Entsprechend dem ISO-OSI-Modell sind die jeweiligen Schichten hierarchisch gegliedert. Die unterste Schicht betrifft eine Transportschicht, die nach den Übertragungsprotokollen ISO/IEC 7816-3 T = 0 (asynchron, Halbduplex, byte-orientiert), T = 1 (asynchron, Halbduplex, block-orientiert), nach dem USB-Standard oder nach dem MMC-Standard, etc. ausgebildet sein kann. Darüber kann als optionales Merkmal eine Netzwerkschicht angeordnet sein, z. B. eine TCP/IP-Schicht. Über der Netzwerkschicht kann ebenfalls als optionales Element eine Sicherungsschicht ausgebildet sein. Diese kann auf den Protokollen SSL oder SECM oder auf anderen Protokollen beruhen. Als oberste Schicht ist die Applikationsschicht zu nennen, die erfindungsgemäß auf einem modifizierten Applikationsprotokoll für die Übertragung von RPC-Befehlen RPC-B, RPC-E mit Authentisierungsdaten A ausgebildet ist.
  • Mit anderen Worten betrifft die Erfindung eine Zusatz-Funktionalität zur Ausbildung einer entsprechenden Schnittstelle zur Kommunikation mit einem mobilen Datenträger C und unterschiedlichen Instanzen Ri, Gi. Die Modifikation betrifft die kombinierte Übertragung von RPC-Befehlen RPC-B, RPC-E und Authentisierungsinformationen A. Die erfindungsgemäße Schnittstelle wird mit dem oben beschriebenen Verfahren gesteuert und/oder betrieben.
  • Durch die flexible Konfigurierbarkeit der erfindungsgemäßen Schnittstelle kann diese optimiert auf den jeweiligen Anwendungsfall hin ausgelegt werden. Insbesondere ist es einstellbar, welche Sicherheitsmechanismen zum Einsatz kommen sollen, z. B. eine Sicherung gegen Manipulationen mit dem Authentic-Verfahren und/oder gegen ein Abhören durch entsprechende Verschlüsselungs-Mechanismen, insbesondere mittels des Combined-Verfahrens.
  • Ein besonderer Vorteil ist darüber hinaus darin zu sehen, dass die vorliegende Erfindung auch auf Chipkarten-Betriebssysteme der neuen Generation angewendet werden kann, wie z. B. auf Multi-Applikations-Systeme, die auf einem Multi-Tasking Kernel basieren (MTK, Javacard3). In diesem Fall kann eine rufende Instanz Ri, die einer ersten Applikation auf der Chipkarte C zugeordnet ist, eine gerufene Instanz Gi aufrufen, die einer anderen Applikation auf derselben Chipkarte C zugeordnet ist. Erfindungsgemäß kann ein gesicherter Datenaustausch zwischen den beiden Instanzen gewährleistet werden.
  • In einer alternativen Weiterbildung der Erfindung ist es vorgesehen, dass die RPC-Strukturen nicht synchron, sondern in Verbindung mit Threads, und unter Einsatz eines Multi-Threading-Betriebssystems asynchron abgewickelt werden.
  • In der bevorzugten Ausführungsform ist eine java-basierte Realisierung des erfindungsgemäßen Verfahrens vorgesehen. Zu diesem Zweck wird das so genannte RMI-Verfahren (RMI steht für „remote method invocation") verwendet, das für entfernte Funktionsaufrufe zwischen Java-Objekten vorgesehen ist und gegebenenfalls auf eine Java-Klassen-Bibliothek zurückgreift, über die die Aufrufe abgewickelt werden.
  • Abschließend sei darauf hingewiesen, dass die Beschreibung der Erfindung und die dargestellten Ausführungsbeispiele grundsätzlich nicht einschränkend im Hinblick auf eine bestimmte physikalische Realisierung der Erfindung zu verstehen sind und somit auch in verschiedenster Weise modifiziert werden können, ohne den Bereich der Erfindung zu verlassen. Für einen Fachmann ist es insbesondere offensichtlich, dass die Erfindung auch als heterogenes System teilweise oder vollständig durch Software- und/oder Hardware-Module und/oder auf mehrere physikalische Produkte – dabei insbesondere auch Computerprogrammprodukte – verteilt realisiert werden kann.

Claims (15)

  1. Verfahren zur gesicherten Datenübertragung zwischen zumindest zwei Instanzen (Ri, Gi), die einem mobilen Datenträger (C) zugeordnet sind, wobei ein Ausführen von RPC-Befehlen (RPC-B) zwischen den Instanzen (Ri, Gi) und/oder dem mobilen Datenträger (C) unterstützt wird, indem eine rufende Instanz (Ri) den RPC-Befehl (RPC-B) an eine gerufene Instanz (Gi) zur Ausführung sendet, und wobei das Verfahren auf einem Secure Messaging basiert, mit folgenden Verfahrensschritten: – Erzeugen und/oder Erfassen und/oder von Secure-Messaging Datensätzen, insbesondere von einer Authentisierungsinformation (A), – Übertragen des RPC-Befehls (RPC-B) und von Parametern für den RPC-Befehl (RPC-B) von der rufenden (Ri) an die gerufene (Gi) Instanz, – Ausführen des RPC-Befehls (RPC-B) auf der gerufenen Instanz (Gi) und – Übertragen von Ergebnissen (RPC-E) des RPC-Befehls (RPC-B) von der gerufenen Instanz (Gi) an die rufende Instanz (Ri), wobei mit dem Übertragen der Parameter für den RPC-Befehl (RPC-B) und/oder mit dem Übertragen der Ergebnisse (RPC-E) für den RPC-Befehl die Secure-Messaging Datensätze übertragen werden und wobei während des Verfahrens eine Überprüfung der Secure-Messaging Datensätze erfolgt.
  2. Verfahren nach Patentanspruch 1, dadurch gekennzeichnet, dass die Überprüfung der Secure-Messaging Datensätze auf dem mobilen Datenträger (C) erfolgt.
  3. Verfahren nach zumindest einem der Patentansprüche 1 oder 2, dadurch gekennzeichnet, dass unterschiedliche Instanzen jeweils separat und/oder unabhängig voneinander authentisiert werden können, falls das Secure Messaging auf Authentisierungsinformation (A) basiert.
  4. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass der RPC-Befehl (RPC-B) über eine Middleware umgesetzt wird und/oder dass die Secure-Messaging-Datensätze auf mehrere zu übertragende, protokoll-unabhängige Einheiten aufgeteilt sind, die insbesondere getrennt übertragen werden können.
  5. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass die Secure-Messaging-Datensätze alle oder nur einen Teil der zu übermittelnden Parameter betreffen.
  6. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass die Secure-Messaging-Datensätze direkt mit dem RPC-Befehl (RPC-B) und/oder mit den Parametern für den RPC-Befehl (RPC-B) und/oder mit den Ergebnissen (RPC-E) des RPC-Befehls übertragen werden und insbesondere direkt in ein Marshalling einbezogen werden.
  7. Verfahren nach zumindest einem der vorstehenden Patentansprüche 1 bis 5, dadurch gekennzeichnet, dass die Secure-Messaging Datensätze getrennt von den Parametern für den RPC-Befehl (RPC-B) übertragen werden, insbesondere in einem Abspann nach dem RPC-Befehl (RPC-B).
  8. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass die Secure-Messaging-Datensätze von der rufenden Instanz (Ri) bereitgestellt werden.
  9. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass nach der Überprüfung der Secure-Messaging-Datensätze, insbesondere nach einer Authentisierung, eine Autorisierung für eine Ausführung von weiteren Befehlen erfolgt.
  10. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass zumindest eine der beiden Instanzen (Ri, Gi) auf dem mobilen Datenträger (C) abläuft.
  11. Verfahren nach zumindest einem der vorstehenden Patentansprüche, dadurch gekennzeichnet, dass der mobile Datenträger (C) mit einem Multi-Applikations-System betrieben wird und dass beide Instanzen (Ri, Gi) auf demselben mobilen Datenträger (C) ablaufen, aber unterschiedlichen Applikationen zugeordnet sind.
  12. Mobiler Datenträger (C), der ein Ausführen von RPC-Befehlen (RPC-B) zwischen zumindest zwei Instanzen (Ri, Gi) unterstützt und der zur sicheren Datenübertragung zwischen den Instanzen (Ri, Gi) ausgelegt ist, mit zumindest einem Secure-Messaging-Modul, das Mittel umfasst, die zur Ausführung eines Verfahrens nach zumindest einem der Patentansprüche 1 bis 11 bestimmt sind.
  13. Vorrichtung zur gesicherten Datenübertragung mit einem mobilen Datenträger (C) gemäß Patentanspruch 12.
  14. System zur gesicherten Datenübertragung zwischen mehreren Instanzen (Ri, Gi), die einem mobilen Datenträger (C) zugeordnet sind, wobei das System ein Ausführen von RPC-Befehlen (RPC-B) unterstützt, mit: – zumindest einer rufenden Instanz (Ri), die zur Ausgabe eines RPC-Befehls (RPC-B), zur Parameterversorgung für den RPC-Befehl und zum Senden des RPC-Befehls (RPC-B) mit den jeweils erforderlichen Parametern an eine gerufenen Instanz (Gi) ausgelegt ist, – zumindest einer gerufenen Instanz (Gi), die auf dem mobilen Datenträger (C) abläuft und zur Ausführung des RPC-Befehls (RPC-B) und zum Senden eines Ergebnisses (RPC-E) des RPC-Befehls an die rufende Instanz (Ri) ausgelegt ist und mit – zumindest einem Secure Messaging Modul, das dazu bestimmt ist, Datensätze für ein Secure Messaging zwischen der rufenden Instanz (Ri) und der gerufenen Instanz (Gi), insbesondere eine Authentisierungsinformation (A), zu erzeugen oder zu erfassen, diese Datensätze mit dem RPC-Befehl (RPC-B), dessen Parametern und/oder einem Ergebnis (RPC-E) des RPC-Befehls (RPC-B) zu kombinieren und diese zu überprüfen.
  15. Computerprogrammprodukt, welches direkt in einen Speicher eines mobilen Datenträgers (C) zum Zwecke einer Unterstützung von RPC-Befehlen (RPC-B) ladbar ist, mit Programmcode-Mitteln, um alle Schritte eines Verfahrens nach zumindest einem der Ansprüche 1 bis 11 auszuführen, wenn das Programm in dem mobilen Datenträger (C) ausgeführt wird.
DE200610023436 2006-05-18 2006-05-18 Authentisierung für entfernte Funktionsaufrufe Withdrawn DE102006023436A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
DE200610023436 DE102006023436A1 (de) 2006-05-18 2006-05-18 Authentisierung für entfernte Funktionsaufrufe
EP07725303A EP2025119A1 (de) 2006-05-18 2007-05-16 Authentisierung für entfernte funktionsaufrufe
PCT/EP2007/004388 WO2007134784A1 (de) 2006-05-18 2007-05-16 Authentisierung für entfernte funktionsaufrufe

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE200610023436 DE102006023436A1 (de) 2006-05-18 2006-05-18 Authentisierung für entfernte Funktionsaufrufe

Publications (1)

Publication Number Publication Date
DE102006023436A1 true DE102006023436A1 (de) 2007-11-22

Family

ID=38458165

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200610023436 Withdrawn DE102006023436A1 (de) 2006-05-18 2006-05-18 Authentisierung für entfernte Funktionsaufrufe

Country Status (3)

Country Link
EP (1) EP2025119A1 (de)
DE (1) DE102006023436A1 (de)
WO (1) WO2007134784A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11729178B2 (en) * 2021-02-05 2023-08-15 Shopify Inc. Systems and methods for generating account permissions based on application programming interface interactions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040123138A1 (en) * 2002-12-18 2004-06-24 Eric Le Saint Uniform security token authentication, authorization and accounting framework
EP1665044A1 (de) * 2003-09-09 2006-06-07 Telecom Italia S.p.A. Verfahren und system für fernkartenzugang, computerprogrammprodukt dafür

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6308317B1 (en) * 1996-10-25 2001-10-23 Schlumberger Technologies, Inc. Using a high level programming language with a microcontroller
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Remote Procedure Call Protocol Specification Version 2.RFC 1057.Sun Microsystems,June 1988,S.1-25; *

Also Published As

Publication number Publication date
WO2007134784A1 (de) 2007-11-29
EP2025119A1 (de) 2009-02-18

Similar Documents

Publication Publication Date Title
EP2417550B1 (de) Verfahren zur durchführung einer applikation mit hilfe eines tragbaren datenträgers
DE60315552T2 (de) IC-Karte und Methode zur Authentisierung in einem elektronischen Ticket-Verteiler-System
EP2454703B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP2415228B1 (de) Verfahren zum lesen von attributen aus einem id-token über eine mobilfunkverbindung
DE102011084728B4 (de) Verfahren zum Starten einer externen Applikation und bidirektionaler Kommunikation zwischen einem Browser und einer externen Applikation ohne Browsererweiterungen
EP2567345B1 (de) Verfahren zum lesen eines rfid-tokens, rfid-karte und elektronisches gerät
DE19947986A1 (de) System und Verfahren zum Herunterladen von Anwendungsteilen auf eine Chipkarte
DE10212619A1 (de) Sichere Benutzerauthentisierung über ein Kommunikationsnetzwerk
EP2454704A1 (de) Verfahren zum lesen von attributen aus einem id-token
DE102007011309B4 (de) Verfahren zur authentisierten Übermittlung eines personalisierten Datensatzes oder Programms an ein Hardware-Sicherheitsmodul, insbesondere einer Frankiermaschine
EP3748521B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP2932446A1 (de) Reputationssystem und verfahren
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
EP1222563A2 (de) System zur ausführung einer transaktion
EP2752785B1 (de) Verfahren zur Personalisierung eines Secure Elements (SE) und Computersystem
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
DE102006023436A1 (de) Authentisierung für entfernte Funktionsaufrufe
EP3271855B1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
EP3367285B1 (de) Terminal, id-token, computerprogramm und entsprechende verfahren zur authentisierung einer zugangsberechtigung
EP2169579A1 (de) Verfahren und Vorrichtung zum Zugriff auf ein maschinenlesbares Dokument
WO2014037136A1 (de) Verfahren zur personalisierung eines secure elements (se) und computersystem
EP2486551B1 (de) Personalisieren eines telekommunikationsmoduls
DE102020104646A1 (de) Browserbasierter Fernzugriff auf Hardware-Sicherheitsmodul
EP3107029A1 (de) Verfahren und vorrichtung zum personalisierten elektronischen signieren eines dokuments und computerprogrammprodukt
EP1460510B1 (de) Verfahren zur sicheren Kommunikation zwischen einer Datenverarbeitungsanlage und einer Sicherheitseinrichtung

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
R005 Application deemed withdrawn due to failure to request examination

Effective date: 20130522