WO2016188636A1 - Authentification d'application - Google Patents

Authentification d'application Download PDF

Info

Publication number
WO2016188636A1
WO2016188636A1 PCT/EP2016/000872 EP2016000872W WO2016188636A1 WO 2016188636 A1 WO2016188636 A1 WO 2016188636A1 EP 2016000872 W EP2016000872 W EP 2016000872W WO 2016188636 A1 WO2016188636 A1 WO 2016188636A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
security element
session
terminal
key
Prior art date
Application number
PCT/EP2016/000872
Other languages
German (de)
English (en)
Inventor
Daniel Albert
Helmut Schuster
Original Assignee
Giesecke & Devrient Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to EP16725371.5A priority Critical patent/EP3304399A1/fr
Publication of WO2016188636A1 publication Critical patent/WO2016188636A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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

Dans un procédé réalisé dans un terminal (10) dans lequel une application (30) peut être exécutée et comprenant un élément de sécurité (40), l'application s'authentifie (S5) par rapport à l'élément de sécurité à l'aide d'une valeur d'authentification spécifique à la session, pouvant être générée au moyen d'une clé associée à l'application. A cet effet, l'application reçoit au préalable plusieurs valeurs d'authentification spécifiques à la session provenant d'une instance externe (100), l'instance externe ayant généré les valeurs d'authentification au moyen de la clé associée à l'application. L'application enregistre (S4) la pluralité de valeurs d'authentification spécifiques à la session pour des sessions de communication futures avec l'élément de sécurité (40).
PCT/EP2016/000872 2015-05-26 2016-05-25 Authentification d'application WO2016188636A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP16725371.5A EP3304399A1 (fr) 2015-05-26 2016-05-25 Authentification d'application

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015006752.4A DE102015006752A1 (de) 2015-05-26 2015-05-26 Applikationsauthentisierung
DE102015006752.4 2015-05-26

Publications (1)

Publication Number Publication Date
WO2016188636A1 true WO2016188636A1 (fr) 2016-12-01

Family

ID=56083983

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/000872 WO2016188636A1 (fr) 2015-05-26 2016-05-25 Authentification d'application

Country Status (3)

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

Citations (3)

* 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
US20140040149A1 (en) * 2011-04-05 2014-02-06 Visa Europe Limited 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

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8745390B1 (en) * 2013-11-13 2014-06-03 Google Inc. Mutual authentication and key exchange for inter-application communication

Patent Citations (3)

* 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
US20140040149A1 (en) * 2011-04-05 2014-02-06 Visa Europe Limited 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

Also Published As

Publication number Publication date
EP3304399A1 (fr) 2018-04-11
DE102015006752A1 (de) 2016-12-01

Similar Documents

Publication Publication Date Title
EP3175384B1 (fr) Procédé et dispositif de connexion à des appareils médicinaux
EP3443705B1 (fr) Procédé et dispositif d'établissement d'une communication sécurisée entre un premier dispositif de réseau (initiateur) et un deuxième dispositif de réseau (répondant)
EP2656535B1 (fr) Procédé cryptographique
DE112008001436T5 (de) Sichere Kommunikation
WO2014086654A1 (fr) Procédé pour établir une liaison sûre entre des clients
DE10393259B4 (de) Verfahren und Vorrichtung zum Verbessern der Authentifizierung in einem kryptographischen System
DE102018202176A1 (de) Master-Slave-System zur Kommunikation über eine Bluetooth-Low-Energy-Verbindung
AT504634B1 (de) Verfahren zum transferieren von verschlüsselten nachrichten
EP3220575A1 (fr) Procédé de fabrication d'une communication sécurisée entre un client et un serveur
EP3206154B1 (fr) Procede et dispositifs destines a la transmission fiable de donnees utiles
EP2893668B1 (fr) Procede de creation d'une instance derivee d'un support de donnees d'origine
EP3525414A1 (fr) Procédé de transmission de données chiffrées sur une liaison de communication protégée par cryptographique, non chiffrée
EP3050244B1 (fr) Production et utilisation de clés pseudonymes dans le cryptage hybride
DE102016106602A1 (de) Verfahren und Anordnung zum Aufbauen einer sicheren Kommunkation zwischen einer ersten Netzwerkeinrichtung (Initator) und einer zweiten Netzwerkeinrichtung (Responder)
WO2016188636A1 (fr) Authentification d'application
DE10216396A1 (de) Verfahren zur Authentisierung
EP3882796A1 (fr) Authentification de l'utilisateur à l'aide de deux éléments de sécurité indépendants
WO2011035899A1 (fr) Procédé pour établir un canal de communication sécurisé
EP2880810B1 (fr) Authentication d'un document à un dispositif de lecture
EP2383672B1 (fr) Generateur de mot de passe a utilisation unique
EP3367285A1 (fr) Dispositif de commande d'accès et procédé d'authentification d'une autorisation d'accès
EP1054364A2 (fr) Méthode pour améliorer la sécurité de systèmes utilisant des signatures digitales
WO2018091703A1 (fr) Procédé et dispositif de sécurisation d'une transmission de données électronique
EP1387520B1 (fr) Procédé de génération d'une clé secrète
DE102014211839A1 (de) Verfahren zum Authentifizieren einer Entität

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16725371

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE