EP2499597A1 - Verfahren zur sicheren interaktion mit einem sicherheitselement - Google Patents

Verfahren zur sicheren interaktion mit einem sicherheitselement

Info

Publication number
EP2499597A1
EP2499597A1 EP10774138A EP10774138A EP2499597A1 EP 2499597 A1 EP2499597 A1 EP 2499597A1 EP 10774138 A EP10774138 A EP 10774138A EP 10774138 A EP10774138 A EP 10774138A EP 2499597 A1 EP2499597 A1 EP 2499597A1
Authority
EP
European Patent Office
Prior art keywords
terminal
pin
authentication data
security module
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.)
Withdrawn
Application number
EP10774138A
Other languages
English (en)
French (fr)
Inventor
Stephan Spitz
Lutz Hammerschmid
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.)
Trustonic Ltd
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
Publication of EP2499597A1 publication Critical patent/EP2499597A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45Structures or tools for the administration of authentication
    • G06F21/46Structures or tools for the administration of authentication by designing passwords or checking the strength of passwords
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/34User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • G06F21/41User authentication where a single sign-on provides access to a plurality of computers
    • 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
    • H04L9/3226Cryptographic 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 using a predetermined code, e.g. password, passphrase or PIN
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06Authentication
    • 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/56Financial cryptography, e.g. electronic payment or e-cash
    • 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

Definitions

  • the present invention relates to a method for secure interaction with a security module integrated in a terminal, in particular the secure input of authentication data into the security module via an input device of the terminal.
  • Various applications for example for paying for goods or services, can be provided to a user on a security module, for example in the form of a (U) SIM mobile calling card, a secure memory card or the like.
  • a security module for example in the form of a (U) SIM mobile calling card, a secure memory card or the like.
  • Such an application itself as well as the data processed by the application are protected on the security module against unauthorized access.
  • the user Before the application is released, for example, to effect a payment transaction, it is necessary for the user to authenticate himself to the security module, for example by means of a PIN. This can prevent that third parties, for example by means of malicious code, abusing the application for their own purposes on the terminal without the knowledge and consent of the user.
  • the input of such authentication data is usually via an input device of the terminal, such as a keyboard, the security module in the terminal - preferably removable - is integrated.
  • the security module in the terminal - preferably removable - is integrated.
  • An inventive method for secure interaction with a security module, which is integrated into a terminal, via an input device of the terminal comprises the following steps.
  • the input device of the terminal is reserved by a security application, which is executable in a trusted area of the terminal.
  • first authentication data are entered via the reserved input device.
  • the security application then derives second authentication data from the first authentication data by means of secret data stored in the trusted area.
  • the second authentication data are then encrypted by the security application and encrypted to the security module and / or transmitted to a server.
  • the received, encrypted second authentication data are finally decrypted.
  • An inventive terminal, which is set up for integrating a security module comprises an input device and a trusted area with a security application executable therein.
  • the security application is further configured to derive second authentication data from the first authentication data by means of secret data stored in the trustworthy area, to encrypt the second authentication data and encrypted to a to transfer to the terminal integrated security module and / or a server.
  • the fact that the second authentication data are encrypted before they are transmitted from the trusted area of the terminal by the security application to the security module and / or the server - and thus generally have to pass through the untrusted area of the terminal - can also No spying, this time the second authentication data, by malicious code installed in the untrusted area.
  • the second authentication data required for authentication to the security module and / or the server is provided by the security module and / or the security module Server receives encrypted and then decrypted in the security module and / or the server.
  • the advantage of the method according to the invention is that the devices used, in particular the terminal and the security module and / or server, as well as the communication between the terminal and the security module and / or server can be maintained substantially unchanged. Only the security application which is executed in the trusted area of the terminal is adapted according to the invention. This means that an authorized user of a corresponding card is not informed of the PIN with which the card is personalized. Alternatively, the authorized user could be asked before the first use itself to enter a PIN, which is written for example by means of a PIN change command on the card.
  • the trusted area of the terminal is provided by a known hardware architecture, for example according to the ARM technology, so-called APvM trust zone, as well as a security runtime environment executed therein, which is supplemented by the security application.
  • Alternative and known hardware architectures are, for example, virtualization technologies or trusted computing with TPM.
  • An encrypted communication between the security application in the trusted area of the terminal and the security module and / or server can be implemented by known techniques. In this way, the inventive method can be easily integrated into existing systems.
  • the security application preferably reserves the issuing device of the terminal in that the security application controls a driver application which is executable in the trustworthy area of the terminal and which is provided to handle the data communication with the input device such that all data entered via the input device is exclusive get into the trusted area of the disk.
  • the secret data stored in the trusted area are preferably formed terminal-specific.
  • the secret data can during a personalization phase of the terminal - matched to the security module to be integrated into the terminal and its users - be introduced into the terminal. In this way it can be prevented that a third party, if it comes into the possession of the security module and attains knowledge of the first authentication data, can authenticate to the security module by means of a further terminal. That is, only a system of terminal, security module and matching secret data in the trusted area of the terminal allow - with knowledge of the first authentication data - a successful authentication against the security module.
  • the second authentication data can be derived from the first authentication data in that the security application encrypts the first authentication data by means of the secret data as a secret key to the second authentication data, for example by means of a cryptographic hash function or the like.
  • a transport key for encrypting the second authentication data for encrypted transmission thereof to the security module and / or the server can be negotiated between the security application and the security module and / or the server in a known manner, for example according to the Diffie-Hellman patent.
  • one or more corresponding transport keys are already stored in the security module and / or the server and the trusted area of the terminal.
  • the second authentication data are used according to a preferred embodiment of the inventive method for releasing an executable on the security module and / or the server application, such as a payment application or the like.
  • the terminal used is preferably a mobile terminal, in particular a mobile station, a PDA, a smartphone, a netbook or the like.
  • Particularly suitable as a security module are (U) SIM mobile communication cards, secure memory cards or similar portable data carriers, which can preferably be removably integrated into a corresponding terminal.
  • Particularly suitable as servers are secured computers, which are used, for example, by banks for financial transactions, for example for paying bills, such as so-called online banking, for example.
  • FIG. 1A schematically shows a preferred embodiment of a terminal according to the invention
  • FIG. 1B shows portions of the terminal device from FIG. 1A which are relevant to the invention in a likewise schematic representation
  • Fig. 1A shows a terminal 100 in the form of a mobile station.
  • Other, in particular mobile terminals are likewise possible, for example PDAs, smartphones, netbooks or the like.
  • the terminal 100 comprises an output device 110 in the form of a display and an input device 180 in the form of a keyboard. Only As interpreted, the terminal 100 includes a chipset 120 by means of which the terminal 100 is controlled and which will be described in greater detail with reference to FIG. 1B.
  • the terminal 100 is set up to record a security module 200, in the example shown, a (U) S mobile phone card, in a removable manner. Security modules of another type and design are also possible, for example, a secure memory card.
  • the security module 200 may provide a user of the terminal 100 with various applications, such as a payment application 210 (see Fig. 1B). In order to prevent unauthorized third parties from abusing such an application for their own purposes, for example by means of being installed on the terminal 100
  • the hardware 120 on which the control unit of the terminal 100 is based provides a trusted area 130 as well as an untrusted area 160. In this way, security-relevant applications and data can already be separated at the hardware level from less security-relevant data and applications.
  • a hardware architecture from ARM, for example, provides this under the name "Trust Zone.”
  • a secure runtime environment 140 controls the processes in the trusted area 130.
  • a driver application 142 which records all entries on the input device 180 of the terminal This ensures that, if necessary, data entered via the issuing device 180 can not enter the untrusted area 160 of the terminal 100. However, the driver application 142 can also be set such that Applications executing in the untrusted area 160 of the terminal 100 have access to the input user interface. direction 180.
  • a security application 150 that complements the secure runtime environment and that has direct access and control over the driver application 142 will be described in greater detail below with reference to FIG. 2, as well as a secret date 144 stored in the trusted area 130 in the form of a secret key (see Fig. 2).
  • a common operating system (OS) 170 controls the untrusted area 160 of the terminal 100.
  • Various non-security applications 172 may be executable therein.
  • the security module 200 is connected to the terminal 100. That while the security module 200 ensures sufficient security for data executable thereon applications 210 and data processed by these applications 210, an interaction with the security module 200, which is usually performed via the input device 180 of the terminal 100, must be secured by further measures. This is necessary because transmitted data must always pass the untrusted area 160 of the terminal 100 and therefore may be exposed to attacks caused by malicious code that has been installed in the untrusted area 160 - mostly unnoticed by the user.
  • a method is described below, which makes it possible to securely transfer authentication data to the security module 200 via the input device 180 of the terminal 100, in order, for example, to execute a payment application 210 that can be executed on the security module 200. release.
  • the user of the terminal 100 initiates the calling of the payment application 210 on the security module 200, for example by means of an application 172 executed in the untrusted area 160 of the terminal 100.
  • Such a call causes the security application 150, which is executed in the trusted area 130 of the terminal 100, to reserve the issuer 180 in step S2.
  • the security application 150 controls the driver application 142 in such a way that, while the issuing device 180 is reserved, all data entered via the input device only reach the trusted area 130 of the terminal 100.
  • a reservation of the issuing device has the consequence that - apart from the data entered via the input device 180 - no further data, in particular no data from the untrusted area 160, can reach the trusted area 130. In this way, it can be prevented, for example, that in the non-trusted area 160 any malicious code present simulates an input device.
  • the security application 150 when the issuing device 180 is reserved, sends an input request in step S3, which can be displayed to the user on the display 110, for example (see FIG. 1A).
  • step S4 the first authentication data PIN 1 is entered by the user of the terminal 100 via the reserved issuing device 180, which is completely controlled by the security application 150 by means of the driver application 142.
  • the entered first authentication data PIN 1 thus reach the trusted area 130 of the terminal 100 in a secured manner.
  • second authentication data PIN 2 are derived from the first authentication data PIN 1 by means of secret data 144 stored in the trusted area 130 in the form of a secret key. This can be done, for example, by the second authentication data PIN 2 being formed by means of a cryptographic hash function from the first authentication data PIN 1 and the secret key keys.
  • the secret key keys is terminal specific, adapted to the corresponding application 210 on the security module 200, which with the means of the key keys derived authentication data PIN 2 is to be released.
  • the PIN 2 is, for example, a PIN in the so-called EMC PIN format
  • the number 2 at the beginning determines the format.
  • the number 4 specifies the PIN length.
  • the PEST itself which is represented by xxxx, is converted to 8 bytes with ff. This means that after the PEM 1 has been encrypted, the resulting PEST 2 must be converted into an EMC PESI.
  • the security application 150 alone is authorized to access the secret date 144, that is to say the secret key keys.
  • the second authentication data PEST 2 derived in this way enables successful authentication at the security module 200, but not the first authentication data PEM 1. If an attacker succeeds in spying on the first authentication data PEST 1 in some way, he can do so for the reasons described, since it is not possible for him to derive the second authentication data PJN 2. This is only by means of the secret key keys possible, but which is - inaccessible to the attacker - stored in the trusted area 130 of the terminal 100.
  • the second authentication data PIN 2 is transmitted by the security application 150 encrypted again in step S6.
  • This is done by a transport key keyr.
  • This can be negotiated in a known manner between the security application 150 and the security module 200.
  • the transport key keyT has already been stored in the trusted area 130 of the terminal 100 and in the security module 200, for example within the framework of corresponding personalization phases.
  • the use of an asymmetric encryption system for encrypting the second authentication data PIN 2 is possible, with encryption and decryption in a known manner by means of various keys - a public or a secret key - done.
  • the encrypted second authentication data PENJ 3 obtained in this way are now transmitted in a secure-since encrypted-manner to the security module 200 in step S7.
  • the encrypted second authentication data ⁇ 3 received in the security module 200 are decrypted there in step S8-again by means of the transport key keyT.
  • the data PEST 2 'thus obtained are compared in the security module 200 with the expected authentication data PIN 2 in step S9. If the comparison is positive, then the user is authenticated as positive and the payment application 210 is released in step Sil. However, if the comparison shows that the decrypted data PIN does not match the expected second authentication data PIN 2, the attempt to release the payment application 210 is aborted by the security module 200 in step S10.
  • Abortion may mean that, for example, in the case of a credit card, the card responds to a VERIFY command with an error code and an erroneous operation counter is decremented.
  • the inventive method is not only able to authenticate a payment function, but it is also possible to authenticate a user in a corresponding application of the method to change PIN1 and ⁇ 2.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)
  • Telephone Function (AREA)

Abstract

In einem Verfahren zur gesicherten Interaktion mit einem Sicherheitsmodul (200), welches in ein Endgerät (100) integriert ist, über eine Eingabeeinrichtung (180) des Endgeräts (100) wird die Eingabeeinrichtung (180) durch eine Sicherheitsapplikation (180), welche in einem vertrauenswürdigen Bereich (130) des Endgeräts (100) ausführbar ist, reserviert. Anschließend werden erste Authentisierungsdaten (PIN 1) über die reservierte Eingabeeinrichtung (180) eingegeben. Die Sicherheitsapplikation (150) leitet aus den ersten Authentisierungsdaten (PIN 1) mittels in dem vertrauenswürdigen Bereich (130) gespeicherter Geheimdaten (144) zweite Authentisierungsdaten (PIN 2) ab. Diese (PIN 2) werden anschließend durch die Sicherheitsapplikation (150) verschlüsselt und an das Sicherheitsmodul (200) und/oder an einen Server übertragen. In dem Sicherheitsmodul (200) und/oder dem Server werden die empfangenen, verschlüsselten zweiten Authentisierungsdaten (PIN 3) schließlich entschlüsselt.

Description

Verfahren zur sicheren Interaktion
mit einem Sicherheitseleme nt
Die vorliegende Erfindung betrifft ein Verfahren zur gesicherten Interaktion mit einem in einem Endgerät integrierten Sicherheitsmodul, insbesondere die sichere Eingabe von Authentisierungsdaten in das Sicherheitsmodul über eine Eingabeeinrichtung des Endgeräts.
Verschiedenste Applikationen, beispielsweise zum Bezahlen von Waren oder Dienstleistungen, können einem Nutzer auf einem Sicherheitsmodul, beispielsweise in Form einer (U)SIM-Mobüfunkkarte, einer sicheren Speicherkarte oder dergleichen, bereitgestellt werden. Eine solche Applikation selbst sowie die von der Applikation verarbeiteten Daten sind auf dem Sicherheitsmodul gegen unautorisierten Zugriff geschützt. Bevor die Applikation freigegeben wird, um beispielsweise eine Bezahltransaktion zu bewirken, ist es notwendig, dass sich der Nutzer gegenüber dem Sicherheitsmodul au- thentisiert, beispielsweise mittels einer PIN. Damit kann verhindert werden, dass Dritte, beispielsweise mittels Schadcode, auf dem Endgerät ohne Wissen und Einwilligung des Nutzers die Applikation für ihre Zwecke missbrauchen.
Die Eingabe solcher Authentisierungsdaten, beispielsweise einer PIN, erfolgt in der Regel über eine Eingabeeinrichtung des Endgeräts, beispielsweise eine Tastatur, wobei das Sicherheitsmodul in das Endgerät - vorzugsweise entfernbar - integriert ist. Bei der Eingabe der PIN und der Übergabe derselben an das Sicherheitsmodul muss sichergestellt werden, dass die PIN nicht durch unberechtigte Dritte ausgespäht werden kann. Dies kann in eingeschränktem Rahmen mittels einer gesicherten Emgabeeinrichtung erfolgen. Es kann dabei aber nicht ausgeschlossen werden, dass eine Schadcodeapplikation die sichere Eingabeeinrichtung für ihre Zwecke missbraucht.
Weiterhin ist es wünschenswert, dass eventuell doch ausgespähte Authentisierungsdaten von unautorisierten Dritten nicht weiter verwendet werden können. Demnach ist es Aufgabe der vorliegenden Erfindung, eine gesicherte Interaktion mit einem Sicherheitsmodul in einem Endgerät über eine Eingabeeinrichtung des Endgeräts zu ermöglichen.
Diese Aufgabe wird durch ein Verfahren, ein Endgerät sowie ein System mit den Merkmalen der unabhängigen Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Ein erfindungsgemäßes Verfahren zur gesicherten Interaktion mit einem Si- cherheitsmodul, welches in ein Endgerät integriert ist, über eine Eingabeeinrichtung des Endgeräts umfasst die folgenden Schritte. Die Eingabeeinrichtung des Endgeräts wird durch eine Sicherheitsapplikation, welche in einem vertrauenswürdigen Bereich des Endgeräts ausführbar ist, reserviert. Anschließend werden erste Authentisierungsdaten über die reservierte Einga- beeinrichtung eingegeben. Die Sicherheitsapplikation leitet dann aus den ersten Authentisierungsdaten mittels in dem vertrauenswürdigen Bereich gespeicherter Geheimdaten zweite Authentisierungsdaten ab. Die zweiten Authentisierungsdaten werden anschließend durch die Sicherheitsapplikation verschlüsselt und im verschlüsselten Zustand an das Sicherheitsmodul und/oder an einen Server übertragen. In dem Sicherheitsmodul und /oder dem Server werden die empfangenen, verschlüsselten zweiten Authentisie- rungsdaten schließlich entschlüsselt. Ein erfindungsgemäßes Endgerät, welches zum Integrieren eines Sicherheitsmoduls eingerichtet ist, umfasst eine Eingabeeinrichtung sowie einen vertrauenswürdigen Bereich mit einer darin ausführbaren Sicherheitsapplikation. Diese ist eingerichtet, die Emgabeeinrichtung zu reservieren und über die reservierte Emgabeeinrichtung erste Authentisierungsdaten zu empfan- gen. Die Sicherheitsapplikation ist weiter eingerichtet, zweite Authentisierungsdaten aus den ersten Authentisierungsdaten mittels in dem vertrauenswürdigen Bereich gespeicherter Geheimdaten abzuleiten, die zweiten Authentisierungsdaten zu verschlüsseln und verschlüsselt an ein in das Endgerät integriertes Sicherheitsmodul und/ oder einen Server zu übertra- gen.
Damit kann sichergestellt werden, dass über die Emgabeeinrichtung eingegebene Authentisierungsdaten ausschließlich von der Sicherheitsapplikation in dem vertrauenswürdigen Bereich des Endgeräts empfangen und verarbei- tet werden. Das Reservieren der Eingabeeinrichtung blockiert sämtliche anderen Anwendungen auf dem Endgerät dahingehend, dass diese die Eingabeeinrichtung, während sie von der Sicherheitsapplikation reserviert ist, nicht nutzen können. Es wird durch die Sicherheitsapplikation ebenso verhindert, dass, während die Emgabeeinrichtung reserviert ist, als vermeintli- che Eingabedaten getarnte Daten, die nicht über die Eingabeeinrichtung eingegeben worden sind, beispielsweise mittels Schadcode in den vertrauenswürdigen Bereich eingeschleust werden können. Die Möglichkeit des Ausspähens von Authentisierungsdaten auf dem Weg von der Eingabeeinrichtung in den vertrauenswürdigen Bereich des Endgeräts - mittels in einen nicht vertrauenswürdigen Bereich des Endgeräts eingeschleusten Schadcodes - wird damit wirkungsvoll verhindert.
Gelingt es einem Angreifer jedoch auf anderem Weg die ersten Authentisie- rungsdaten zu erspähen, beispielsweise indem er einen Nutzer beim Eingeben derselben beobachtet oder indem er die Eingebeeinrichtung auf Hardwareebene manipuliert, so sind die auf diese Weise erhaltenen ersten Authentisierungsdaten für den Angreifer wertlos. Ohne Kenntnis der Geheimdaten, welche in dem vertrauenswürdigen Bereich des Endgeräts sicher ge- speichert sind, ist der Angreifer nicht in der Lage, die zweiten Authentisierungsdaten abzuleiten. Diese aber, und nicht die ersten Authentisierungsdaten, sind zu einer erfolgreichen Authentisierung gegenüber dem Sicherheitsmodul und/ oder dem Server notwendig. Dieses Konzept, wonach erst die zweiten Authentisierungsdaten zur Authentisierung gegenüber dem Si- cherheitsmodul und/ oder dem Server berechtigen, verhindert wirkungsvoll sogenannte Phishing- Angriffe. Selbst wenn der Nutzer versehentlich einer nicht Vertrauenswürdigen Anwendung die ersten Authentisierungsdaten übergibt, können diese von dem Angreifer aus den beschriebenen Gründen nicht verwendet werden.
Dadurch, dass die zweiten Authentisierungsdaten verschlüsselt werden, bevor sie von dem vertrauenswürdigen Bereich des Endgeräts durch die Sicherheitsapplikation an das Sicherheitsmodul und/ oder den Server übertragen werden - und dabei den nicht vertrauenswürdigen Bereich des Endge- räts in der Regel passieren müssen -, kann auch hier kein Ausspähen, diesmal der zweiten Authentisierungsdaten, durch in dem nicht vertrauenswürdigen Bereich installierten Schadcodes erfolgen. Die zur Authentisierung gegenüber dem Sicherheitsmodul und /oder dem Server erforderlichen zweiten Authentisierungsdaten werden vom dem Sicherheitsmodul und/ oder dem Server verschlüsselt empfangen und anschließend in dem Sicherheitsmodul und/ oder dem Server entschlüsselt.
Somit wird eine gesicherte Interaktion mit einem Sicherheitsmodul in einem Endgerät über eine Eingabeeinrichtung des Endgeräts bzw. mit einem Server ermöglicht. Vorteilhaft an dem erfindungsgemäßen Verfahren ist neben seiner hohen Sicherheit, dass die verwendeten Vorrichtungen, insbesondere das Endgerät und das Sicherheitsmodul und /oder Server, sowie die Kommunikation zwischen dem Endgerät und dem Sicherheitsmodul und /oder Server im Wesentlichen unverändert beibehalten werden können. Lediglich die Sicherheitsapplikation, welche in dem vertrauenswürdigen Bereich des Endgeräts ausgeführt wird, wird erfindungsgemäß angepasst. Das bedeutet, daß einem berechtigten Nutzer einer entsprechenden Karte nicht die PIN mitgeteilt wird, mit der die Karte personalisiert ist. Alternativ dazu könnte der berechtigte Nutzer vor der ersten Nutzung aufgefordert werden selbst eine PIN einzugeben, welche beispielsweise mittels einem PIN-Change- Kommando auf die Karte eingeschrieben wird. Der vertrauenswürdige Bereich des Endgeräts wird durch eine bekannte Hardwarearchitektur, beispielsweise gemäß der ARM-Technologie, sogenannte APvM-Trust-Zone, so- wie eine darin ausgeführte Sicherheitslaufzeitumgebung, welche durch die Sicherheitsapplikation ergänzt wird, bereitgestellt. Alternativ bekannte und geeignete Hardwarearchitekturen sind beispielsweise Virtualisierungstech- nologien oder Trusted Computing mit TPM. Eine verschlüsselte Kommunikation zwischen der Sicherheitsapplikation in dem vertrauenswürdigen Be- reich des Endgeräts und dem Sicherheitsmodul und/ oder Server kann mittels bekannter Techniken implementiert werden. Auf diese Weise kann das erfindungsgemäße Verfahren auf einfache Weise in bestehende Systeme integriert werden. Die Sicherheitsapplikation reserviert die Emgabeeinrichtung des Endgeräts vorzugsweise dadurch, dass die Sicherheitsapplikation eine Treiberapplikation, welche in dem vertrauenswürdigen Bereich des Endgeräts ausführbar ist und welche zur Abwicklung der Datenkommunikation mit der Eingabe- einrichtung vorgesehen ist, derart steuert, dass sämtliche über die Eingabeeinrichtung eingegebenen Daten ausschließlich in den vertrauenswürdigen Bereich des Datenträgers gelangen. Dadurch ist sichergestellt, dass eingegebene Daten in Form der ersten Authentisierungsdaten nicht von Schadcode, welcher in dem nicht vertrauenswürdigen Bereich des Endgeräts installiert sein könnte, ausgespäht werden können. Weiterhin verhindert ein Reservieren der Emgabeeinrichtung durch die Sicherheitsapplikation, dass eine andere Applikation sich zur selben Zeit der Emgabeeinrichtung bedient. Auf diese Weise wird ein gesicherter Kommunikationskanal von der Eingabeeinrichtung in den vertrauenswürdigen Bereich des Endgeräts geschaffen. Das Re- servieren der Eingabeeinrichtung durch die Sicherheitsapplikation hat weiterhin zur Folge, dass während die Emgabeeinrichtung reserviert ist, keine Daten aus dem nicht vertrauenswürdigen Bereich in den vertrauenswürdigen Bereich des Endgeräts gelangen - mit Ausnahme der über die Eingabeeinrichtung eingegebenen Daten. Die Sicherheitsapplikation überwacht also, dass sämtliche nicht über die Emgabeeinrichtung eingegebenen Daten verworfen werden, bevor diese in den vertrauenswürdigen Bereich des Endgeräts gelangen. Damit wird verhindert, dass Schadcode vermeintliche Eingabedaten - insbesondere an der Treiberapplikation vorbei - in den vertrauenswürdigen Bereich einschleust.
Die in dem vertrauenswürdigen Bereich gespeicherten Geheimdaten werden vorzugsweise endgerätespezifisch ausgebildet. Die Geheimdaten können dabei während einer Personalisierungsphase des Endgeräts - abgestimmt auf das in das Endgerät zu integrierende Sicherheitsmodul und dessen Nutzer - in das Endgerät eingebracht werden. Auf diese Weise kann verhindert werden, dass sich ein Dritter, falls dieser in den Besitz des Sicherheitsmoduls kommt sowie Kenntnis der ersten Authentisierungsdaten erlangt, mittels eines weiteren Endgeräts bei dem Sicherheitsmodul authentisieren kann. Das heißt, nur ein System aus Endgerät, Sicherheitsmodul sowie darauf abgestimmte Geheimdaten in dem vertrauenswürdigen Bereich des Endgeräts erlauben - bei Kenntnis der ersten Authentisierungsdaten - ein erfolgreiches Authentisieren gegenüber dem Sicherheitsmodul. Die zweiten Authentisierungsdaten können aus den ersten Authentisierungsdaten dadurch abgeleitet werden, dass die Sicherheitsapplikation die ersten Authentisierungsdaten mittels der Geheimdaten als Geheimschlüssel zu den zweiten Authentisierungsdaten verschlüsselt, beispielsweise mittels einer kryptographischen Hashfunktion oder dergleichen.
Ein Transportschlüssel zum Verschlüsseln der zweiten Authentisierungsdaten zum verschlüsselten Übertragen derselben an das Sicherheitsmodul und /oder den Server kann zwischen der Sicherheitsapplikation und dem Sicherheitsmodul und/ oder dem Server in bekannter Weise ausgehandelt werden, beispielsweise gemäß dem Diffie-Hellman-
Schlüsselaustauschverfahren. Es ist aber auch möglich, dass in dem Sicherheitsmodul und/oder dem Server und dem vertrauenswürdigen Bereich des Endgeräts bereits ein oder mehrere entsprechende Transportschlüssel gespeichert sind.
Die zweiten Authentisierungsdaten dienen gemäß einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens zum Freigeben einer auf dem Sicherheitsmodul und /oder dem Server ausführbaren Applikation, beispielsweise einer Bezahlapplikation oder dergleichen. Als Endgerät wird vorzugsweise ein mobiles Endgerät, insbesondere ein Mobilfunkendgerät, ein PDA, ein Smartphone, eine Netbook oder dergleichen, verwendet. Als Sicherheitsmodul eignen sich insbesondere (U)SIM- Mobilfunkkarten, sichere Speicherkarten oder ähnliche portable Datenträger, welche sich vorzugsweise entfernbar in ein entsprechendes Endgerät integrieren lassen. Als Server eignen sich insbesondere abgesicherte Rechner, welche beispielsweise bei Banken für Finanztransaktionen, z.B. zum Zahlen von Rechnungen, wie beispielsweise beim sogenannten Online-Banking, einge- setzt werden.
Die vorliegende Erfindung wird im Folgenden mit Bezug auf die beiliegenden Zeichnungen beispielhaft beschrieben. Darin zeigen: Figur 1A schematisch eine bevorzugte Ausführungsform eines erfindungsgemäßen Endgeräts;
Figur 1B erfindungsrelevante Anteile des Endgeräts aus Fig. 1A in ebenfalls schematisierter Darstellung; und
Figur 2 Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens.
Fig. 1A zeigt ein Endgerät 100 in Form eines Mobüfunkendgeräts. Andere, insbesondere mobile Endgeräte sind gleichfalls möglich, beispielsweise PDAs, Smartphones, Netbooks oder dergleichen.
Das Endgerät 100 umfasst eine Ausgabeeinrichtung 110 in Form eines Displays und eine Eingabeeinrichtung 180 in Form einer Tastatur. Lediglich an- gedeutet dargestellt umfasst das Endgerät 100 einen Chipsatz 120, mittels dessen das Endgerät 100 gesteuert wird und welcher mit Bezug auf Fig. 1B genauer beschrieben wird. Das Endgerät 100 ist eingerichtet, ein Sicherheitsmodul 200, im gezeigten Beispiel eine (U)S- -Mobüfunkkarte, entfern- bar aufzunehmen. Sicherheitsmodule anderer Art und Bauform sind ebenfalls möglich, beispielsweise eine sichere Speicherkarte. Das Sicherheitsmodul 200 kann einem Nutzer des Endgeräts 100 diverse Applikationen bereitstellen, beispielsweise eine Bezahlapplikation 210 (vgl. Fig. 1B). Um unautorisierte Dritte davon abzuhalten, eine solche Applikation für ihre Zwecke zu missbrauchen, beispielsweise mittels auf dem Endgerät 100 installierten
Schadcodes, sind verschiedene Sicherheitsmaßnahmen vorgesehen, die mit Bezug auf die Fig. 1B und 2 nachstehend detailliert beschrieben werden.
Die Hardware 120, auf welcher die Steuereinheit des Endgeräts 100 beruht, stellt einen vertrauenswürdigen Bereich 130 sowie einen nicht vertrauenswürdigen Bereich 160 bereit. Sicherheitsrelevante Applikationen und Daten können auf diese Weise bereits auf der Ebene der Hardware von weniger sicherheitsrelevanten Daten und Applikationen getrennt werden. Eine Hardware- Architektur der Firma ARM stellt Entsprechendes beispielsweise unter dem Namen„Trust Zone" zur Verfügung. Auf Ebene der Software steuert eine sichere Laufzeitumgebung 140 die Abläufe in dem vertrauenswürdigen Bereich 130. Eine Treiberapplikation 142, welche sämtliche Eingaben auf der Eingabeeinrichtung 180 des Endgeräts verarbeitet, ist Teil der sicheren Laufzeitumgebung 140. Damit kann sichergestellt werden, dass, falls erforderlich, über die Emgabeeinrichtung 180 eingegebene Daten nicht in den nicht vertrauenswürdigen Bereich 160 des Endgeräts 100 gelangen können. Die Treiberapplikation 142 kann aber auch derart eingestellt werden, dass auch Applikationen, welche in dem nicht vertrauenswürdigen Bereich 160 des Endgeräts 100 ausgeführt werden, Zugriff auf die Eingabeein- richtung 180 haben. Eine Sicherheitsapplikation 150, welche die sichere Laufzeitumgebung ergänzt und welche direkten Zugriff auf und Kontrolle über die Treiberapplikation 142 besitzt, wird nachfolgend mit Bezug auf Fig. 2 genauer beschrieben, genauso wie ein in dem vertrauenswürdigen Bereich 130 gespeichertes Geheimdatum 144 in Form eines geheimen Schlüssels keys (vgl. Fig. 2).
Wie in Fig. 1B weiter dargestellt, steuert ein gewöhnliches Betriebssystem (OS) 170 den nicht vertrauenswürdigen Bereich 160 des Endgeräts 100. Darin können verschiedene nicht sicherheitsrelevante Applikationen 172 ausführbar sein. Ebenfalls über den nicht vertrauenswürdigen Bereich 160 ist das Sicherheitsmodul 200 mit dem Endgerät 100 verbunden. D.h. während das Sicherheitsmodul 200 für darauf ausführbare Applikationen 210 sowie von diesen Applikationen 210 verarbeitete Daten eine ausreichende Sicherheit gewährleistet, muss eine Interaktion mit dem Sicherheitsmodul 200, welche in der Regel über die Eingabeeinrichtung 180 des Endgeräts 100 durchgeführt wird, mittels weiterer Maßnahmen gesichert werden. Dies ist notwendig, da übertragene Daten stets den nicht vertrauenswürdigen Bereich 160 des Endgeräts 100 passieren müssen und daher möglicherweise Angriffen ausgesetzt sind, die durch Schadcode verursacht werden, der in dem nicht vertrauenswürdigen Bereich 160 - für den Nutzer meist unbemerkt - installiert worden ist.
Mit Bezug auf Fig. 2 wird im Folgenden ein Verfahren dargestellt, welches es ermöglicht, in gesicherter Weise Authentisierungsdaten über die Eingabeeinrichtung 180 des Endgeräts 100 an das Sicherheitsmodul 200 zu übertragen, um damit beispielsweise eine Bezahlapplikation 210, welche auf dem Sicherheitsmodul 200 ausführbar ist, freizugeben. In einem ersten Schritt Sl stößt der Nutzer des Endgeräts 100, beispielsweise mittels einer im nicht vertrauenswürdigen Bereich 160 des Endgeräts 100 ausgeführten Applikation 172, das Aufrufen der Bezahlapplikation 210 auf dem Sicherheitsmodul 200 an.
Ein solches Aufrufen veranlasst die Sicherheitsapplikation 150, welche in dem vertrauenswürdigen Bereich 130 des Endgeräts 100 ausgeführt wird, in Schritt S2 die Emgabeeinrichtung 180 zu reservieren. Dazu steuert die Sicherheitsapplikation 150 die Treiberapplikation 142 in einer Weise, dass, während die Emgabeeinrichtung 180 reserviert ist, sämtliche über die Eingabeeinrichtung eingegebenen Daten ausschließlich in den vertrauenswürdigen Bereich 130 des Endgeräts 100 gelangen. Weiterhin hat ein Reservieren der Emgabeeinrichtung zur Folge, dass - außer den über die Eingabeeinrichtung 180 eingegebenen Daten - keine weiteren Daten, insbesondere keine Daten aus dem nicht vertrauenswürdigen Bereich 160 in den vertrauenswürdigen Bereich 130 gelangen können. Auf diese Weise kann beispielsweise verhindert werden, dass in dem nichtvertrauenswürdigen Bereich 160 eventuell befindlicher Schadcode eine Eingabeeinrichtung vortäuscht. Die Sicherheitsapplikation 150 sendet, wenn die Emgabeeinrichtung 180 reserviert ist, in Schritt S3 eine Eingabeaufforderung, welche beispielsweise auf dem Display 110 dem Nutzer abgezeigt werden kann (vgl. Fig. 1A).
Es folgt in Schritt S4 die Eingabe erster Authentisierungsdaten PIN 1 durch den Nutzer des Endgeräts 100 über die reservierte Emgabeeinrichtung 180, welche mittels der Treiberapplikation 142 vollständig von der Sicherheitsapplikation 150 kontrolliert wird. Die eingegebenen ersten Authentisierungsdaten PIN 1 gelangen auf diese Weise gesichert in den vertrauenswürdigen Bereich 130 des Endgeräts 100. Dort werden durch die Sicherheitsapplikation 150 in Schritt S5 aus den ersten Authentisierungsdaten PIN 1 mittels in dem vertrauenswürdigen Bereich 130 gespeicherter Geheimdaten 144 in Form eines geheimen Schlüssels keys zweite Authentisierungsdaten PIN 2 abgeleitet. Dies kann beispielsweise dadurch erfolgen, dass die zweiten Authentisierungsdaten PIN 2 mittels einer kryptographischen Hashfunktion aus den ersten Authentisierungsdaten PIN 1 und dem geheimen Schlüssel keys gebildet werden. Es ist auch möglich, dass von dem berechneten Hashwert lediglich eine vorgegebene Anzahl von Stellen verwendet wird, beispielsweise abhängig von Vorgaben des Sicherheitsmoduls 200. Der geheime Schlüssel keys wird endgerätespezifisch ausgebildet, angepasst an die entsprechende Applikation 210 auf dem Sicherheitsmodul 200, welche mit den mittels des Schlüssels keys abgeleiteten Authentisierungsdaten PIN 2 freigegeben werden soll. Bei der PIN 2 handelt es sich beispielsweise um eine PIN im sogenannten EMV-PIN-Format
24xxxxffffffffff. Die Ziffer 2 am Beginn legt das Format fest. Die Ziffer 4 legt die PIN-Länge fest. Die PEST selbst, welche mit xxxx dargestellt wird, wird mit ff auf 8 Byte gewandelt. Das bedeutet, daß nachdem die PEM 1 verschlüsselt wurde, muß die entstandene PEST 2 in eine EMV-PESI umgewandelt wer- den. Die Sicherheitsapplikation 150 ist alleine berechtigt, auf das Geheimdatum 144, also den geheimen Schlüssel keys, zuzugreifen.
Allein die auf diese Weise abgeleiteten zweiten Authentisierungsdaten PEST 2 ermöglichen ein erfolgreiches Authentisieren bei dem Sicherheitsmodul 200, nicht jedoch bereits die ersten Authentisierungsdaten PEM 1. Sollte es einem Angreifer also gelingen, die ersten Authentisierungsdaten PEST 1 auf irgendeine Weise zu erspähen, so kann er diese aus den beschriebenen Gründen nicht verwerten, da es ihm nicht möglich ist, die zweiten Authentisierungsdaten PJN 2 abzuleiten. Dies ist lediglich mittels des geheimen Schlüssels keys möglich, der jedoch - für den Angreifer unerreichbar - in dem vertrauenswürdigen Bereich 130 des Endgeräts 100 gespeichert ist.
Um die abgeleiteten zweiten Authentisierungsdaten PIN 2 in gesicherter Weise von dem vertrauenswürdigen Bereich 130 des Endgeräts 100 an das Sicherheitsmodul 200 zu übertragen, wobei die übertragenen Daten den nicht vertrauenswürdigen Bereich 160 des Endgeräts 100 passieren müssen, werden die zweiten Authentisierungsdaten PIN 2 durch die Sicherheitsapplikation 150 in Schritt S6 abermals verschlüsselt. Dazu dient ein Transport- Schlüssel keyr. Dieser kann in bekannter Weise zwischen der Sicherheitsapplikation 150 und dem Sicherheitsmodul 200 ausgehandelt werden. Es ist aber auch möglich, dass der Transportschlüssel keyT bereits in dem vertrauenswürdigen Bereich 130 des Endgeräts 100 und in dem Sicherheitsmodul 200 gespeichert worden ist, beispielsweise im Rahmen entsprechender Per- sonalisierungsphasen. Weiterhin ist die Verwendung eines asymmetrischen Verschlüsselungssystems zur Verschlüsselung der zweiten Authentisierungsdaten PIN 2 möglich, wobei Ver- und Entschlüsselung in bekannter Weise mittels verschiedener Schlüssel - einem öffentlichen bzw. einem geheimen Schlüssel - erfolgen.
Die auf diese Weise erhaltenen verschlüsselten zweiten Authentisierungsdaten PENJ 3 werden nun in gesicherter - da verschlüsselter - Weise in Schritt S7 an das Sicherheitsmodul 200 übertragen. Die in dem Sicherheitsmodul 200 empfangenen verschlüsselten zweiten Authentisierungsdaten ΡΓΝ 3 werden dort in Schritt S8 - wieder mittels des Transportschlüssels keyT - entschlüsselt. Die derart erhaltenen Daten PEST 2' werden in dem Sicherheitsmodul 200 mit den erwarteten Authentisierungsdaten PIN 2 in Schritt S9 verglichen. Fällt der Vergleich positiv aus, so gilt der Nutzer als positiv authentisiert und die Bezahlapplikation 210 wird in Schritt Sil freigegeben. Ergibt der Vergleich allerdings, dass die entschlüsselten Daten PIN nicht mit den erwarteten zweiten Authentisierungsdaten PIN 2 übereinstimmen, wird der Versuch, die Bezahlapplikation 210 frei- zugeben, durch das Sicherheitsmodul 200 in Schritt S10 abgebrochen. Dabei kann Abbruch bedeuten, daß beispielsweise bei einer Kreditkarte, die Karte auf ein VERIFY-Kommando mit einem Fehlercode antwortet und ein Fehlbedienungszähler dekrementiert wird. Das erfindungsgemäße Verfahren ist aber nicht nur in der Lage eine Bezahlfunktion zu authentisieren, sondern es ist auch möglich einen Benutzer in entsprechender Anwendung des Verfahrens zu authentisieren, um PIN1 und ΡΠΝΓ2 zu verändern.

Claims

P a t e n t a n s p r ü c h e 1. Verfahren zur gesicherten Interaktion mit einem in einem Endgerät (100) integrierten Sicherheitsmodul (200) über eine Eingabeeinrichtung (180) des Endgeräts (100), umfassend die Schritte:
Reservieren (S2) der Emgabeeinrichtung (180) durch eine in einem vertrauenswürdigen Bereich (130) des Endgeräts (100) ausführbare Si- cherheitsapplikation (150);
Eingeben (S4) erster Authentisierungsdaten (PIN 1) über die reservierte Emgabeeinrichtung (180);
Ableiten (S5) zweiter Authentisierungsdaten (PIN 2) aus den ersten Authentisierungsdaten (PIN 1) durch die Sicherheitsapplikation (150) mittels in dem vertrauenswürdigen Bereich (130) gespeicherter Geheimdaten (144) ;
Verschlüsseln (S6) der zweiten Authentisierungsdaten (PIN 2) durch die Sicherheitsapplikation (150) und Übertragen (S7) der verschlüsselten zweiten Authentisierungsdaten (PIN 3) an das Sicherheitsmodul (200) und/ oder an einen Server; und
Entschlüsseln (S8) der verschlüsselten zweiten Authentisierungsdaten (PIN 3) in dem Sicherheitsmodul (200) und/oder in dem Server.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Ein- gabeeinrichtung (180) dadurch reserviert wird, dass die Sicherheitsapplikation (150) eine in dem vertrauenswürdigen Bereich (130) ausführbare Treiberapplikation (142) der Eingabeeinrichtung (180) derart steuert, dass sämtliche über die Eingabeeinrichtung (180) eingegebenen Daten ausschließlich in den vertrauenswürdigen Bereich (130) des Endgeräts (100) gelangen.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Sicherheitsapplikation (150) überwacht, dass, während die Eingabeeinrichtung (180) reserviert ist, sämtliche nicht über die Emgabeeinrichtung (180) eingegebenen Daten verworfen werden, bevor diese in den vertrauenswürdigen Bereich (130) des Endgeräts (100) gelangen.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die in dem vertrauenswürdigen Bereich (130) gespeicherten Ge- heimdaten (144) endgerätespezifisch ausgebildet werden.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Sicherheitsapplikation (150) die zweiten Authentisierungsdaten (PIN 2) ableitet, indem sie die ersten Authentisierungsdaten (PIN 1) mittels der Geheimdaten (144) als Geheimschlüssel zu den zweiten Authentisierungsdaten (PIN 2) verschlüsselt.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass ein Transportschlüssel (keyr) zum Verschlüsseln der zweiten Au- thentisierungsdaten (PIN 2) zum Übertragen der verschlüsselten zweiten Authentisierungsdaten (PIN 3) zwischen der Sicherheitsapplikation (150) und dem Sicherheitsmodul (200) und/ oder dem Server ausgehandelt wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeich- net, dass als Endgerät (100) ein mobiles Endgerät, insbesondere ein Mobilfunkendgerät, verwendet wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass als Sicherheitsmodul (200) ein portabler Datenträger, insbesondere eine (U)SIM-Mobüfunkkarte oder eine sichere Speicherkarte, in das Endgerät (100) integriert wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeich- net, dass die zweiten Authentisierungsdaten (PIN 2) zum Freigeben einer auf dem Sicherheitsmodul (200) und/ oder dem Server ausführbaren Applikation (210) dienen.
10. Endgerät (100), eingerichtet zum Integrieren eines Sicherheitsmoduls (200), umfassend eine Eingabeeinrichtung (180) sowie einen vertrauenswürdigen Bereich (130) mit einer darin ausführbaren Sicherheitsapplikation (150), die eingerichtet ist, die Emgabeeinrichtung (180) zu reservieren, über die reservierte Eingabeeinrichtung (180) erste Authentisierungsdaten (PIN 1) zu empfangen, zweite Authentisierungsdaten (PIN 2) aus den ersten Authen- tisierungsdaten (PIN 1) mittels in dem vertrauenswürdigen Bereich (130) gespeicherter Geheimdaten (144) abzuleiten, die zweiten Authentisierungsdaten (PIN 2) zu verschlüsseln und verschlüsselt an ein in das Endgerät (100) integriertes Sicherheitsmodul (200) und/ oder an einen Server zu übertragen.
11. Endgerät (100) nach Anspruch 10, dadurch gekennzeichnet, dass die Sicherheitsapplikation (180) eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 9 auszuführen.
12. System, umfassend ein Endgerät (100) nach Anspruch 10 oder 11 so- wie ein in das Endgerät (100) integrierbares Sicherheitsmodul (200), welches eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 9 auszuführen.
EP10774138A 2009-11-09 2010-10-26 Verfahren zur sicheren interaktion mit einem sicherheitselement Withdrawn EP2499597A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102009052389A DE102009052389A1 (de) 2009-11-09 2009-11-09 Verfahren zur sicheren Interaktion mit einem Sicherheitselement
PCT/EP2010/006536 WO2011054462A1 (de) 2009-11-09 2010-10-26 Verfahren zur sicheren interaktion mit einem sicherheitselement

Publications (1)

Publication Number Publication Date
EP2499597A1 true EP2499597A1 (de) 2012-09-19

Family

ID=43480710

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10774138A Withdrawn EP2499597A1 (de) 2009-11-09 2010-10-26 Verfahren zur sicheren interaktion mit einem sicherheitselement

Country Status (8)

Country Link
US (1) US20120233456A1 (de)
EP (1) EP2499597A1 (de)
CN (1) CN102667800A (de)
AU (1) AU2010314480B2 (de)
BR (1) BR112012010553A2 (de)
CA (1) CA2779654A1 (de)
DE (1) DE102009052389A1 (de)
WO (1) WO2011054462A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2500560A (en) * 2011-11-03 2013-10-02 Proxama Ltd Authorising transactions in a mobile device
FR2997525B1 (fr) * 2012-10-26 2015-12-04 Inside Secure Procede de fourniture d’un service securise
DE102012022875A1 (de) * 2012-11-22 2014-05-22 Giesecke & Devrient Gmbh Verfahren und System zur Applikationsinstallation
CN104765999B (zh) * 2014-01-07 2020-06-30 腾讯科技(深圳)有限公司 一种对用户资源信息进行处理的方法、终端及服务器
EP2908262B1 (de) * 2014-02-18 2016-02-17 Nxp B.V. Sicherheitstoken, Verfahren zur Ausführung einer Transaktion und Computerprogrammprodukt
DE102014007789A1 (de) * 2014-05-23 2015-11-26 Giesecke & Devrient Gmbh Browserbasierte Applikation
EP3016342B1 (de) 2014-10-30 2019-03-06 Nxp B.V. Mobile Vorrichtung, Verfahren zur Erleichterung einer Transaktion, Computerprogramm, hergestellter Gegenstand
US11068895B2 (en) * 2015-02-17 2021-07-20 Visa International Service Association Token and cryptogram using transaction specific information
CN105430150B (zh) * 2015-12-24 2019-12-17 北京奇虎科技有限公司 一种实现安全通话的方法和装置
DE102016207339A1 (de) * 2016-04-29 2017-11-02 Volkswagen Aktiengesellschaft Verfahren zur sicheren Interaktion eines Nutzers mit einem mobilen Endgerät und einer weiteren Instanz

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL103062A (en) * 1992-09-04 1996-08-04 Algorithmic Res Ltd Data processor security system
US6092202A (en) * 1998-05-22 2000-07-18 N*Able Technologies, Inc. Method and system for secure transactions in a computer system
US7380136B2 (en) * 2003-06-25 2008-05-27 Intel Corp. Methods and apparatus for secure collection and display of user interface information in a pre-boot environment
DE102004004552A1 (de) * 2004-01-29 2005-08-18 Giesecke & Devrient Gmbh System mit wenigstens einem Computer und wenigstens einem tragbaren Datenträger
US20110071949A1 (en) * 2004-09-20 2011-03-24 Andrew Petrov Secure pin entry device for mobile phones
US20080014990A1 (en) * 2005-07-25 2008-01-17 Pixtel Media Technology (P) Ltd. Method of locating a mobile communication system for providing anti theft and data protection during successive boot-up procedure
EP1752937A1 (de) * 2005-07-29 2007-02-14 Research In Motion Limited System und Verfahren zur verschlüsselten Eingabe einer persönlichen Identifizierungsnummer für eine Chipkarte
US7694147B2 (en) * 2006-01-03 2010-04-06 International Business Machines Corporation Hashing method and system
EP1862948A1 (de) * 2006-06-01 2007-12-05 Axalto SA IC-Karte mit OTP-Client
US8051297B2 (en) * 2006-11-28 2011-11-01 Diversinet Corp. Method for binding a security element to a mobile device
US20080301816A1 (en) * 2007-06-01 2008-12-04 Ting David M T Method and system for handling keystroke commands
US8140855B2 (en) * 2008-04-11 2012-03-20 Microsoft Corp. Security-enhanced log in
US20100312709A1 (en) * 2009-06-05 2010-12-09 Dynamic Card Solutions International Payment application pin data self-encryption

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
DE102009052389A1 (de) 2011-05-12
CA2779654A1 (en) 2011-05-12
CN102667800A (zh) 2012-09-12
BR112012010553A2 (pt) 2016-03-22
US20120233456A1 (en) 2012-09-13
AU2010314480A1 (en) 2012-06-14
AU2010314480B2 (en) 2014-01-23
WO2011054462A1 (de) 2011-05-12

Similar Documents

Publication Publication Date Title
WO2011054462A1 (de) Verfahren zur sicheren interaktion mit einem sicherheitselement
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
EP2533172B2 (de) Gesicherter Zugriff auf Daten in einem Gerät
EP2749003B1 (de) Verfahren zur authentisierung eines telekommunikationsendgeräts umfassend ein identitätsmodul an einer servereinrichtung eines telekommunikationsnetzes, verwendung eines identitätsmoduls, identitätsmodul und computerprogramm
EP2765752B1 (de) Verfahren zum versehen eines mobilen endgeräts mit einem authentisierungszertifikat
EP2962439B1 (de) Lesen eines attributs aus einem id-token
WO2013185888A1 (de) Mobilstation mit bindung zwischen endgerät und sicherheitselement
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
DE112010004580T5 (de) Sichere Pin-Verwaltung einer für Benutzer vertrauenswürdigen Einheit
EP3095080A1 (de) Verfahren zum autorisieren einer transaktion
EP3206151B1 (de) Verfahren und system zur authentifizierung eines mobilen telekommunikationsendgeräts an einem dienst-computersystem und mobiles telekommunikationsendgerät
EP2434424B1 (de) Verfahren zur Erhöhung der Sicherheit von sicherheitsrelevanten Online-Diensten
EP1915718B1 (de) Verfahren zur absicherung der authentisierung eines tragbaren datenträgers gegen ein lesegerät über einen unsicheren kommunikationsweg
EP3449655A1 (de) Verfahren zur sicheren interaktion eines nutzers mit einem mobilen endgerät und einer weiteren instanz
DE102013102092B4 (de) Verfahren und Vorrichtung zum Authentifizieren von Personen
WO2016116278A1 (de) Verfahren zum betreiben einer computereinheit mit einer sicheren laufzeitumgebung sowie eine solche computereinheit
EP3361436B1 (de) Verfahren zur freigabe einer transaktion
DE102017128807A1 (de) Verfahren und Anordnung zum Auslösen einer elektronischen Zahlung
EP2819077A1 (de) Verfahren zum Freischalten mindestens eines Dienstes im E-Wallet
EP1714203A1 (de) System mit wenigstens einem computer und wenigstens einem tragbaren datenträger
EP3486852A2 (de) Verfahren und anordnung zum auslösen einer elektronischen zahlung
EP1563360A1 (de) Verfahren zum schutz eines tragbaren datentr gers
DE102012024856A1 (de) Verfahren zum Betreiben eines Sicherheitsmoduls sowie ein solches Sicherheitsmodul

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: 20120611

AK Designated contracting states

Kind code of ref document: A1

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

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: TRUSTONIC LIMITED

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

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20161214