EP2025119A1 - Authentisierung für entfernte funktionsaufrufe - Google Patents

Authentisierung für entfernte funktionsaufrufe

Info

Publication number
EP2025119A1
EP2025119A1 EP07725303A EP07725303A EP2025119A1 EP 2025119 A1 EP2025119 A1 EP 2025119A1 EP 07725303 A EP07725303 A EP 07725303A EP 07725303 A EP07725303 A EP 07725303A EP 2025119 A1 EP2025119 A1 EP 2025119A1
Authority
EP
European Patent Office
Prior art keywords
rpc
command
secure
secure messaging
data
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.)
Ceased
Application number
EP07725303A
Other languages
English (en)
French (fr)
Inventor
Stephan Spitz
Gisela 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+Devrient GmbH
Original Assignee
Giesecke+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+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of EP2025119A1 publication Critical patent/EP2025119A1/de
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/357—Cards having a plurality of specified features
    • G06Q20/3574—Multiple applications on card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1016—Devices or methods for securing the PIN and other transaction-data, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Definitions

  • the invention relates to a method for the secure exchange of data between at least two instances, inter alia, exchanging their data via so-called remote function calls or remote procedure calls (hereinafter referred to as RPC commands for short), wherein in the exchange of RPC commands an additional safety mechanism is provided.
  • a chip card can serve as a data storage as well as authorization for certain information and / or for the execution of certain commands in addition to the function.
  • An important aspect of data transfer therefore, is to ensure the integrity and authenticity of messages to be transmitted and, where appropriate, the confidentiality and binding nature of the messages.
  • the purpose of verifying authenticity is, on the one hand, to ensure an unambiguous association between sender and recipient of the message and, on the other hand, to prove that a message received from the recipient has not been changed during its transmission.
  • the verification of authenticity plays an essential role in the context of an authentication.
  • the purpose of an authentication is to verify the identity and authenticity of a communication partner during data transmission.
  • a variety of methods and mechanisms have been developed in this context to increase the overall security of data transmission in connection with smart cards. These mechanisms and procedures fall under the generic term "Secure Messaging".
  • Secure Messaging When applying secure messaging methods to chip card technology, it must be taken into consideration that the computing power of at least one of the two communication partners and / or the transmission speed between the two communication partners may be subject to restrictions.
  • a secure messaging technique has been standardized in ISO / IEC 7816-4 and advanced features have been standardized in ISO / IEC standard 7816-8.
  • remote procedure calls also referred to as RPC for short.
  • RPC remote procedure calls
  • the present invention has therefore set itself the task of providing a way to remote function calls (Remote Procedure Calls), which are executed directly on the mobile disk - especially on the smart card - to combine with an additional security mechanism, while the resources the instances involved are claimed to the least extent possible.
  • remote function calls Remote Procedure Calls
  • the flexibility and performance of using RPC commands on a mobile data carrier should be increased without sacrificing security.
  • the above-mentioned limitations and disadvantages of the prior art are to be overcome.
  • This object is achieved according to the invention by a method for authentication between at least two instances which are assigned to a mobile data carrier, in particular a chip card, wherein an execution of RPC commands in connection with the mobile data carrier is supported by a calling entity authorizing the RPC request. Sends a command to a called instance for execution, and wherein the method is based on security mechanisms, in particular secure messaging, which ensure at least the authenticity and, if necessary, the confidentiality of the data to be transferred or parts thereof, with the following method steps:
  • the secure data transfer is a
  • Data transmission that takes into account security mechanisms.
  • the mechanisms and procedures applicable in this context may also be referred to as secure messaging. This includes procedures that determine the authenticity of a communication partner, the identity of a Communication partners, the confidentiality of the data to be transmitted and / or the liability of the data to be transmitted and / or the confidentiality of the data to be transmitted.
  • the term "liability" of the data transmitted in this context should be understood as the possibility of the sender to check whether a particular recipient has received a message. A denial of the receipt of a message is no longer possible with a binding data transmission.
  • a secure channel is set up for secure messaging, via which the data to be transmitted is exchanged.
  • An important advantage of the solution according to the invention is the fact that it is sufficient to provide a secure channel for data transmission, via which an access of possibly different instances then takes place in a secure manner. It is therefore not necessary that a separate, separate secure channel must be set up for each instance (accessing remote or "foreign" data records), which can significantly save the resources of the entire system.
  • “Secure messaging records” in the context of this invention are records that are relevant in the context of a security mechanism for data transmission. According to the invention, however, different security mechanisms can be used, so that the content of the secure messaging data records can be designed differently in content.
  • the secure messaging record usually includes one Authentication information.
  • the secure messaging record additionally comprises confidentiality information. This feature is optional. Purpose of the authentication is the verification of the authenticity and / or the identity of the respective partner instance. The authentication information thus serves in particular to determine whether the card or the terminal is actually a real card or a true terminal. The authentication information or the authentication record thus clearly refers to an instance or a person.
  • identity is encompassed by the term "authentication”.
  • a mobile data carrier may be a smart card, a smartcard or other card with a microprocessor, or it may also be a complex electronic component or device, such as e.g. a security token or other mobile bearer of digital data, each equipped with appropriate interfaces for data communication.
  • an "instance” is to be understood as meaning all units or modules which are involved in a data transmission.
  • a calling entity that requests data from another entity and is destined to receive that data.
  • There is also a called instance that receives a particular command and is destined to execute that command. After executing the command on the called instance, the result of the command is returned to the calling entity.
  • the calling entity is for issuing an RPC command and the called entity is for executing the RPC command and outputting a result.
  • An instance can be functions, procedures or more complex program parts or programs, but also separate electronic devices or components.
  • An instance can run directly or directly on the mobile disk. Moreover, it is possible that an instance does not run directly on the mobile volume, but is assigned to it only indirectly, by running on an external unit that is in communication with the mobile volume. there can it be z. For example, a chip card terminal or another back office act.
  • RPC commands are used as the communication mechanism.
  • only RPC commands are used for the entire data exchange.
  • other communication structures may be provided in other embodiments.
  • the RPC client and / or the RPC server can thus be provided on the same or another mobile data carrier or in a (smart card) terminal.
  • RPC commands are executed directly on the chip card.
  • certain Web services should be mentioned, which allow access to various services via Internet-based protocols.
  • it is necessary to provide additional safety Mechar ⁇ smen even if previously a secure channel has been established.
  • Messaging data in particular the authentication information, in relation to the participating entities.
  • the authentication information is provided and / or generated.
  • the authentication information is specified by the calling entity.
  • the authentication information is not provided by the calling entity, but is automatically generated by a middleware.
  • a “middleware” is to be understood as a technology which is application-independent and offers different services for switching between separate applications. It is, so to speak, one of the Actual application decoupled platform to mediate function calls between individual instances and organizes the transport of complex data. It is thus possible to handle remote procedure calls via middleware.
  • the authentication information is transmitted in combination with the transmission of the parameters for the remote function call, ie the RPC command.
  • different options are provided for this.
  • the authentication information is preferably linked to the transmission of the parameters of a function call to the chip card.
  • the authentication information may be particularly involved in marshaling (where "marshaling" means receiving and converting a set of structured data elements into a format required to send the data elements in a message to a recipient).
  • the authentication information is tied to the smart card's response to the RPC command.
  • the "result" of the RPC command is here to be understood to mean all return values to the RPC command which, if appropriate, are sent back next to the actual response.
  • the authentication information can also be done after the transmission of the actual RPC command, in particular in a credits after the RPC sequence.
  • the method comprises a check of the authentication information.
  • different variants are also provided according to the invention.
  • the check is made directly on the smart card or on the security device to which the RPC command has been addressed.
  • it may also be provided to have the verification of the authentication carried out in other instances or on an external module.
  • Protocol can then be set the format for the authentication record dynamically.
  • At least one of the two communication instances runs on the mobile data carrier, in particular on the chip card. Usually, this is the called instance used to execute the RPC command. If it is a multi-application system, the other instance, ie the calling entity, can be assigned to another application on the same chip card. For an operating system that supports only a single application at a time, the calling instance may be associated with an external environment.
  • the external environment may be any other instance that is in communication with the smart card.
  • web services are to be mentioned here, which are based on data transmission over the Internet. This feature mainly affects networkable internet smart cards.
  • Another task solution consists in a mobile data carrier, in particular in a chip card, in a security token or in a chip card module according to claim 12, in a more complex device, which is equipped with such a mobile data carrier, according to patent claim 13.
  • the device it can be any electronic device, preferably a portable device such as a cell phone or a PDA equipped with a mobile data carrier.
  • Other task solutions can be seen in a system according to claim 14 and in a computer program product according to claim 15.
  • An alternative task solution provides an interface with respect to a mobile data carrier which is controlled and / or operated according to the method described above.
  • FIG. 1 is a schematic representation of transmitted remote procedure calls according to a preferred embodiment of the invention
  • Fig. 2 is a schematic representation of a protocol stack, which is used in a preferred embodiment of the invention and used
  • FIG. 3 shows an overview of modules according to a preferred embodiment of the invention.
  • the invention relates to a method for secure data transmission between multiple instances Ri, Gi, wherein at least one called instance Gi runs on a mobile data carrier, in particular on a chip card C.
  • the data transmission may include execution of remote function calls, namely remote procedure calls RPC-B, RPC-E.
  • FIG. 3 the data transmission according to the invention is shown schematically.
  • An RPC command structure is based on a client-server approach and is usually handled synchronously. This means that a calling party Ri sets an RPC command RPC-B and waits until it receives the corresponding result RPC-E from the called instance Gi on the RPC command RPC-B. While the calling entity Ri is waiting, the called entity Gi processes the RPC command.
  • the authentication information A is combined with parameters that are transmitted in connection with the function call RPC-B.
  • the response from the chip card C ie the result RPC-E of the RPC command RPC-B, be provided with an authentication information A.
  • the authentication information A is checked.
  • the check can either be on the smart card C or on another unit to which the RPC command RPC-B has been addressed.
  • the data exchange between the participating entities Ri and Gi is handled via a so-called middleware, which implements the corresponding commands.
  • the RPC data including the necessary parameters and the authentication information A may also be transmitted separately. If a protocol according to the ISO / IEC 7816-4 standard is used as the transmission protocol, then the
  • APDU Application Protocol Data Unit
  • the RPC data with the authentication information A can be transmitted in several different APDU sequences.
  • the authentication information A is a plurality of data units to be transmitted
  • FIG. 1 shows the case that there are two calling entities Ri and R 2 which transmit corresponding RPC commands RPC-B to the chip card C. After execution of the RPC command on the chip card C can be transmitted from this, the answer or a result RPC-E back to the calling entity Ri.
  • the authentication information A is transmitted with the RPC request RPC-B and / or with the RPC response RPC-E.
  • a particular advantage of the solution according to the invention is therefore too see that the transmission according to the invention can be dynamically configured.
  • appropriate settings can be made via configuration parameters that z. B. specify which RPC protocol is used, in which format the authentication record A should be present, whether the authentication information A all or only part of the parameters to be transmitted, whether the authentication information A with the RPC command RPC-B and / or to be transmitted with the RPC result RPC-E and / or on which instance Ri, Gi a check of the authentication is to take place.
  • inventive method can be dynamically adapted to the particular application. According to the invention, therefore, flexible authentications of different entities Ri, Gi can be connected, independently of the secure channel over which the function calls RPC-B, RPC-E are handled.
  • a network layer can be arranged as an optional feature, for.
  • a TCP / IP layer Over the network layer can also be formed as an optional element, a backup layer. This can be based on SSL or SECM protocols or other protocols.
  • the uppermost layer is the application layer, which according to the invention is designed on a modified application protocol for the transmission of RPC commands RPC-B, RPC-E with authentication data A.
  • the invention relates to an additional functionality for forming a corresponding interface for communication with a mobile data carrier C and different instances Ri, Gi.
  • the modification relates to the combined transmission of RPC commands RPC-B, RPC-E and authentication information A.
  • the interface according to the invention is controlled and / or operated by the method described above.
  • the interface Due to the flexible configurability of the interface according to the invention, it can be optimally designed for the respective application. In particular, it is adjustable which security mechanisms are to be used, for. As a backup against tampering with the Authentic-Verf ears and / or against interception by appropriate Encryption mechanisms, in particular by means of the combined method.
  • RMI remote method invocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mobile Radio Communication Systems (AREA)

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

Authentisierung f ür entf ernte Funktionsauf ruf e
Die Erfindung liegt auf dem Gebiet der Datenübertragung in Bezug auf mo- bile 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-Bef ehl 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 Auf Zä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 Schutzbe- reich 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 umf asst 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 Authentisierungsverf ahren 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-Bef ehls 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 BackOffice 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 RMI s (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-Mecharύsmen 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äß umf asst das Verfahren eine Überprüfung der Authent- isierungsinformation. 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-10234 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 Authentisierungsinforma- tion, 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 authen- tisieren. 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 vor- gesehen, 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 weite- res 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 Pa- tentanspruch 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än- kend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. Es zeigen:
Fig. 1 eine schematische Darstellung von übertragenen Remote Procedure Calls gemäß einer bevorzugten Ausführungsform der Erfindung, Fig. 2 eine schematische Darstellung eines Protokollstacks, der bei einer bevorzugten Ausführungsform der Erfindung zum Einsatz kommt und
Fig. 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 G1 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 MetaInformationen, 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 Fig. 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 Instan-
Ü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 Fig. 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 Authentisierungs- information 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 Fig. 1 gezeigt, ist es möglich, dass mehrere unterschiedliche rufende Instanzen Ri vorgesehen sind. In Fig. 1 ist der Fall dargestellt, dass es zwei rufende Instanzen Ri 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 Fig. 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 Ai für die erste RPC-Struktur RPC-Bi/ RPC-Ei der ersten Instanz Ri 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 Fig. 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=O (asynchron,
Halbduplex, byte-orientiert), T=I (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 Konf igurierbarkeit 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-Verf ahren 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

P a t e n t a n s p r ü c h e
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 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
Ü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, da- durch 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 Aus- fü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 Authentisie- rungsinformation (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.
EP07725303A 2006-05-18 2007-05-16 Authentisierung für entfernte funktionsaufrufe Ceased EP2025119A1 (de)

Applications Claiming Priority (2)

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

Publications (1)

Publication Number Publication Date
EP2025119A1 true EP2025119A1 (de) 2009-02-18

Family

ID=38458165

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07725303A Ceased EP2025119A1 (de) 2006-05-18 2007-05-16 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

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE69714752C5 (de) * 1996-10-25 2015-08-13 Gemalto Sa Verwendung einer hohen programmiersprache in einem mikrokontroller
US6547150B1 (en) * 1999-05-11 2003-04-15 Microsoft Corporation Smart card application development system and method
US20040123138A1 (en) * 2002-12-18 2004-06-24 Eric Le Saint Uniform security token authentication, authorization and accounting framework
US20080245860A1 (en) * 2003-09-09 2008-10-09 Marco Polano Method and System for Remote Card Access, Computer Program Product Therefor

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007134784A1 *

Also Published As

Publication number Publication date
WO2007134784A1 (de) 2007-11-29
DE102006023436A1 (de) 2007-11-22

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
DE69534181T2 (de) System mit Endgerät und Karte, Karte und Endgerät
EP2415228B1 (de) Verfahren zum lesen von attributen aus einem id-token über eine mobilfunkverbindung
EP2567345B1 (de) Verfahren zum lesen eines rfid-tokens, rfid-karte und elektronisches gerät
WO2011006791A1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3748521B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP3271855B1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
DE102008042582A1 (de) Telekommunikationsverfahren, Computerprogrammprodukt und Computersystem
EP2932446A1 (de) Reputationssystem und verfahren
EP1222563A2 (de) System zur ausführung einer transaktion
WO2007134784A1 (de) Authentisierung für entfernte funktionsaufrufe
EP2752785B1 (de) Verfahren zur Personalisierung eines Secure Elements (SE) und Computersystem
EP3244331B1 (de) Verfahren zum lesen von attributen aus einem id-token
EP2923264B1 (de) Verfahren und system zur applikationsinstallation in einem sicherheitselement
EP2169579A1 (de) Verfahren und Vorrichtung zum Zugriff auf ein maschinenlesbares Dokument
EP3367285B1 (de) Terminal, id-token, computerprogramm und entsprechende verfahren zur authentisierung einer zugangsberechtigung
EP3107029A1 (de) Verfahren und vorrichtung zum personalisierten elektronischen signieren eines dokuments und computerprogrammprodukt
EP2740070B1 (de) Mechanismus zur kommunikation zwischen zwei applikationen auf einem sicherheitsmodul
WO2014037136A1 (de) Verfahren zur personalisierung eines secure elements (se) und computersystem
DE10136384C2 (de) Vorrichtung zum rechnergesteuerten Erzeugen einer Vielzahl von Datensätzen
DE102004058020A1 (de) Verfahren zur Personalisierung von Chipkarten
DE102016123019A1 (de) Verfahren zum elektronischen Initiieren einer Aktion und elektronisches System zum elektronischen Initiieren einer Aktion
DE102020104646A1 (de) Browserbasierter Fernzugriff auf Hardware-Sicherheitsmodul
DE10219731A1 (de) Verfahren zur Ausführung einer Datentransaktion mittels einer aus einer Haupt- und einer trennbaren Hilfskomponente bestehenden Transaktionsvorrichtung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081218

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC MT NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090709

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

DAX Request for extension of the european patent (deleted)
APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20140128