EP3304399A1 - Applikationsauthentisierung - Google Patents

Applikationsauthentisierung

Info

Publication number
EP3304399A1
EP3304399A1 EP16725371.5A EP16725371A EP3304399A1 EP 3304399 A1 EP3304399 A1 EP 3304399A1 EP 16725371 A EP16725371 A EP 16725371A EP 3304399 A1 EP3304399 A1 EP 3304399A1
Authority
EP
European Patent Office
Prior art keywords
application
security element
session
terminal
key
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
EP16725371.5A
Other languages
English (en)
French (fr)
Inventor
Daniel Albert
Helmut Schuster
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 Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany 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 Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP3304399A1 publication Critical patent/EP3304399A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/44—Program or device authentication
    • G06F21/445—Program or device authentication by mutual authentication, e.g. between devices or programs
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • 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
    • H04L9/3226—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 using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes

Definitions

  • the present invention relates to a method in a terminal, for example a smartphone. More particularly, the invention relates to a method for authenticating an application executable on the terminal to a security element arranged in the terminal.
  • Authentication of such an application with respect to a security element can be carried out by means of an authentication key.
  • an authentication key is generally generated or derived by means of a secret key assigned to the application.
  • the object of the present invention is therefore to propose a method for authenticating an application on a terminal in relation to a security element arranged in the terminal, which takes into account the above-mentioned disadvantages.
  • This object is achieved by a method and a system having the features of the independent claims. Advantageous embodiments and further developments are specified in the dependent claims.
  • the present invention is based on the idea that a secret key associated with the application that can be used to derive a session-specific authentication value is not used in the application, i.e., in the application. is not stored in an unsecured area of the terminal, but is only available to a trusted external entity. This external entity is set up to generate corresponding authentication values for the application and to make these available to the application.
  • a preferred embodiment of a method according to the invention in a terminal, wherein the terminal comprises an application executable on the terminal and a security element arranged in the terminal comprises a step carried out in the terminal of authenticating the application of the terminal relative to that in the terminal associated security element mit Vietnamese e of a session-specific authentication value, which can be generated by means of a secret key associated with the application.
  • session-specific means that the authentication value can only be used for authenticating the application once to the security element, whereby the application generally authenticates itself to the security element for a subsequent communication session between the application and the security element.
  • the method is characterized by the following steps preceding the step of authenticating in the terminal:
  • the application on the terminal receives a plurality of session-specific authentication values from a trusted external entity, wherein the external entity uses the session-specific authentication values by means of the application associated with the application, secret key has generated.
  • the number of session-specific authentication values received by the application is limited to a small two-digit value, eg 10 to 50.
  • the application then stores the multiple session-specific authentication values for the subsequent authentication of the application with respect to the security element for future communication sessions with the security element.
  • the application of the terminal now uses one of the previously received and stored session-specific authentication values as the authentication value.
  • a further advantage of the method is that the application is provided with a plurality of session-specific authentication values in advance and these are stored in the terminal. As a result, it is not necessary for the terminal or the application to maintain a permanent communication connection with the trusted external entity. Instead, the application can always use one of the stored session-specific authentication values for authentication with respect to the security element if authentication is to take place in relation to the security element. This not only ensures independence of the method with respect to a communication connection to the external entity, but also allows a simpler and faster implementation of the authentication method, since no communication with the external entity in the context of the actual authentication method is more necessary.
  • the application can request further session-specific authentication values from the trusted, external instance.
  • the external instance of the application can provide on the terminal at regular or irregular intervals a predetermined contingent of session-specific authentication values in the manner described.
  • provision may be made for authentication values which are still stored in the terminal and which have been received at an earlier time to become invalid.
  • the transmission of the authentication values from the external entity to the terminal or the application in the terminal preferably takes place via a secure correlation connection. Even if an attacker were to succeed in gaining one or more of the session-specific authentication values despite the secure transmission, the risk of an attack on the security element is limited due to the comparatively small number of authentication values that can be obtained. What is important is that an attacker can not obtain the secret key assigned to the application, because only this one makes it possible to generate further session-specific authentication values.
  • the plurality of session-specific authentication values are generated by the external entity as session-specific authentication keys by means of the secret key available to the external entity and associated with the application.
  • the plurality of session-specific authentication keys are either already present in the security element or can be generated by the security element in the security element.
  • the secret key assigned to the application can also be present in the security element.
  • the secret key is not present in an unsecured environment of the terminal, but only secured in the security element.
  • the security element is then set up to generate the plurality of session-specific authentication keys in turn by means of the secret key assigned to the application.
  • a counter assigned to a specific session between the security element and the application can be encrypted by the external entity or by the security element by means of the secret key assigned to the application.
  • the application and the security element can be used for a subsequent session-specific authentication value by means of the session-specific authentication value used in the step of authenticating
  • Communication session negotiate a communication key.
  • This communication key is preferably also session-specific.
  • the secret key assigned to the application corresponds to a private key of a key pair assigned to the application in an asymmetrical cryptosystem.
  • the external entity When generating the plurality of session-specific authentication values, the external entity then encrypts a session-specific initial value, for example a random number, by means of this private key assigned to the application in order to generate a session-specific authentication value.
  • a session-specific authentication value can then be decrypted or verified in the security element of the terminal by means of a public key assigned to the application, which together with the private key forms the key pair.
  • the above-mentioned initial value for example a random number, can itself be used as a communication key for a subsequent communication session between the applications and the security element. ment be used or at least be used to derive such a communication key.
  • the multiple session-specific authentication values are generated by the trusted, external entity in each case specifically for the security element of the terminal. In this way, it can be ensured that only exactly one authentication of the application with respect to the specific security element, and not with respect to a different security element, can be carried out by means of the corresponding authentication values. In this way, it can be prevented, in particular, that an attacker who succeeds in obtaining such an authentication value can use this to authenticate himself as an application with respect to another security element that is different from the security element of the terminal.
  • the plurality of session-specific authentication values are generated by the external instance specifically for the security element by encrypting the authentication values by means of a public key of a key pair assigned to the security element in an asymmetric cryptosystem. Only the security element itself can then decrypt the session-specific authentication value by decrypting the encrypted session-specific authentication value by means of the private key of the security element, which forms the named key pair in addition to the public key of the security element.
  • the trustworthy, external entity can thus in a first step specific correspondence keys generate usable random numbers.
  • These session-specific random numbers are then encrypted by the external entity in each case by means of the private key of the application and then by means of the public key of the security element.
  • the external entity then transmits this list of randomly encrypted random numbers in the described manner to the application on the terminal, which receives this list as a list of session-specific authentication values and stores it in the terminal for later use.
  • Terminal is preferably also via a secure, encrypted channel.
  • the second encryption by means of the public key of the security element, can already be regarded as sufficient transport security.
  • the application selects one of the stored, session-specific authentication values and transmits it to the security element.
  • the security element decrypts the corresponding authentication value first by means of the private key of the security element and then by means of the public key of the application. As a result of this double determination, the security element then acquires the random number which is to serve as the communication key for a subsequent communication session between the application and the security element.
  • the security element can then encrypt this communication key in turn by means of the secret key of the security element and transmit it to the application which transmits the encrypted communication. finally key can decrypt by means of the public key assigned to the security element. In this way, the security element and the application have exchanged a session-specific communication key and at the same time have mutually authenticated each other.
  • the external entity can also send the random numbers separately to the application in a manner that can be decrypted specifically for the application. For example, in addition to the list of double-encrypted random numbers described above, the external entity can generate a second list in which the same random numbers are encrypted in such a way that the application can decrypt them. The external entity then sends both lists to the application. Whenever the application selects a doubly encrypted random number from the one list and transmits it to the security element for authentication, the application additionally decrypts the corresponding simply application-specific encrypted random number from the other list and in this way obtains the correct session-specific communication key.
  • a communication session between the application and the security element can be carried out.
  • This communication session is preferably secured by means of a communication key which consists of the session information used in the step of authenticating the application with respect to the security element.
  • specific authentication value derived or negotiated by means of this authentication value between the applications and the security element.
  • the application may request in particular generic security functions provided by the security element, such as the encryption, decryption or signing of data.
  • transaction-specific security functions can also be provided by the security element, such as, for example, the generation of a transaction-specific transaction data record, including a signature by the security element.
  • a preferred embodiment of a system according to the invention therefore comprises a terminal with an application executable on the terminal and a security element arranged in the terminal, as well as a trusted, external entity, which are each set up to carry out a method as described above.
  • a telecommunications terminal in particular a telecommunications terminal, a smartphone, a notebook or the like can be used as the terminal.
  • a security element in the context of the present invention, on the one hand, conventional, hardware-based security elements, such as SIM / UICC mobile cards, USB tokens, secure memory cards or the like can be used.
  • TEE trusted execution environment
  • a trusted, external instance can be, for example, a so-called “Trusted Service Manager” (TSM).
  • FIG. 1 shows the components of a preferred embodiment of a system according to the invention and FIG. 2 shows steps of a preferred embodiment of a method according to the invention.
  • a system 200 comprises a trustworthy external entity 100, for example a TSM, as well as at least one terminal 10, which is shown as an example in FIG.
  • a trustworthy external entity 100 for example a TSM
  • at least one terminal 10 which is shown as an example in FIG.
  • an application 30 is stored executable.
  • This application 30 is set up to communicate with a security element 40 of the terminal 10, for example a secure memory card 40.
  • FIG. 2 shows by way of example steps of a method which makes it possible to authenticate the application 30 with respect to the security element 40 in the terminal 10, without the security element 40 of the terminal 10 becoming vulnerable thereby.
  • a first step S1 the external entity 100 generates a plurality of session-specific authentication values for the application 30 on the terminal 10. The generation of these session-specific authentication values takes place by means of a secret key assigned to the application 30.
  • this secret key can be a symmetrical key, which is then generally also present in the security element 40.
  • the secret key may be a private key assigned to the application 30, which is part of a key pair associated with the application 30 in an asymmetric cryptosystem.
  • the public key that completes this key pair and is associated with the application 30 then also exists in particular in the security element 40 of the terminal 10.
  • the secret key associated with the application 30 is not in the application, i. in an unsecured area of the terminal 10, before. In this way, it can be prevented that an attacker can obtain the secret key assigned to the application 30 and can generate authentication values for authentication with respect to the security element 40 by means of this key.
  • a plurality of session-specific authentication values can be generated by the external entity 100 thereby.
  • the random numbers generated by the central entity 100 are respectively encrypted by means of the private key of the application 30.
  • the external entity 100 can additionally encrypt the encrypted random numbers by means of a public key, which is part of a key pair assigned to the security element 40 in an asymmetrical cryptosystem.
  • the external entity 100 can encrypt a predetermined initial value, for example a counter specifically assigned to the application 30 and the security element 40, by means of a secret symmetric key assigned to the application 30 in order to generate an authentication value.
  • a predetermined initial value for example a counter specifically assigned to the application 30 and the security element 40
  • a secret symmetric key assigned to the application 30 in order to generate an authentication value.
  • Such an authentication value can then also be generated by the security element 40 itself and used to authenticate the application 30.
  • step S2 the generated, multiple session-specific authentication values are then transmitted from the external instance 100 to the application 30 on the terminal 10. This transmission preferably takes place via a secure data transmission channel.
  • step S3 the application 30 receives the plurality of session-specific authentication values on the terminal 10 and stores them in the terminal 10 in step S4 for later use, that is to say for authentication to the security element 40.
  • step S5 the application 30 now authenticates itself to the security element 40 by means of one of the previously received and stored authentication values. For this purpose, one of these authentication values is transmitted to the security element 40, which authenticates the application 30 on the basis of the received authentication value.
  • the security element 40 decrypts it by means of the public key assigned to the application 30.
  • the security element 40 first decrypts this authentication value by means of the private key of the security element 40.
  • the security element 40 receives as a session-specific authentication value, for example, a counter encrypted using a secret symmetric key assigned to the application 30, the security element 40 generates a corresponding encrypted counter based on the secret key of the application 30 present in the security element 40 and the counter also present in the security element and compares the calculated result with the received authentication value.
  • a session-specific authentication value for example, a counter encrypted using a secret symmetric key assigned to the application 30
  • the security element 40 generates a corresponding encrypted counter based on the secret key of the application 30 present in the security element 40 and the counter also present in the security element and compares the calculated result with the received authentication value.
  • a communication key can be negotiated between the applications 30 and the security element 40.
  • this negotiation of the Kornmunikations ensurels using the used for the authentication of the application 30 against the security element 40 session-specific authentication value.
  • this random number itself is used as the communication key, which then ensures a communication session between the application 30 and the security element 40 carried out in step S7. Basically, however, can be dispensed with the derivation of a communication key.
  • the steps S5 to S7 can be repeated until all the authentication values stored in the terminal in step S4 have been used up.
  • no communication connection between the terminal 10 and the external instance 100 is required to perform the steps S5 to S7.
  • the method between the application 30 and the security element 40 autonomously in the terminal 10, i. without any connection to the external instance 100.
  • the application 30 may request further session-specific authentication values from the external instance 100, as indicated with reference to step S8.
  • the application 30 can in particular specify the security element 40 in order to allow the external entity 100 to generate specific authentication values for the security element 40. The process may then be repeated as described with reference to steps S1 through S4.
  • the central entity 100 can easily recognize an attack, for example, by the attacker requesting a large number of session-specific authentication values in a short time intended use, but just pointing to an attack.
  • the external entity 100 can then refrain from transmitting further authentication values and thereby prevent further attacks on the security element 40.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

In einem Verfahren in einem Endgerät (10) mit einer auf dem Endgerät ausführbaren Applikation (30) und einem in dem Endgerät angeordneten Sicherheitselement (40) authentisiert (S5) sich die Applikation gegenüber dem Sicherheitselement mit Hilfe eines sitzungsspezifischen Authentisierungswertes, welcher mittels eines der Applikation zugeordneten Schlüssels erzeugbar ist. Dazu empfängt die Applikation vorab mehrere sitzungsspezifische Authentisierungswerte von einer externen Instanz (100), wobei die externe Instanz die Authentisierungswerte mittels des der Applikation zugeordneten Schlüssels erzeugt hat. Die Applikation speichert (S4) die mehreren sitzungsspezifischen Authentisierungswerte für zukünftige Kommunikationssitzungen mit dem Sicherheitselement (40).

Description

A p p l i k a t i o n s a u t h e n t i s i e r u n g
Die vorliegende Erfindung betrifft ein Verfahren in einem Endgerät, beispielsweise einem Smartphone. Genauer betrifft die Erfindung ein Verfahren zum Authentisieren einer auf dem Endgerät ausführbaren Applikation gegenüber einem in dem Endgerät angeordneten Sicherheitselement.
Eine Authentisierung einer solchen Applikation gegenüber einem Sicherheitselement, beispielsweise einer SIM/UICC- Mobilfunkkarte, kann mittels eines Authentisierungsschlüssels durchgeführt werden. Ein solcher Authenti- sierungsschlüssel wird in der Regel mittels eines geheimen, der Applikation zugeordneten Schlüssels erzeugt oder abgeleitet.
In dem Fall, dass die Applikation auf einem Prozessor des Endgerätes, d.h. in einer nicht besonders gesicherten Umgebung, ausgeführt wird, besteht die Gefahr, dass ein Angreifer einen solchen geheimen Schlüssel der Applikation erlangen kann. Einmal im Besitz dieses geheimen Schlüssels der Applikation, kann sich der Angreifer gegenüber dem Sicherheitselement als Applikation authentisieren und beliebig oft mit dem Sicherheitselement kommunizieren. Dies ermöglicht Angriffe auf das Sicherheitselement des Endgeräts, welche vermieden werden sollten.
Aufgabe der vorliegenden Erfindung ist es demnach, ein Verfahren zur Authentisierung einer Applikation auf einem Endgerät gegenüber einem in dem Endgerät angeordneten Sicherheitselement vorzuschlagen, welches den vorstehend genannten Nachteilen Rechnung trägt. Diese Aufgabe wird durch ein Verfahren und ein System mit den Merkmalen der nebengeordneten Ansprüche gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Die vorliegende Erfindung basiert auf dem Grundgedanken, dass ein der Applikation zugeordneter geheimer Schlüssel, der zum Ableiten eines sitzungsspezifischen Authentisierungswertes verwendet werden kann, nicht bei der Applikation, d.h. nicht in einem ungesicherten Bereich des Endgerä- tes gespeichert ist, sondern lediglich bei einer vertrauenswürdigen, externen Instanz vorliegt. Diese externe Instanz ist eingerichtet, entsprechende Au- thentisierungswerte für die Applikation zu erzeugen und diese der Applikation bereitzustellen. Eine bevorzugte Ausführungsform eines erfindungsgemäßen Verfahrens in einem Endgerät, wobei das Endgerät eine auf dem Endgerät ausführbare Applikation und ein in dem Endgerät angeordnetes Sicherheitselement um- fasst, umfasst einen in dem Endgerät ausgeführten Schritt des Authentisie- rens der Applikation des Endgeräts gegenüber dem in dem Endgerät ange- ordneten Sicherheitselement mithilf e eines sitzungsspezifischen Authentisierungswertes, welcher mittels eines der Applikation zugeordneten geheimen Schlüssels erzeugbar ist.
„Sitzungsspezifisch" bedeutet dabei, dass der Authentisierungswert ledig- lieh zum einmaligen Authentisieren der Applikation gegenüber dem Sicherheitselement verwendet werden kann. Dabei authentisiert sich die Applikation gegenüber dem Sicherheitselement in der Regel für eine nachfolgende Kommunikationssitzung zwischen der Applikation und dem Sicherheitselement. Das Verfahren zeichnet sich durch die folgenden, dem Schritt des Authenti- sierens vorgelagerten Schritte in dem Endgerät aus: Die Applikation auf dem Endgerät empfängt von einer vertrauenswürdigen, externen Instanz mehrere sitzungsspezifische Authentisierungswerte, wobei die externe Instanz die sitzungsspezifischen Authentisierungswerte mittels des der Applikation zugeordneten, geheimen Schlüssels erzeugt hat. Vorzugsweise ist die Anzahl der seitens der Applikation empfangenen sitzungs- spezifischen Authentisierungswerte auf einen kleinen zweistelligen Wert beschränkt, z.B. 10 bis 50.
Die Applikation speichert dann die mehreren sitzungsspezifischen Authentisierungswerte zum nachfolgenden Authentisieren der Applikation gegen- über dem Sicherheitselement für zukünftige Kommunikationssitzungen mit dem Sicherheitselement.
Im vorstehend bereits beschriebenen Schritt des Authentisierens der Applikation gegenüber dem Sicherheitselement verwendet nun die Applikation des Endgeräts einen der vorab empfangenen und gespeicherten sitzungsspezifischen Authentisierungswerte als den Authentisierungswert.
Dadurch, dass der geheime, der Applikation zugeordnete Schlüssel, welcher zum Erzeugen der Authentisierungswerte verwendet wird, nicht mehr in dem Endgerät selbst vorliegt, kann ein Angreifer diesen Schlüssel grundsätzlich nicht mehr erlangen und sich folglich gegenüber dem Sicherheitselement nicht mehr ohne weiteres als Applikation authentisieren. Weiterhin vorteilhaft an dem Verfahren ist, dass der Applikation mehrere sitzungsspezifische Authentisierungswerte vorab bereitgestellt werden und diese in dem Endgerät gespeichert werden. Dadurch ist es nicht erforderlich, dass das Endgerät bzw. die Applikation eine dauerhafte Kommunikations- Verbindung mit der vertrauenswürdigen, externen Instanz aufrechterhält. Vielmehr kann die Applikation immer dann, wenn eine Authentisierung gegenüber dem Sicherheitselement erfolgen soll, einen der gespeicherten sitzungsspezifischen Authentisierungswerte zum Authentisieren gegenüber dem Sicherheitselement verwenden. Dies sichert nicht nur eine Unabhängig- keit des Verfahrens mit Bezug auf eine Kommunikations Verbindung zu der externen Instanz, sondern erlaubt überdies eine einfachere und schnellere Durchführung des Authentisierungsverfahrens, da keine Kommunikation mit der externen Instanz im Rahmen des eigentlichen Authentisierungsverfahrens mehr notwendig ist.
In dem Fall, dass die in dem Endgerät gespeicherten mehreren sitzungsspezifischen Authentisierungswerte aufgebraucht sind oder zur Neige gehen, z.B. nur noch 5 bis 10 verwendbare Authentisierungswerte verbleiben, kann die Applikation bei der vertrauenswürdigen, externen Instanz weitere sitzungs- spezifische Authentisierungswerte anfordern.
Alternativ oder zusätzlich kann die externe Instanz der Applikation auf dem Endgerät in regelmäßigen oder unregelmäßigen Abständen ein vorgegebenes Kontingent von sitzungsspezifischen Authentisierungswerten in der be- schriebenen Weise bereitstellen. Gemäß einer solchen Variante kann es vorgesehen sein, dass dann noch in dem Endgerät gespeicherte, zu einem früheren Zeitpunkt empfangene Authentisierungswerte ungültig werden. Generell erfolgt die Übertragung der Authentisierungswerte von der externen Instanz an das Endgerät bzw. die Applikation in dem Endgerät vorzugsweise über eine gesicherte Korrimunikationsverbindung. Selbst wenn es einem Angreifer gelingen sollte, einen oder mehrere der sitzungsspezifischen Authentisierungswerte - trotz der gesicherten Übertragung - zu erlangen, so ist aufgrund der vergleichsweise geringen Anzahl der erlangbaren Authentisierungswerte die Gefahr hinsichtlich eines Angriffs auf das Sicherheitselement begrenzt. Wesentlich ist, dass ein Angreifer den der Applikation zugeordneten geheimen Schlüssel nicht erlangen kann, denn nur dieser ermög- licht ein Erzeugen von weiteren sitzungsspezifischen Authentisierungs werten.
Gemäß einer ersten bevorzugten Variante des Verfahrens werden die mehreren sitzungsspezifischen Authentisierungswerte durch die externe Instanz als sitzungsspezifische Authentisierungsschlüssel mittels des bei der externen Instanz vorliegenden, der Applikation zugeordneten geheimen Schlüssels erzeugt. Gemäß dieser ersten Variante liegen die mehreren sitzungsspezifischen Authentisierungsschlüssel entweder auch bereits in dem Sicherheitselement vor oder können durch das Sicherheitselement in dem Sicher- heitselement erzeugt werden.
Zum Erzeugen der sitzungsspezifischen Authentisierungsschlüssel in dem Sicherheitselement kann der der Applikation zugeordnete geheime Schlüssel auch in dem Sicherheitselement vorliegen. Der geheime Schlüssel liegt je- doch nicht in einer ungesicherten Umgebung des Endgerätes vor, sondern lediglich gesichert in dem Sicherheitselement. Das Sicherheitselement ist dann eingerichtet, die mehreren sitzungsspezifischen Authentisierungsschlüssel seinerseits mittels des der Applikation zugeordneten geheimen Schlüssels zu erzeugen. Zum sitzungsspezifischen Erzeugen eines solchen Authentisierungsschlüs- sels kann z.B. seitens der externen Instanz bzw. seitens des Sicherheitselements jeweils ein einer spezifischen Sitzung zwischen dem Sicherheitsele- ment und der Applikation zugeordneter Zähler mittels des der Applikation zugeordneten geheimen Schlüssels verschlüsselt werden.
Gemäß einer weiteren bevorzugten Variante können die Applikation und das Sicherheitselement mittels des im Schritt des Authentisierens verwende- ten sitzungsspezifischen Authentisierungswertes für eine nachfolgende
Kommunikationssitzung einen Kommunikationsschlüssel aushandeln. Dieser Kommunikationsschlüssel ist vorzugsweise ebenfalls sitzungsspezifisch.
Gemäß einer zweiten bevorzugten Variante des eingangs allgemein beschriebenen Verfahrens entspricht der der Applikation zugeordnete geheime Schlüssel einem privaten Schlüssel eines der Applikation in einem asymmetrischen Kryptosy stem zugeordneten Schlüsselpaares. Beim Erzeugen der mehreren sitzungsspezifischen Authentisierungswerte verschlüsselt dann die externe Instanz jeweils einen sitzungsspezifischen Ausgangswert, beispielsweise eine Zufallszahl, mittels dieses der Applikation zugeordneten privaten Schlüssels, um einen sitzungsspezifischen Authentisierungswert zu erzeugen. Ein solcher sitzungsspezifischer Authentisierungswert kann dann im Sicherheitselement des Endgeräts mittels eines der Applikation zugeordneten öffentlichen Schlüssels, welcher zusammen mit dem privaten Schlüssel das Schlüsselpaar bildet, entschlüsselt bzw. verifiziert werden.
Der vorstehend erwähnte Ausgangswert, also beispielsweise eine Zufallszahl, kann selbst als Kommunikationsschlüssel für eine nachfolgende Kommunikationssitzung zwischen der Applikationen und dem Sicherheitsele- ment verwendet werden oder zumindest zum Ableiten eines solchen Kommunikationsschlüssels herangezogen werden.
Gemäß einer weiteren bevorzugten Variante werden die mehreren sitzungs- spezifischen Authentisierungswerte durch die vertrauenswürdige, externe Instanz jeweils spezifisch für das Sicherheitselement des Endgeräts erzeugt. Auf diese Weise kann sichergestellt werden, dass mittels der entsprechenden Authentisierungswerte jeweils nur genau eine Authentisierung der Applikation gegenüber dem spezifischen Sicherheitselement, und nicht gegenüber einem davon abweichenden Sicherheitselement, vorgenommen werden kann. Auf diese Weise kann es insbesondere verhindert werden, dass ein Angreifer, welchem es gelingt, einen solchen Authentisierungswert zu erlangen, diesen verwenden kann, um sich als Applikation gegenüber einem weiteren, von dem Sicherheitselement des Endgeräts unterschiedlichen Sicher- heitselement zu authentisieren.
Vorzugsweise werden die mehreren sitzungsspezifischen Authentisierungswerte durch die externe Instanz dadurch spezifisch für das Sicherheitselement erzeugt, indem die Authentisierungswerte mittels eines öffentlichen Schlüssels eines dem Sicherheitselement in einem asymmetrischen Krypto- system zugeordneten Schlüsselpaares verschlüsselt werden. Lediglich das Sicherheitselement selbst kann dann durch Entschlüsseln des verschlüsselten sitzungsspezifischen Authentisierungswertes mittels des privaten Schlüssels des Sicherheitselements, welcher neben dem öffentlichen Schlüssel des Si- cherheitselements das genannte Schlüsselpaar bildet, den sitzungsspezifischen Authentisierungswert entschlüsseln.
Gemäß der zuletzt beschriebenen Variante kann die vertrauenswürdige, externe Instanz somit in einem ersten Schritt eine Mehrzahl von als sitzungs- spezifische Korruriunikationsschlüssel verwendbare Zufallszahlen erzeugen. Diese sitzungsspezifischen Zufallszahlen werden dann seitens der externen Instanz jeweils mittels des privaten Schlüssels der Applikation und anschließend mittels des öffentlichen Schlüssels des Sicherheitselements verschlüs- seit. Die externe Instanz überträgt dann diese Liste der in der beschriebenen Weise doppelt verschlüsselten Zufallszahlen an die Applikation auf dem Endgerät, welches diese Liste als Liste sitzungsspezifischer Authentisie- rungswerte empfängt und in dem Endgerät zur späteren Verwendung speichert. Die Übertragung dieser Liste der sitzungsspezifischen Authentisie- rungswerte zwischen der externen Instanz und der Applikation auf dem
Endgerät erfolgt vorzugsweise ebenfalls über einen gesicherten, verschlüsselten Kanal. Die zweite Verschlüsselung, mittels des öffentlichen Schlüssels des Sicherheitselements, kann bereits als ausreichende Transportsicherung angesehen werden.
Möchte sich nun die Applikation gegenüber dem Sicherheitselement authen- tisieren, so wählt die Applikation einen der gespeicherten, sitzungsspezifischen Authentisierungswerte aus und überträgt diesen an das Sicherheitselement. Das Sicherheitselement entschlüsselt den entsprechenden Authenti- sierungswert zuerst mittels des privaten Schlüssels des Sicherheitselements und anschließend mittels des öffentlichen Schlüssels der Applikation. Als Ergebnis dieses zweifachen Entschlüsseins erlangt das Sicherheitselement dann die Zufallszahl, welche als Kommunikationsschlüssel für eine nachfolgende Kommunikationssitzung zwischen der Applikation und dem Sicher- heitselement dienen soll.
Das Sicherheitselement kann dann diesen Kommunikationsschlüssel seinerseits mittels des geheimen Schlüssels des Sicherheitselements verschlüsseln und an die Applikation übertragen, welche den verschlüsselten Kommunika- tionsschlüssel schließlich mittels des dem Sicherheitselement zugeordneten öffentlichen Schlüssels entschlüsseln kann. Auf diese Weise haben das Sicherheitselement und die Applikation einen sitzungsspezifischen Kommunikationsschlüssel ausgetauscht und sich gleichzeitig gegenseitig authentifi- ziert.
Alternativ zu dem Teilschritt, in dem das Sicherheitselement die Zufallszahl mittels seines privaten Schlüssels verschlüsselt und an die Applikation überträgt, kann auch die externe Instanz die Zufallszahlen, in spezifisch für die Applikation entschlüsselbarer Weise, separat an die Applikation senden. Die externe Instanz kann beispielsweise zusätzlich zu der vorstehend beschriebenen Liste doppelt verschlüsselter Zufallszahlen eine zweite Liste generieren, in welcher dieselben Zufallszahlen derart verschlüsselt werden, dass die Applikation diese entschlüsseln kann. Die externe Instanz sendet dann beide Listen an die Applikation. Immer dann, wenn die Applikation eine doppelt verschlüsselte Zufallszahl aus der einen Liste auswählt und zum Authenti- sieren an das Sicherheitselement überträgt, entschlüsselt die Applikation zusätzlich die entsprechende einfach applikationsspezifisch verschlüsselte Zufallszahl aus der anderen Liste und erlangt auf diese Weise den korrekten sitzungsspezifischen Kommunikationsschlüssel.
Im Anschluss an eine erfolgreiche Authentifizierung der Applikation durch das Sicherheitselement kann gemäß einer bevorzugten Variante des Verfahrens eine Kommunikationssitzung zwischen der Applikation und dem Si- cherheitselement durchgeführt werden.
Diese Kommunikationssitzung wird vorzugsweise mittels eines Kommunikationsschlüssels gesichert, welcher aus dem im Schritt des Authentisierens der Applikation gegenüber dem Sicherheitselement verwendeten sitzungs- spezifischen Authentisierungswert abgeleitet oder mittels dieses Authenti- sierungswertes zwischen der Applikationen und dem Sicherheitselement ausgehandelt worden ist. Im Rahmen der Kommunikationssitzung kann die Applikation insbesondere von dem Sicherheitselement bereitgestellte, generische Sicherheitsfunktionen anfordern, wie das Verschlüsseln, Entschlüsseln oder Signieren von Daten. Alternativ oder zusätzlich können auch transaktionsspezifische Sicherheitsfunktionen durch das Sicherheitselement bereitgestellt werden, wie bei- Spiels weise das Erzeugen eines transaktionsspezifischen Transaktionsdatensatzes, auch inklusive einer Signatur durch das Sicherheitselement.
Eine bevorzugte Ausführungsform eines erfindungsgemäßen Systems um- fasst demnach ein Endgerät mit einer auf dem Endgerät ausführbaren Ap- plikation und einem in dem Endgerät angeordneten Sicherheitselement sowie eine vertrauenswürdige, externe Instanz, welche jeweils eingerichtet sind, ein vorstehend beschriebenes Verfahren auszuführen.
Als Endgerät kann dabei insbesondere ein Telekommunikationsendgerät, ein Smartphone, ein Notebook oder dergleichen verwendet werden.
Als Sicherheitselement im Sinne der vorliegenden Erfindung können zum einen herkömmliche, hardwarebasierte Sicherheitselemente, wie beispielsweise SIM/UICC- Mobilfunkkarten, USB-Token, sichere Speicher karten oder dergleichen verwendet werden. Es ist aber auch möglich, ein Sicherheitselement in Form eines so genannten„trusted execution environment" (TEE) gemäß der„GlobalPlatform Specification" auszubilden oder vollständig über geeignete Softwaremittel in dem Endgerät bereitzustellen. Als vertrauenswürdige, externe Instanz kann beispielsweise ein so genannter „Trusted Service Manager" (TSM) dienen.
Die vorliegende Erfindung wird im Folgenden mit Bezug auf die beiliegen- den Zeichnungen exemplarisch beschrieben. Darin zeigen:
Figur 1 die Komponenten einer bevorzugten Ausführungsform eines erfindungsgemäßen Systems und Figur 2 Schritte einer bevorzugten Ausführungsform eines erfindungsgemäßen Verfahrens.
Wie mit Bezug auf Figur 1 exemplarisch dargestellt, umfasst ein erfindungsgemäßes System 200 eine vertrauenswürdige, externe Instanz 100, beispiels- weise einen TSM, sowie zumindest ein Endgerät 10, welches in Figur 1 exemplarisch als Smartphone dargestellt ist. In dem Endgerät 10, beispielsweise in einem herkömmlichen Prozessor 20 des Endgeräts 10, ist eine Applikation 30 ausführbar gespeichert. Diese Applikation 30 ist eingerichtet, mit einem Sicherheitselement 40 des Endgeräts 10, beispielsweise einer siche- ren Speicherkarte 40, zu kommunizieren.
Um eine Kommunikationssitzung zwischen der Applikation 30 und dem Sicherheitselement 40 in dem Endgerät 10 auf gesicherte Weise durchführen zu können, ist es vorgesehen, dass sich zumindest die Applikation 30 gegen- über dem Sicherheitselement 40 authentisieren kann. Zusätzlich kann auch eine Authentisierung des Sicherheitselements 40 gegenüber der Applikation 30 vorgesehen sein. In Figur 2 sind Schritte eines Verfahrens exemplarisch dargestellt, welches ein Authentisieren der Applikation 30 gegenüber dem Sicherheitselement 40 in dem Endgerät 10 ermöglicht, ohne dass das Sicherheitselement 40 des Endgeräts 10 dadurch angreifbar wird.
In einem ersten Schritt Sl erzeugt die externe Instanz 100 eine Mehrzahl sitzungsspezifischer Authentisierungswerte für die Applikation 30 auf dem Endgerät 10. Das Erzeugen dieser sitzungsspezifischen Authentisierungswerte erfolgt dabei mittels eines der Applikation 30 zugeordneten, geheimen Schlüssels.
Dieser geheime Schlüssel kann einerseits ein symmetrischer Schlüssel sein, welcher dann in der Regel ebenfalls in dem Sicherheitselement 40 vorliegt. Alternativ kann der geheime Schlüssel ein der Applikation 30 zugeordneter privater Schlüssel sein, welcher Teil eines der Applikation 30 in einem asymmetrischen Kryptosystem zugeordneten Schlüsselpaares ist. Der dieses Schlüsselpaar vervollständigende, der Applikation 30 zugeordnete öffentliche Schlüssel liegt dann insbesondere auch in dem Sicherheitselement 40 des Endgeräts 10 vor.
In beiden Fällen liegt jedoch der der Applikation 30 zugeordnete, geheime Schlüssel nicht bei der Applikation, d.h. in einem ungesicherten Bereich des Endgerätes 10, vor. Auf diese Weise kann verhindert werden, dass ein Angreifer den der Applikation 30zugeordneten, geheimen Schlüssel erlangen und mittels dieses Schlüssels Authentisierungswerte zum Authentisieren gegenüber dem Sicherheitselement 40 erzeugen kann.
Gemäß einer bevorzugten Variante kann eine Mehrzahl sitzungsspezifischer Authentisierungswerte durch die externe Instanz 100 dadurch erzeugt wer- .
- 13 - den, dass seitens der zentralen Instanz 100 erzeugte Zufallszahlen jeweils mittels des privaten Schlüssels der Applikation 30 verschlüsselt werden. Um die Mehrzahl der sitzungsspezifischen Authentisierungswerte zusätzlich spezifisch für das Sicherheitselement 40 des Endgeräts 10 zu erzeugen, kann die externe Instanz 100 die verschlüsselten Zufallszahlen zusätzlich jeweils noch mittels eines öffentlichen Schlüssels, welcher Teil eines in einem asymmetrischen Kryptosystem dem Sicherheitselement 40 zugeordneten Schlüsselpaares ist, verschlüsseln. Gemäß einer alternativen bevorzugten Variante kann die externe Instanz 100 einen vorgegebenen Ausgangswert, beispielsweise einen spezifisch der Applikation 30 und dem Sicherheitselement 40 zugeordnete Zähler, mittels eines der Applikation 30 zugeordneten, geheimen symmetrischen Schlüssels verschlüsseln, um einen Authentisierungswert zu erzeugen. Ein solcher Au- thentisierungswert kann dann durch das Sicherheitselement 40 selbst ebenfalls erzeugt werden und zum Authentifizieren der Applikation 30 herangezogen werden.
In Schritt S2 werden dann die erzeugten, mehreren sitzungsspezifischen Au- thentisierungswerte von der externen Instanz 100 an die Applikation 30 auf dem Endgerät 10 übermittelt. Vorzugsweise erfolgt diese Übermittlung über einen gesicherten Datenübertragungskanal.
In Schritt S3 empfängt die Applikation 30 auf dem Endgerät 10 die mehreren sitzungsspezifischen Authentisierungswerte und speichert diese in Schritt S4 in dem Endgerät 10 zur späteren Verwendung, das heißt zur Authentisie- rung gegenüber dem Sicherheitselement 40. In Schritt S5 authentisiert sich nun die Applikation 30 gegenüber dem Sicherheitselement 40 mittels eines der vorab empfangenen und gespeicherten Authentisierungswerte. Dazu wird einer dieser Authentisierungswerte an das Sicherheitselement 40 übertragen, welches die Applikation 30 anhand des empfangenen Authentisierungswertes authentifiziert.
In dem Fall, dass zum Beispiel eine mittels des privaten Schlüssels der Applikation 30 verschlüsselte Zufallszahl als sitzungsspezifischer Authentisie- rungswert verwendet wird, entschlüsselt das Sicherheitselement 40 densel- ben mittels des der Applikation 30 zugeordneten öffentlichen Schlüssels.
Falls der sitzungsspezifische Authentisierungswert, wie vorstehend angedeutet, zusätzlich noch mittels eines öffentlichen Schlüssels des Sicherheitselements 40 verschlüsselt war, um den sitzungsspezifische Authentisie- rungswert spezifisch für das Sicherheitselement 40 auszubilden, entschlüsselt das Sicherheitselement 40 zuerst diesen Authentisierungswert mittels des privaten Schlüssels des Sicherheitselements 40.
In dem Fall, dass das Sicherheitselement 40 als sitzungsspezifischen Authen- tisierungswert beispielsweise einen mittels eines der Applikation 30 zugeordneten, geheimen symmetrischen Schlüssels verschlüsselten Zähler empfängt, erzeugt das Sicherheitselement 40 einen entsprechenden verschlüsselten Zähler auf Basis des in dem Sicherheitselement 40 vorliegenden geheimen Schlüssels der Applikation 30 und des in dem Sicherheitselement eben- falls vorliegenden Zählers und vergleicht das berechnete Resultat mit dem empfangenen Authentisierungswert.
In einem optionalen Schritt S6 kann zwischen der Applikationen 30 und dem Sicherheitselement 40 ein Kommunikationsschlüssel ausgehandelt werden. Vorzugsweise erfolgt dieses Aushandeln des Kornmunikationsschlüssels mithilfe des zur Authentisierung der Applikation 30 gegenüber dem Sicherheitselement 40 verwendeten sitzungsspezifischen Authentisierungswertes. Beispielsweise kann mit Bezug auf die vorstehend beschriebene Variante, in welcher als Authentisierungswert eine doppelt verschlüsselte Zufallszahl vorgelegen hat, diese Zufallszahl selbst als Kommunikationsschlüssel herangezogen werden, welche dann eine in Schritt S7 durchgeführte Kommunikationssitzung zwischen der Applikation 30 und dem Sicherheitselement 40 sichert. Grundsätzlich kann jedoch auch auf das Ableiten eines Kommunikationsschlüssels verzichtet werden.
Die Schritte S5 bis S7 können solange wiederholt werden, bis sämtliche im Endgerät in Schritt S4 gespeicherten Authentisierungswerte aufgebraucht sind. Insbesondere ist zum Durchführen der Schritte S5 bis S7 keine Kommunikationsverbindung zwischen dem Endgerät 10 und der externen Instanz 100 erforderlich. Dadurch kann das Verfahren zwischen der Applikation 30 und dem Sicherheitselement 40 autonom in dem Endgerät 10, d.h. ohne jede Verbindung zu der externen Instanz 100, durchgeführt werden.
Sind die gespeicherten Authentisierungswerte aufgebraucht oder liegen nur noch wenige davon vor, so kann die Applikation 30, wie mit Bezug auf Schritt S8 angedeutet, bei der externen Instanz 100 weitere sitzungsspezifische Authentisierungswerte anfordern. Dabei kann die Applikation 30 insbe- sondere das Sicherheitselement 40 spezifizieren, um es der externen Instanz 100 zu ermöglichen, für das Sicherheitselement 40 spezifische Authentisierungswerte zu erzeugen. Der Prozess kann dann, wie mit Bezug auf die Schritte Sl bis S4 beschrieben, wiederholt werden.
Dadurch, dass ein der Applikation 30 zugeordneter geheimer Schlüssel, wel- eher in jedem Fall zum Erzeugen eines sitzungsspezifischen Authentisie- rungswertes benötigt wird, nicht mehr bei der Applikation 30 in dem Endgerät 10, d.h. nicht mehr in einer grundsätzlich ungesicherten Umgebung, vorliegt, kann ein solcher geheimer Schlüssel von einem Angreifer nicht mehr erlangt werden. Folglich ist der Angreifer nicht mehr in der Lage, selbst eine große Anzahl von Authentisierungswerten mithilfe eines solchen, der Applikation 30 zugeordneten, geheimen Schlüssels zu erzeugen.
Selbst wenn es einem Angreifer gelingen sollte, seitens der externen Instanz 100 erzeugte und an die Applikation 30 auf dem Endgerät 10 übermittelte sitzungsspezifische Authentisierungswerte zu erlangen, so ist deren Anzahl doch sehr begrenzt und erlaubt keinen extensiven Angriff auf das Sicherheitselement 40.
Auch wenn es einem Angreifer gelingen sollte, sich gegenüber der zentralen Instanz 100 als Applikation 30 auszugeben, so kann die zentrale Instanz 100 einen Angriff beispielsweise leicht daran erkennen, dass der Angreifer in kurzer Zeit eine große Anzahl von sitzungsspezifischen Authentisierungswerten anfordert, welche nicht auf einen bestimmungsgemäßen Gebrauch, sondern eben auf einen Angriff hindeutet. Die externe Instanz 100 kann dann von dem Übermitteln weiterer Authentisierungswerte absehen und dadurch weitere Angriffe auf das Sicherheitselement 40 verhindern.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren in einem Endgerät (10), wobei das Endgerät (10) eine auf dem Endgerät (10) ausführbare Applikation (30) und ein in dem Endgerät (10) angeordnetes Sicherheitselement (40) umfasst, umfassend den Schritt in dem Endgerät (10):
Authentisieren (S5) der Applikation (30) gegenüber dem Sicherheitselement (40) mit Hilfe eines sitzungsspezifischen Authentisierungswertes, welcher mittels eines der Applikation (30) zugeordneten Schlüssels erzeugbar ist;
gekennzeichnet durch die dem Schritt des Authentisierens vorgelagerten Schritte in dem Endgerät (10):
Empfangen (S3) mehrerer sitzungsspezifischer Authentisierungswerte von einer externen Instanz (100) durch die Applikation (30), wobei die externe Instanz (100) die Authentisierungswerte mittels des der Applikation (30) zugeordneten Schlüssels erzeugt hat; und
Speichern (S4) der mehreren sitzungsspezifischen Authentisierungswerte durch die Applikation (30) zum Authentisieren der Applikation (30) gegenüber dem Sicherheitselement (40) für zukünftige Kommunikationssitzungen mit dem Sicherheitselement (40);
wobei die Applikation (30) im Schritt des Authentisierens gegenüber dem Sicherheitselement (40) einen der vorab empfangenen und gespeicherten sitzungsspezifischen Authentisierungswerte als Authentisierungswert verwendet.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die mehreren sitzungsspezifischen Authentisierungswerte durch die externe Instanz (100) als sitzungsspezifische Authentisierungsschlüssel mittels eines der Applikation (30) zugeordneten geheimen Schlüssels erzeugt werden,
wobei die mehreren sitzungsspezifischen Authentisierungsschlüssel auch in dem Sicherheitselement (40) vorliegen oder durch das Sicherheitselement (40) erzeugt werden können.
3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der der Applikation (30) zugeordnete geheime Schlüssel auch in dem Sicherheitselement (40) vorliegt und das Sicherheitselement (40) eingerichtet ist, die mehreren sitzungsspezifischen Authentisierungsschlüssel seinerseits zu erzeugen.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Applikation (30) und das Sicherheitselement (40) mittels des im Schritt des Authentisierens verwendeten sitzungsspezifischen Authentisie- rungs wertes einen Kommunikationsschlüssel aushandeln (S6).
5. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der der Applikation (30) zugeordnete Schlüssel ein privater Schlüssel eines der Applikation (30) in einem asymmetrischen Kryptosystem zugeordneten Schlüsselpaares ist und dass beim Erzeugen der mehreren sitzungsspezifischen Authentisierungswerte jeweils ein sitzungsspezifischer Ausgangswert mittels des privaten Schlüssels verschlüsselt wird, um einen sitzungsspezifischen Authentisierungswert zu erzeugen.
6. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass der Ausgangswert als Kommunikationsschlüssel oder zum Ableiten eines Kommunikationsschlüssels für eine nachfolgende Kommunikationssitzung zwischen der Applikation und dem Sicherheitselement verwendet wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass die mehreren sitzungsspezifischen Authentisierungswerte spezifisch für das Sicherheitselement (40) des Endgeräts (10) erzeugt werden.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass die mehreren sitzungsspezifisch erzeugten Authentisierungswerte durch die externe Instanz (100) mittels eines öffentlichen Schlüssels eines dem Sicherheitselement (40) in einem asymmetrischen Kryptosystem zugeordneten Schlüsselpaares verschlüsselt werden.
9. Verfahren nach einem der Ansprüche 1 bis 8, gekennzeichnet durch folgenden Schritt nach einer erfolgreichen Authentifizierung der Applikation (30) durch das Sicherheitselement (40):
Durchführen (S7) einer Kommunikationssitzung zwischen der Appli- kation (30) und dem Sicherheitselement (40).
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Kommunikationssitzung mittels eines Kommunikationsschlüssels gesichert wird, welcher aus dem im Schritt des Authentisierens verwendeten sitzungs- spezifischen Authentisierungswert abgeleitet oder mittels dieses Authenti- sierungswertes zwischen der Applikation (30) und dem Sicherheitselement (40) ausgehandelt worden ist.
11. Verfahren nach einen der Ansprüche 1 bis 10, gekennzeichnet durch den weiteren Schritt in dem Endgerät (10):
Anfordern (S8) weiterer sitzungsspezifischer Authentisierungswerte bei der externen Instanz (100) durch die Applikation (30).
12. Endgerät (10) mit einer auf dem Endgerät (10) ausführbaren Applikation (30) und einem in dem Endgerät (10) angeordneten Sicherheitselement (40), eingerichtet zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 11.
13. System (200), umfassend
ein Endgerät (10), wobei das Endgerät (10) eine auf dem Endgerät (10) ausführbare Applikation (30) und ein in dem Endgerät (10) angeordnetes Sicherheitselement (40) umfasst, sowie
- eine externe Instanz (100),
welche jeweils eingerichtet sind, ein Verfahren nach einem der Ansprüche 1 bis 11 durchzuführen.
EP16725371.5A 2015-05-26 2016-05-25 Applikationsauthentisierung Withdrawn EP3304399A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015006752.4A DE102015006752A1 (de) 2015-05-26 2015-05-26 Applikationsauthentisierung
PCT/EP2016/000872 WO2016188636A1 (de) 2015-05-26 2016-05-25 Applikationsauthentisierung

Publications (1)

Publication Number Publication Date
EP3304399A1 true EP3304399A1 (de) 2018-04-11

Family

ID=56083983

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16725371.5A Withdrawn EP3304399A1 (de) 2015-05-26 2016-05-25 Applikationsauthentisierung

Country Status (3)

Country Link
EP (1) EP3304399A1 (de)
DE (1) DE102015006752A1 (de)
WO (1) WO2016188636A1 (de)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130139230A1 (en) * 2006-09-24 2013-05-30 Rfcyber Corporation Trusted Service Management Process
GB201105765D0 (en) * 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
US8904195B1 (en) * 2013-08-21 2014-12-02 Citibank, N.A. Methods and systems for secure communications between client applications and secure elements in mobile devices
US8745390B1 (en) * 2013-11-13 2014-06-03 Google Inc. Mutual authentication and key exchange for inter-application communication

Also Published As

Publication number Publication date
WO2016188636A1 (de) 2016-12-01
DE102015006752A1 (de) 2016-12-01

Similar Documents

Publication Publication Date Title
EP3175384B1 (de) Verfahren und vorrichtung zum login bei medizinischen geräten
DE112011100182B4 (de) Datensicherheitsvorrichtung, Rechenprogramm, Endgerät und System für Transaktionsprüfung
EP3443705B1 (de) Verfahren und anordnung zum aufbauen einer sicheren kommunikation zwischen einer ersten netzwerkeinrichtung (initiator) und einer zweiten netzwerkeinrichtung (responder)
EP2656535B1 (de) Kryptographisches verfahren
DE112008001436T5 (de) Sichere Kommunikation
DE10393259B4 (de) Verfahren und Vorrichtung zum Verbessern der Authentifizierung in einem kryptographischen System
DE102018202176B4 (de) Master-Slave-System zur Kommunikation über eine Bluetooth-Low-Energy-Verbindung
EP2929648A1 (de) Verfahren zum aufbau einer sicheren verbindung zwischen clients
EP3220575B1 (de) Verfahren zur herstellung einer sicheren kommunikation zwischen einem client und einem server
EP3206154B1 (de) Verfahren und vorrichtungen zum sicheren übermitteln von nutzdaten
EP3525414A1 (de) Verfahren zur verschlüsselten übertragung von daten auf einer kryptographisch geschützten, unverschlüsselten kommunikationsverbindung
AT519025B1 (de) Verfahren zum Austausch von Datenfeldern von zertifizierten Dokumenten
EP3248324B1 (de) Verteiltes bearbeiten eines produkts auf grund von zentral verschlüsselt gespeicherten daten
EP2893668B1 (de) Verfahren zur erstellung einer abgeleiteten instanz eines originaldatenträgers
EP3050244B1 (de) Bereitstellung und verwendung pseudonymer schlüssel bei hybrider verschlüsselung
EP3882796A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
AT504634B1 (de) Verfahren zum transferieren von verschlüsselten nachrichten
DE102019216203A1 (de) Auf Blockverschlüsselung basierender Proof-of-Work
DE10216396A1 (de) Verfahren zur Authentisierung
EP3304399A1 (de) Applikationsauthentisierung
DE102016106602A1 (de) Verfahren und Anordnung zum Aufbauen einer sicheren Kommunkation zwischen einer ersten Netzwerkeinrichtung (Initator) und einer zweiten Netzwerkeinrichtung (Responder)
EP3367285B1 (de) Terminal, id-token, computerprogramm und entsprechende verfahren zur authentisierung einer zugangsberechtigung
EP2481183A1 (de) Verfahren zum aufbauen eines gesicherten kommunikationskanals
EP4242890B1 (de) Verfahren zur sicheren identifizierung einer person durch eine verifikationsinstanz
EP1387520B1 (de) Verfahren zum Erzeugen eines Geheimschlüssels

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

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

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20200205

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