EP4423641A1 - Autorisieren einer anwendung auf einem sicherheitselement - Google Patents

Autorisieren einer anwendung auf einem sicherheitselement

Info

Publication number
EP4423641A1
EP4423641A1 EP22800087.3A EP22800087A EP4423641A1 EP 4423641 A1 EP4423641 A1 EP 4423641A1 EP 22800087 A EP22800087 A EP 22800087A EP 4423641 A1 EP4423641 A1 EP 4423641A1
Authority
EP
European Patent Office
Prior art keywords
user verification
application
user
controller
sensor
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.)
Pending
Application number
EP22800087.3A
Other languages
English (en)
French (fr)
Inventor
Oliver Gibis
Werner Ness
Alexander SUMMERER
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient ePayments GmbH
Original Assignee
Giesecke and Devrient ePayments GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient ePayments GmbH filed Critical Giesecke and Devrient ePayments GmbH
Publication of EP4423641A1 publication Critical patent/EP4423641A1/de
Pending 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/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • 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
    • 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/602—Providing cryptographic facilities or services

Definitions

  • the present invention relates to a method for authorizing an application installed on a security element and a corresponding device with a security element and a user verification element.
  • Mobile devices are known which can be used for digital transactions, such as digital payments or the like.
  • Devices of this type can be designed, for example, as watches or key fobs, but also as telecommunications terminals such as mobile phones or the like. It is often beneficial to provide these devices with a user verification capability, such as biometric testing, to secure transactions.
  • the applications are provided as binary code by third parties and the source code is not even available to the manufacturer of the said devices.
  • the third-party provider must be commissioned with a corresponding modification.
  • different types of biometric verification systems may have to be genes are taken into account individually and/or various third-party providers are active. This regularly leads to the fact that applications have to be additionally or re-certified, which results in considerable costs and time
  • the present invention relates to authorizing an application installed on a security element and comprises several steps: According to a first step, a user feature of a user is detected by means of a sensor of a user verification element and from this sensor data are determined that characterize the user feature. In a second step, the user verification element derives a user verification status of the user from the sensor data. In a third step, the derived user verification status is transmitted from the user verification element to the security element for authorization of the application by the security element and the application is authorized on the basis of the user verification status
  • the invention characterized in this way makes it possible to provide a user verification status to a security element with applications installed on it and to use it there to authorize the application. Neither the security element or its operating system nor the application itself has to carry out the user verification themselves or be specifically adapted for this purpose.
  • already existing applications can be provided with access and/or transaction protection without changing their source code or binary code, without having to carry out a new installation or renewed certification, or having to modify the application in any other way.
  • the user verification is modularized and thereby decoupled from the actual authorization.
  • all aspects of the user verification are bundled on a user verification element, which is implemented separately from the security element and makes the required user verification status for its authorization available to this or the relevant application. Any security-relevant or user- or application-specific applications executed on the security element therefore do not have to be adapted for a specific user verification.
  • the device according to the invention is appropriately equipped and set up to check the authorization according to the invention of the application installed on the security element.
  • the device according to the invention comprises a user verification element and a security element with applications installed on it.
  • the user verification element is set up to detect a user feature using the sensor and to derive a user verification status from this, which characterizes the user feature.
  • the user verification element is set up to transmit the user verification status to the security element.
  • the security element is set up to receive the user verification status and to use this to authorize the application.
  • the method according to the invention preferably includes the step of providing said device with a security element and user verification element.
  • the security element and the user verification element are structurally separate and maintain a data communication connection.
  • the user verification element preferably includes at least one sensor controller assigned to the sensor and a verification controller.
  • the security element in turn comprises a switching application. While the sensor controller derives the user verification status from the sensor data, the verification controller transmits the user verification status to the security element or to its intermediary application.
  • the intermediary application can allow or deny certain steps depending on the user verification status, such as authorizing or denying the application in question and preventing the execution of transactions.
  • the sensor controller can determine whether a positive user verification status results from the sensor data and can forward the user verification status to the verification controller.
  • the sensor controller can determine, independently of the other components of the device according to the invention, whether the user can be verified by the sensor data.
  • At least one application is selected on the security element and/or a transaction is carried out with the at least one application. If there is a positive user verification status, transactions with the security element are permitted, for example.
  • the user verification by means of the sensor and its sensor controller avoids a security-related adaptation of the application required for the transaction. These adjustments can instead be made in the mediator application and in the verification controller. Since the user verification by means of sensor data is implemented logically and preferably structurally separately from the applications of the security element and the user verification status is securely transferred to the applications, a modification of the applications and thus a break in the corresponding certifications is avoided.
  • the sensor is preferably a biometric sensor that generates sensor data that characterizes a biometric user feature.
  • the biometric sensor is particularly preferably a fingerprint sensor and the sensor controller is a fingerprint controller. This allows the user verification status to be determined easily because the user does not need to possess any special items or prove knowledge. In particular, a biometric sensor relieves the verification controller. In some cases, this can result in lower power requirements and a correspondingly longer battery life.
  • the intermediary application of the security element, the verification controller and/or the sensor controller is preferably pre-personalized by securely storing personalized data in these components.
  • This data preferably includes a set of keys with one or more cryptographic keys that are suitable for encrypting the relevant data communication.
  • the same set of keys is preferably stored in the intermediary application, verification controller and sensor controller during the pre-personalization.
  • the encryption of the data communication between verification controller, intermediary application and/or sensor controller prevents unauthorized reading out or manipulation of the user verification status by an attacker.
  • the information and data transmitted between the components mentioned are at least partially secured with message authentication codes in order to ensure or to be able to check the authenticity of the information and data transmitted.
  • the user verification status is preferably transmitted according to a security protocol, which preferably uses a challenge-response method.
  • a security protocol which preferably uses a challenge-response method.
  • the information transfer between verification controller, intermediary application and/or sensor controller takes place at least partially according to such a security protocol. This prevents manipulation of the user verification status, for example through logical attacks by malware in the verification controller or physical attacks on cable connections between the components.
  • an application is authorized by the intermediary application determining a positive user verification status.
  • the application can be selected and/or a transaction can be carried out using the application.
  • the user verification status is preferably reset with the aid of an application, so that further selection of applications and/or implementation of a Transaction is only possible with renewed user verification. If the device according to the invention is stolen, for example after a user verification and the subsequent transaction, a further, then unauthorized transaction is prevented
  • the security element generally carries out transactions without contact using a suitable transmitting and receiving device on the security element or verification controller, for example using an NFC or Bluetooth module with an antenna.
  • the transmitting and receiving device can be arranged on the security element or verification controller, for example.
  • a device set up for such a contactless transaction does not require any lines leading to the outside which are questionable in terms of security.
  • Authentication transactions, payment transactions and/or access transactions are preferably authorized according to the invention.
  • a user who has been verified beforehand is authenticated by means of an authentication transaction, so that the user can carry out a payment transaction and/or gain access to a system or object.
  • the device according to the invention has the form of a key fob, in particular it is a "key fob" with an integrated fingerprint sensor.
  • the verification controller preferably detects whether the user wants to carry out a user verification.
  • the verification controller requests a challenge from the switching application, such as a random number, which is preferably protected with a message authentication code, for example using an HMAC code.
  • the sensor controller then verifies the integrity of the challenge using the message authentication code. If the message authentication code of the challenge is positive, the sensor controller preferably carries out a user verification and determines a user verification status.
  • the sensor controller then checks the integrity of the challenge using the message authentication code and, if integrity is present, carries out a user verification and determines a user verification status.
  • the sensor controller then transmits the encrypted and secured user verification status to the verification controller, which forwards it to the intermediary application, which decrypts and stores the user verification status if the associated message authentication code is recognized as correct.
  • the operating system of the security element can access the user verification status stored in this way and, in the case of a positive user verification status, allows the application to be selected and/or the relevant transaction to be executed by the application.
  • FIG. 1 shows a first embodiment of the device according to the invention
  • FIG. 2 shows a second embodiment of the device according to the invention
  • FIG. 3 shows a third embodiment of the device according to the invention.
  • the device 1 shows a device 1 with a verification controller 2, which can be designed as a BLE controller, for example as a Bluetooth Low Energy Controller DIALOG BLE 5.0 DA14683 (WL-CSP53).
  • the device 1 has a security element 3, for example a chip card, smart card, eSE, eUICC card or the like, for example an Infineon chip SLE78 with a G+D Sm@rt Cafe operating system.
  • the device 1 further includes a sensor controller 4, in particular a fingerprint controller 5, such as a Nuvoton NuMicro M480, and a sensor 6, such as a fingerprint sensor 7.
  • the BLE verification controller 2 is the main processor according to the embodiment according to FIG. 1 and routes all data communication via the BLE channel to the fingerprint controller 5 (TX/RX) and further to the security element 3.
  • FIG. 1 shows a data connection DATA and Lei - Communications RST and CLK between the verification controller 2 and the security element 3 or the sensor controller 4, as well as data connections TX ("transmit”) and RX ("receive").
  • the verification controller 2 is powered by a battery 8, such as a lithium-ion battery.
  • the verification controller 2 supplies the other components of the device 1 with power (PWD), in particular the security element 3 and the sensor controller 4.
  • a power circuit 9 (“power switch circuit”) is connected to the verification controller 2.
  • Applications 12 e.g. JavaCard applets and/or qVSDC installed, which communicate either contact-based via the verification controller 2 or contactless via the connected antenna 10.
  • the fingerprint sensor 7 transmits biometric sensor data, which depicts or represents a user feature of the user, to the fingerprint controller 5, which determines whether the user in question uses of the data can be verified.
  • the corresponding user verification status is then transmitted in encrypted form to the verification controller 2 and from there to the intermediary application 11 on the security element 3 .
  • the encryption largely rules out manipulations, for example through logical attacks by malware in the verification controller or through physical attacks, some bit manipulations at weak points such as the cable connections between fingerprint controller 5 and verification controller 2 and security element 3.
  • the device provides a challenge-response security protocol (“Key Fob Fingerprint Security Protocol”) for securing the transmission of the user verification status via insecure system components, such as the BLE controller or the cable connections of the device 1.
  • Key Fob Fingerprint Security Protocol a challenge-response security protocol
  • the device 1 has an intermediary application 11 in the security element 3, which receives and stores the user verification status according to the security protocol. As soon as an application 12 is selected or a transaction is carried out with it, the operating system 14 of the security element 3 checks the user verification status and allows the selection or transaction with a positive user verification status. After the transaction has taken place, the security element 3 resets the user verification status, so that a further transaction, for example a selection of the application, is not possible without renewed user verification.
  • Fig. 2 illustrates the process of user verification in several steps:
  • Step 21 As soon as the verification controller 2 (e.g. the BLE controller) determines that the user intends a user verification with a fingerprint as a user feature, the verification controller 2 requests a challenge (e.g. a random number) with the GET_CHALLENGE command. from the mediator application 11 in the security element.
  • a challenge e.g. a random number
  • Step 22 The mediator application 11 returns the challenge, which is protected with the message authentication code HMAC, to the verification controller.
  • Step 23 To check the fingerprint, the verification controller 2 executes the MATCH command with the HMAC-secured challenge as an input parameter and references the keys EncKeyID and MacKeyID as additional input parameters.
  • Step 24 The fingerprint controller 5 verifies the integrity of the challenge using the HMAC signature.
  • Step 25 The fingerprint controller 5 carries out the user verification by means of a fingerprint if the HMAC signature is correct. Otherwise the verification controller 2 is informed of an error message.
  • Step 26 The fingerprint controller 5 encrypts the user verification status (OK Match, No Match) and secures this via a message authentication code (HMAC) using the keys EncKey and MacKey.
  • HMAC message authentication code
  • Step 27 The fingerprint controller 5 sends the encrypted and HMAC-secured user verification status back to the verification controller 2.
  • Step 28 The verification controller 2 forwards the user verification status to the mediator application 11 on the security element 3.
  • Step 29 The broker application 11 on the security element 3 checks the HMAC signature of the received user verification status.
  • Step 30 If the HMAC signature is valid, the user verification status is decrypted by the mediator application 11
  • Step 31 The decrypted user verification status is stored in the agent application 11.
  • Step 32 The operating system 14 of the security element 3 requests the user verification status from the intermediary application 11 together with the defined AIDs and rules and checks them.
  • Step 33 If the user verification was successful and the application 12 has one of the defined AIDs, the operating system 14 allows the selection of the application 12 or the transaction with the application 12.
  • the user verification status is stored in the security element 3 .
  • the user verification status can be stored in verification controller 2, e.g. in the BLE controller.
  • the verification controller 2 generates a challenge and a corresponding message authentication code, such as an HMAC code, executes a MATCH command with the HMAC-secured challenge as an input parameter and references the cryptographic keys EncKeyID and MacKeyID as additional input parameters.
  • the fingerprint controller 5 checks the integrity of the challenge using the HMAC signature and carries out the user verification using the fingerprint if the HMAC signature is correct. Otherwise the verification controller 2 is given an error message.
  • the fingerprint controller 5 then encrypts the user verification status (OK Match, No Match), secures it using a message authentication code (HMAC) and sends the encrypted and HMAC-secured user verification status back to verification controller 2.
  • the verification controller 2 checks the message authentication code of the received user verification status and decrypts the user verification status if the HMAC signature is valid. The decrypted user verification status is finally stored in the verification controller 2 .
  • the MATCH command can lead to the following results:
  • OK Match The selected template matches the finger on the sensor and returns the matching ID value
  • the sensor controller 4, the fingerprint controller 5, the verification controller 2 and the mediator application 11 require pre-stored encryption keys and message authentication codes so that a user verification command can be executed. These keys are stored in the components mentioned during the manufacture of the device 1 and are set permanently by a KEY_LOCK command.
  • the keys are stored in the verification controller 2 itself and blocked by the latter against overwriting.
  • the keys EncKeyID_l [16 bytes] and Ma- cKeyID_l [32 bytes] stored in the security element 3 and in the sensor controller 4.
  • the keys EncKeyID_2 and MacKey ID_2 are stored in verification controller 2 and sensor controller 4. These keys can no longer be changed after the KEY_LOCK command has been executed.
  • FIG 3 shows the device 1 comprising the security element 2 and the user verification element 100 with the verification controller 2, the sensor 6 and the sensor controller 4.
  • the verification controller 2 has a processor unit 201 , a volatile memory 202 and a non-volatile memory 203 .
  • the verification controller 2 has communication interfaces 204 and 205 for connection to the sensor controller 4 and the security element 3 .
  • the security element comprises a processor unit 301, a volatile memory 302 and a non-volatile memory 303 as well as a communication interface 304 which is connected to the verification controller 2.
  • the sensor controller 4 has a processor unit 401, a volatile memory 402, a non-volatile memory 403 and a communication interface 404, which is connected to the verification controller 2.
  • the user verification element 100 is designed and set up to carry out a user verification with the aid of the sensor 6 and to transmit the user verification status obtained to the intermediary application 11 on the security element 3 in encrypted form.
  • the user verification status is transmitted in encrypted form from the sensor controller 4 to the verification controller 2 and from there to the security element 3 .
  • the security element 3 is designed and set up to decrypt the encrypted user verification status transmitted by the user verification element 100 .
  • FIG. 4 illustrates the steps of the method according to the invention for authorizing an application 12 installed on a security element 3 by means of a device 1 according to the invention with user verification element 100 and security element 3:
  • Step 41 detection of a user feature of a user of the device 1 by a sensor 6 of a user verification element (100) and generation of sensor data characterizing the user feature by the sensor controller 4 of the user verification element 100;
  • Step 42 deriving a user verification status from the sensor data by the user verification element or its sensor controller;
  • Step 43 Secure transmission of the user verification status from the user verification element 100 to the security element 3 to authorize the application 12 through the switching application 11;
  • Step 44 storing the authorization information on the security element 3 (optional).
  • Steps 45, 46 selecting the application 12 on the security element

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Collating Specific Patterns (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Ein erfindungsgemäßes Verfahren zum Autorisieren einer auf einem Sicherheitselement (3) installierten Anwendung (12) umfasst die Schritte der Erfassens (41) eines Benutzermerkmals durch einen Sensor (6) eines Benutzerverifikationselements (100) und Erzeugens von Sensordaten, die das Benutzermerkmal charakterisieren; des Ableitens (42) eines Benutzerverifikationsstatus aus den Sensordaten durch das Benutzerverifikationselement (100); und des Übermittelns (43) des Benutzerverifikationsstatus von dem Benutzerverifikationselement (100) an das Sicherheitselement (3) zum Autorisieren der Anwendung (12) durch das Sicherheitselement (3).

Description

A u t o r i s i e r e n e i n e r A n w e n d u n g a u f e i n e m S i c h e r h e i t s e 1 e m e n t
Die vorliegende Erfindung betrifft ein Verfahren zum Autorisieren einer auf ei- nem Sicherheitselement installierten Anwendung sowie eine entsprechende Vorrichtung mit einem Sicherheitselement und einem Benutzerverifikationsele- ment.
Es sind mobile Vorrichtungen bekannt, die für digitale Transaktionen einge- setzt werden können, etwa für digitales Bezahlen oder dergleichen. Derartige Vorrichtungen können beispielsweise als Uhren oder Schlüsselanhänger ausge- führt sein, aber auch als Telekommunikationsendgeräte, wie etwa Mobiltele- fone oder dergleichen. Häufig ist es vorteilhaft, diese Vorrichtungen mit einer Möglichkeit zur Benutzerverifikation auszustatten, beispielsweise mittels einer biometrischen Prüfung, um Transaktionen abzusichern.
Allerdings können die für eine Transaktion erforderlichen Applikationen bzw. Anwendungen, die häufig auf den betreffenden Sicherheitselementen installiert sind und von diesen ausgeführt werden, nicht durch den Hersteller der Vor- richtungen modifiziert werden, etwa weil dies Zertifizierungs- oder andere Si- cherheitsanforderungen nicht zulassen.
In anderen Fällen werden die Anwendungen als Binärcode von Drittanbietern bereitgestellt und der Quellcode liegt dem Hersteller der genannten Vorrich- tungen gar nicht vor. Für ein Absichern von Transaktionen muss daher bei- spielsweise der Drittanbieter mit einer entsprechenden Modifikation beauftragt werden. Um sämtliche relevanten Anwendungen entsprechend zu modifizie- ren, müssen unter Umständen verschiedene Arten von biometrischen Prüfun- gen individuell berücksichtigt und/ oder verschiedene Drittanbieter tätig wer- den. Dies führt regelmäßig dazu, dass Anwendungen zusätzlich oder erneut zertifiziert werden müssen, was erhebliche Kosten und Zeitaufwand zur Folge hat
Es ist insofern die Aufgabe der vorliegenden Erfindung, eine Lösung vorzu- schlagen, die die oben genannten sowie weitere Nachteile des Standes der Tech- nik überwindet.
Gelöst wird diese Aufgabe durch ein Verfahren sowie eine Vorrichtung gemäß den unabhängigen Ansprüchen. In den abhängigen Ansprüchen werden wei- tere Ausgestaltungen und bevorzugte Ausführungsformen der Erfindung ange- geben.
Die vorliegende Erfindung betrifft ein Autorisieren einer auf einem Sicherheit- selement installieren Anwendung und umfasst mehrere Schritte: Gemäß einem ersten Schritt wird ein Benutzermerkmal eines Benutzers mittels eines Sensors eines Benutzerverifikationselements erfasst und daraus werden Sensordaten er- mittelt, die das Benutzermerkmal charakterisieren. In einem zweiten Schritt lei- tet das Benutzerverifikationselement aus den Sensordaten einen Benutzerverifi- kationsstatus des Benutzers ab. In einem dritten Schritt wird der abgeleitete Be- nutzerverifikationsstatus von dem Benutzerverifikationselement an das Sicher- heitselement zum Autorisieren der Anwendung durch das Sicherheitselement übermittelt und die Anwendung anhand des Benutzerverifikationsstatus auto- risiert
Die derart charakterisierte Erfindung ermöglicht es, einem Sicherheitselement mit darauf installierten Anwendungen einen Benutzerverifikationsstatus bereit- zustellen und dort zur Autorisierung der Anwendung zu nutzen. Weder das Si- cherheitselement bzw. dessen Betriebssystem noch die Anwendung selbstmuss die Benutzerverifikation selbst durchführen oder hierfür spezifisch angepasst werden. Bereits existierende Anwendungen können erfindungsgemäß mit ei- nem Zugriffs- und/ oder Transaktionsschutz versehen werden, ohne deren Quellcode oder Binärcode zu verändern, eine Neuinstallation oder erneute Zer- tifizierung durchzuführen, oder die Anwendung anderweitig modifizieren zu müssen. Die Benutzerverifikation wird erfindungsgemäß modularisiert und dadurch von der eigentlichen Autorisierung entkoppelt.
Entsprechend werden erfindungsgemäß alle Aspekte der Benutzerverifikation auf einem Benutzerverifikationselement gebündelt, welches separat von dem Sicherheitselement realisiert ist und diesem bzw. der betreffenden Anwendung den benötigten Benutzerverifikationsstatus für deren Autorisierung zu Verfü- gung stellt. Etwaige auf dem Sicherheitselement ausgeführte, sicherheitsrele- vante oder Benutzer- oder anwendungsindividuelle Anwendungen müssen deshalb nicht für eine spezifische Benutzerverifikation angepasst werden.
Die erfindungsgemäße Vorrichtung ist entsprechend ausgestattet und einge- richtet, um die erfindungsgemäße Autorisierung der auf dem Sicherheitsele- ment installierten Anwendung zu prüfen. Dazu umfasst die erfindungsgemäße Vorrichtung ein Benutzerverifikationselement und ein Sicherheitselement mit darauf installierten Anwendungen. Das Benutzerverifikationselement ist einge- richtet, ein Benutzermerkmal durch den Sensor zu erfassen und daraus einen Benutzerverifikationsstatus abzuleiten, der das Benutzermerkmal charakteri- siert. Ferner ist das Benutzerverifikationselement eingerichtet, den Benutzerve- rifikationsstatus an das Sicherheitselement zu übermitteln. Das Sicherheitsele- ment wiederum ist eingerichtet, den Benutzerverifikationsstatus entgegenzu- nehmen und diesen zum Autorisieren der Anwendung zu nutzen. Vorzugsweise umfasst das erfindungsgemäße Verfahren den Schritt des Bereit- stellens der genannten Vorrichtung mit Sicherheitselement und Benutzerverifi- kationselement Das Sicherheitselement und das Benutzerverifikationselement sind hierbei baulich getrennt und unterhalten eine Datenkommunikationsver- bindung.
Das Benutzerverifikationselement umfasst neben dem Sensor vorzugsweise zu- mindest einen dem Sensor zugeordneten Sensorcontroller sowie einen Verifika- tionscontroller. Vorzugsweise umfasst das Sicherheitselement wiederum eine Vermittlungsanwendung. Während der Sensorcontroller den Benutzerverifika- tionsstatus aus den Sensordaten ableitet übermittelt der Verifikationscontroller den Benutzerverifikationsstatus an das Sicherheitselement bzw. an dessen Ver- mittleranwendung. In diesem Rahmen kann die Vermittleranwendung abhän- gig vom Benutzerverifikationsstatus bestimmte Schritte zulassen oder verwei- gern, etwa die betreffende Anwendung autorisieren oder die Autorisation ver- weigern und die Ausführung von Transaktionen verhindern.
Der Sensorcontroller kann bestimmen, ob sich aus den Sensordaten ein positi- ver Benutzerverifikationsstatus ergibt und kann den Benutzerverifikationssta- tus an den Verifikationscontroller weiterleiten. Insbesondere kann der Sensor- controller unabhängig von den übrigen Komponenten der erfindungsgemäßen Vorrichtung bestimmen, ob der Benutzer durch die Sensordaten verifiziert wer- den kann.
Vorzugsweise wird gemäß einem Schritt des erfindungsgemäßen Verfahrens bei Vorliegen eines von dem Sensorcontroller ermittelten positiven Benutzerve- rifikationsstatus mindestens eine Anwendung auf dem Sicherheitselement se- lektiert und/ oder eine Transaktion mit der mindestens einen Anwendung durchgeführt. Bei Vorliegen eines positiven Benutzerverifikationsstatus werden beispielsweise Transaktionen mit dem Sicherheitselement zugelassen. Die Benutzerverifikation mittels des Sensors und dessen Sensorcontrollers ver- meidet eine sicherheitstechnische Anpassung der für die Transaktion erforderli- chen Anwendung. Diese Anpassungen können stattdessen in der Vermittleran- wendung und im Verifikationscontroller vor genommen werden. Da die Benut- zerverifikation mittels Sensordaten logisch und vorzugsweise baulich getrennt von den Anwendungen des Sicherheitselements realisiert und der Benutzerve- rifikationsstatus sicher an die Anwendungen übergeben wird, wird eine Modi- fikation der Anwendungen und damit ein Bruch der entsprechenden Zertifizie- rungen vermieden.
Der Sensor ist vorzugsweise ein biometrischer Sensor, der Sensordaten erzeugt, die ein biometrisches Benutzermerkmal charakterisieren. Besonders bevorzugt ist der biometrische Sensor ein Fingerabdrucksensor und der Sensorcontroller ein Fingerabdruck-Controller. Dadurch kann der Benutzerverifikationsstatus einfach ermittelt werden, weil der Benutzer keine besonderen Gegenstände be- sitzen oder Kenntnisse nachweisen muss. Insbesondere entlastet ein biometri- scher Sensor den Verifikationscontroller. In einigen Fällen kann dies zu einem niedrigeren Energiebedarf und einer entsprechend längeren Batterielaufzeit führen.
Vorzugsweise wird die Vermittleranwendung des Sicherheitselements, der Ve- rifikationscontroller und/ oder der Sensorcontroller vorpersonalisiert, indem personalisierte Daten in diesen Komponenten sicher hinterlegt werden. Diese Daten umfassen vorzugsweise einen Schlüsselsatz mit einem oder mehreren kryptographischen Schlüsseln, die zur Verschlüsselung der betreffenden Daten- kommunikation geeignet sind. Vorzugsweise wird bei der Vorpersonalisierung derselbe Schlüsselsatz in Vermittleranwendung, Verifikationscontroller und Sensorcontroller hinterlegt. Alternativ kann ein Schlüsselsatz zur Kommunika- tion des Verifikationscontrollers mit dem Sensorcontroller und ein weiterer Schlüsselsatz zur Kommunikation mit der Vermittler an Wendung verwendet werden.
Die Verschlüsselung der Datenkommunikation zwischen Verifikationscontrol- ler, Vermittleranwendung und/oder Sensorcontroller verhindert das unberech- tigte Auslesen oder Manipulieren des Benutzerverifikationsstatus durch einen Angreifer. Die zwischen den genannten Komponenten übermittelten Informati- onen und Daten werden zumindest teilweise mit Nachrichtenauthentifizie- rungscodes gesichert, um die Authentizität der übertragenen Informationen und Daten zu gewährleisten bzw. prüfen zu können.
Der Benutzerverifikationsstatus wird bevorzugt gemäß eines Sicherheitsproto- kolls übermittelt, welches vorzugsweise ein Challenge-Response- Verfahr en nutzt. Vorzugsweise findet die Informationsübertragung zwischen Verifikati- onscontroller, Vermittleranwendung und/ oder Sensorcontroller zumindest teil- weise gemäß einem derartigen Sicherheitsprotokoll statt. Dadurch werden Ma- nipulationen des Benutzerverifizierungsstatus verhindert, beispielsweise durch logische Angriffe einer Schadsoftware im Verifikationscontroller oder physi- sche Angriffe auf Kabelverbindungen zwischen den Komponenten. Diese Maß- nahmen ermöglichen eine sichere Kommunikation über unsichere Komponen- ten der erfindungsgemäßen Vorrichtung hinweg.
Erfindungsgemäß wird eine Anwendung autorisiert, indem die Vermittleran- wendung einen positiven Benutzerverifikationsstatus feststellt. In diesem Fall kann die Anwendung selektiert werden und/oder es kann eine Transaktion mit Hilfe der Anwendung durchgeführt werden. Vorzugsweise wird nach dem Se- lektieren einer Anwendung und/ oder dem Durchführen einer Transaktion mit Hilfe einer Anwendung der Benutzerverifikationsstatus zurückgesetzt, sodass ein weiteres Selektieren von Anwendungen und/ oder Durchführen einer Transaktion nur bei erneuter Benutzerverifikation möglich ist. Falls die erfin- dungsgemäße Vorrichtung beispielsweise nach einer Benutzerverifikation und dar auf folgender Transaktion entwendet wird, wird so eine weitere, dann unau- torisierte Transaktion verhindert
Das Sicherheitselement führt Transaktionen in der Regel mittels einer geeigne- ten Sende- und Empfangseinrichtung am Sicherheitselement oder Verifikations- controller kontaktlos durch, etwa mittels eines NFC- oder Bluetooth-Moduls mit Antenne. Die Sende- und Empfangseinrichtung kann beispielsweise am Si- cherheitselement oder Verifikationscontroller angeordnet sein. Eine für eine derartige kontaktlose Transaktion eingerichtete Vorrichtung benötigt keine si- cherheitstechnisch bedenklichen nach außen geführten Leitungen.
Vorzugsweise werden Authentisierungstransaktionen, Bezahltransaktionen und/ oder Zugangstransaktion erfindungsgemäß autorisiert. Mittels einer Au- thentisierungstransaktion wird beispielsweise ein Benutzer authentisiert, der zuvor verifiziert wurde, so dass der Benutzer etwa eine Bezahltransaktion durchführen und/ oder Zugang zu einem System oder Objekt erlangen kann.
Gemäß einigen Ausführungsformen hat die erfindungsgemäße Vorrichtung die Form eines Schlüsselanhängers, insbesondere ist sie ein „Key Fob" mit inte- griertem Fingerabdrucksensor.
Vorzugsweise detektiert der Verifikationscontroller, ob der Benutzer eine Be- nutzerverifikation durchführen will. In diesem Fall fordert der Verifikations- controller eine Challenge von der Vermittlungsanwendung an, etwa eine Zu- fallszahl, welche vorzugsweise mit einem Nachrichtenauthentifizierungscode geschützt ist, zum Beispiel mittels eines HMAC-Codes. Der Sensorcontroller überprüft dann die Integrität der Challenge mit Hilfe des Nachrichtenauthentifizierungscodes. Falls der Nachrichtenauthentifizierungs- code der Challenge positiv ist, führt der Sensorcontroller vorzugsweise eine Be- nutzerverifikation durch und ermittelt einen Benutzerverifikationsstatus.
Der Sensorcontroller überprüft dann die Integrität der Challenge mit Hilfe des Nachrichtenauthentifizierungscodes und führt im Falle der vorliegenden Integ- rität eine Benutzerverifikation durch und ermittelt einen Benutzerverifikations- status. Anschließend übermittelt der Sensorcontroller den verschlüsselten und gesicherten Benutzerverifikationsstatus an den Verifikationscontroller, welcher diesen an die Vermittleranwendung weiterleitet, welche den Benutzerverifikati- onsstatus entschlüsselt und abspeichert, wenn der zugehörige Nachrichten- authentifizierungscode als korrekt erkannt wird. Das Betriebssystem des Sicher- heitselements kann auf den derart gespeicherten Benutzerverifikationsstatus zugreifen und erlaubt im Falle eines positiven Benutzerverifikationsstatus die Selektion der Anwendung und/oder die Ausführung der betreffenden Trans- aktion durch die Anwendung.
Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung erfindungsgemäßer Ausführungsbeispiele sowie weiterer Aus- führungsalternativen im Zusammenhang mit den Zeichnungen, die zeigen:
Fig. 1 eine erste Ausführungsform der erfindungsgemäßen Vorrichtung;
Fig. 2 eine zweite Ausführungsform der erfindungsgemäßen Vorrichtung;
Fig. 3 eine dritte Ausführungsform der erfindungsgemäßen Vorrichtung; und
Fig. 4 das erfindungsgemäße Verfahren. Fig. 1 zeigt eine Vorrichtung 1 mit einem Verifikationscontroller 2, der als BLE- Controller ausgeführt sein kann, beispielsweise als Bluetooth Low Energy Con- troller DIALOG BLE 5.0 DA14683 (WL-CSP53). Die Vorrichtung 1 weist ein Si- cherheitselement 3 auf, z.B. eine Chipkarte, Smart Card, eSE, eUICC-Karte oder dergleichen, etwa einen Infineon Chip SLE78 mit einem G+D Sm@rt Cafe Be- triebssystem. Die Vorrichtung 1 umfasst weiter einen Sensorcontroller 4, insbe- sondere einen Fingerabdruckcontroller 5, etwa einen Nuvoton NuMicro M480, sowie einen Sensor 6, etwa einen Fingerabdrucksensor 7.
Der BLE-Verifikationscontroller 2 ist gemäß der Ausführungsform nach Fig. 1 der Hauptprozessor und routet alle Datenkommunikation über den BLE-Kanal zum Fingerabdruckcontroller 5 (TX/RX) und weiter zum Sicherheitselement 3. Fig. 1 zeigt in diesem Zusammenhang eine Datenverbindung DATA und Lei- tungen RST und CLK zwischen dem Verifikationscontroller 2 und dem Sicher- heitselement 3 bzw. dem Sensorcontroller 4, ebenso wie Datenverbindungen TX („transmit") und RX („receive").
Der Verifikationscontroller 2 wird durch eine Batterie 8 mit Strom versorgt, etwa eine Lithium-Ionen-Batterie. Der Verifikationscontroller 2 versorgt die weiteren Komponenten der Vorrichtung 1 mit Strom (PWD), insbesondere das Sicherheitselement 3 und den Sensorcontroller 4. Zudem ist ein Leistungsschalt- kreis 9 („Power Switch Circuit") mit dem Verifikationscontroller 2 verbunden. Auf dem Sicherheitselement 3 sind Anwendungen 12 (z.B. JavaCard Applets und/ oder qVSDC) installiert, die entweder über den Verifikationscontroller 2 kontaktbasiert oder über die angeschlossene Antenne 10 kontaktlos kommuni- zieren.
Der Fingerabdrucksensor 7 übermittelt biometrische Sensordaten, die ein Be- nutzermerkmal des Benutzers abbilden bzw. dieses repräsentieren, an den Fin- gerabdruckcontroller 5, welcher feststellt, ob der betreffende Benutzer anhand der Daten verifiziert werden kann. Der entsprechende Benutzerverifikationssta- tus wird dann verschlüsselt an den Verifikationscontroller 2 und von dort wei- ter an die Vermittleranwendung 11 auf dem Sicherheitselement 3 übertragen. Durch die Verschlüsselung werden Manipulationen weitgehend ausgeschlos- sen, beispielsweise durch logische Angriffe einer Schadsoftware im Verifikati- onscontroller oder durch physische Angriffe, etwas Bit-Manipulationen an Schwachstellen, wie den Kabelverbindungen zwischen Fingerabdruckcontr oller 5 und Verifikationscontroller 2 und Sicherheitselement 3.
Insbesondere sieht die Vorrichtung ein Challenge-Response-Sicherheitsproto- koll („Key Fob Fingerprint Security Protocol") zur Sicherung der Übertragung des Benutzerverifikationsstatus über unsichere Systemkomponenten vor, wie den BLE-Controller oder die Kabelverbindungen der Vorrichtung 1.
Die Vorrichtung 1 weist im Sicherheitselement 3 eine Vermittleranwendung 11 auf, die den Benutzerverifikationsstatus gemäß dem Sicherheitsprotokoll entge- gennimmt und abspeichert. Sobald eine Anwendung 12 selektiert wird oder eine Transaktion mit dieser durchgeführt wird, prüft das Betriebssystem 14 des Sicherheitselements 3 den Benutzerverifikationsstatus und lässt die Selektion bzw. Transaktion mir bei positivem Benutzerverifikationsstatus zu. Nach er- folgter Transaktion setzt das Sicherheitselement 3 den Benutzerverifikationssta- tus zurück, sodass eine weitere Transaktion, etwa eine Selektion der Anwen- dung, ohne erneute Benutzerverifikation nicht möglich ist.
Die Vermittleranwendung 11, der Fingerabdruckcontroller 5 und der Verifikati- onscontroller 2 werden bei der Herstellung der Vorrichtung 1 innerhalb einer abgesicherten Umgebung mit dem Schlüsselsatz EncKeyID und MacKeyID für das Sicherheitsprotokoll „Key Fob Fingerprint Security Protocol" vorpersonali- siert. Fig. 2 illustriert den Ablauf einer Benutzerverifikation in mehreren Schritten:
Schritt 21: Sobald der Verifikationscontroller 2 (z.B. der BLE-Controller) fest- stellt, dass der Benutzer eine Benutzerverifikation mit einem Fingerab- druck als Benutzermerkmerkmal beabsichtigt, fordert der Verifikations- controller 2 mit dem GET_CHALLENGE-Kommando eine Challenge (z.B. eine Zufallszahl) von der Vermittleranwendung 11 im Sicherheit- selement an.
Schritt 22: Die Vermittleranwendung 11 gibt die Challenge, die mit dem Nachrichtenauthentifizierungscode HMAC geschützt ist, an den Verifi- kationscontroller zurück.
Schritt 23: Der Verifikationscontroller 2 führt zur Prüfung des Fingerab- drucks das MATCH-Kommando mit der HMAC-gesicherten Challenge als Eingabeparameter aus und referenziert die Schlüssel EncKeyID und MacKeyID als zusätzliche Eingabeparameter.
Schritt 24: Der Fingerabdruckcontroller 5 prüft die Integrität der Challenge mit Hilfe der HMAC-Signatur.
Schritt 25: Der Fingerabdruckcontroller 5 führt die Benutzerverifikation mit- tels Fingerabdrucks durch, falls die HMAC-Signatur korrekt ist. Andern- falls wird dem Verifikationscontroller 2 eine Fehlermeldung mitgeteilt.
Schritt 26: Der Fingerabdruckcontroller 5 verschlüsselt den Benutzerverifika- tionsstatus (OK Match, No Match) und sichert diesen über einen Nach- richtenauthentifizierungscode (HMAC) mit Hilfe der Schlüssel EncKey und MacKey ab.
Schritt 27: Der Fingerabdruckcontroller 5 sendet den verschlüsselten und mit HMAC gesicherten Benutzerverifikationsstatus an den Verifikationscon- troller 2 zurück.
Schritt 28: Der Verifikationscontroller 2 leitet den Benutzerverifikationsstatus an die Vermittleranwendung 11 auf dem Sicherheitselement 3 weiter. Schritt 29: Die Vermittleranwendung 11 auf dem Sicherheitselement 3 prüft die HMAC-Signatur des empfangenen Benutzerverifikationsstatus.
Schritt 30: Falls die HMAC-Signatur gültig ist, wird der Benutzerverifikati- onsstatus von der Vermittleranwendung 11 entschlüsselt
Schritt 31: Der entschlüsselte Benutzerverifikationsstatus wird in der Ver- mittleranwendung 11 gespeichert.
Schritt 32: Das Betriebssystem 14 des Sicherheitselements 3 erfragt den Be- nutzerverifikationsstatus von der Vermittleranwendung 11 zusammen mit den definierten AIDs und Regeln und prüft diese.
Schritt 33: Wenn die Benutzerverifikation erfolgreich war und die Anwen- dung 12 eine der definierten AIDs aufweist, erlaubt das Betriebssystem 14 die Selektion der Anwendung 12 bzw. die Transaktion mit der An- wendung 12.
Bei der Benutzerverifikation gemäß Fig. 2 wird der Benutzerverifikationsstatus im Sicherheitselement 3 gespeichert. Alternativ kann der Benutzerverifikations- status im Verifikationscontroller 2 gespeichert werden, z.B. im BLE-Controller. Dazu erzeugt der Verifikationscontroller 2 eine Challenge und einen entspre- chenden Nachrichtenauthentifizierungscode, etwa einen HMAC-Code, führt ein MATCH-Kommando mit der HMAC-gesicherten Challenge als Eingabepa- rameter aus und referenziert die kryptographischen Schlüssel EncKeyID und MacKeyID als zusätzliche Eingabeparameter.
Der Fingerabdruckcontroller 5 prüft die Integrität der Challenge mit Hilfe der HMAC-Signatur und führt die Benutzerverifikation mittels Fingerabdrucks durch, falls die HMAC-Signatur korrekt ist Andernfalls wird dem Verifikati- onscontroller 2 eine Fehlermeldung übergeben. Der Fingerabdruckcontroller 5 verschlüsselt dann den Benutzerverifikationsstatus (OK Match, No Match), si- chert diesen über einen Nachrichtenauthentifizierungscode (HMAC) ab und sendet den verschlüsselten und mit HMAC gesicherten Benutzerverifikations- status an den Verifikationscontroller 2 zurück. Der Verifikationscontroller 2 prüft anschließend den Nachrichtenauthentifizierungscode des empfangenen Benutzerverifikationsstatus und entschlüsselt den Benutzerverifikationsstatus, falls die HMAC-Signatur gültig ist Der entschlüsselte Benutzerverifikationssta- tus wird schließlich im Verifikationscontroller 2 gespeichert.
Das MATCH-Kommando kann insbesondere zu den folgenden Ergebnissen führen:
OK Ready: Befehl empfangen; Warten auf Fingerabdruck (=Benutzermerk- mal) auf dem Sensor;
OK FP: Finger auf dem Sensor detektiert (=Sensordaten);
OK Match: Die gewählte Vorlage stimmt mit dem Finger auf dem Sensor überein und Rückgabe des übereinstimmenden ID-Werts;
NO Match: Die gewählte Vorlage stimmt nicht mit dem Finger auf dem Sen- sor überein.
Der Sensorcontroller 4, der Fingerabdruckcontr oller 5, der Verifikationscontrol- ler 2 sowie die Vermittleranwendung 11 erfordern vorgespeicherte Schlüssel für Verschlüsselung und Nachrichtenauthentifizierungscodes, damit ein Kom- mando zur Benutzerverifikation ausgeführt werden kann. Die Speicherung die- ser Schlüssel in den genannten Komponenten findet während der Herstellung der Vorrichtung 1 statt und wird durch ein KEY_LOCK-Kommando permanent gesetzt.
Für eine auf dem Verifikationscontroller 2 basierende Benutzerverifikation wer- den die Schlüssel im Verifikationscontroller 2 selbst gespeichert und von die- sem gegen Überschreiben gesperrt. Für die Benutzerverifikation basierend auf dem Sicherheitselement werden die Schlüssel EncKeyID_l [16 Bytes] und Ma- cKeyID_l [32 Bytes] im Sicherheitselement 3 und im Sensorcontroller 4 gespei- chert. Für die Benutzerverifikation basierend auf dem Verifikationscontroller 2 werden die Schlüssel EncKeyID_2 und MacKey ID_2 im Verifikationscontroller 2 und im Sensorcontroller 4 gespeichert. Diese Schlüssel können nach der Aus- führung des KEY_LOCK-Kommandos nicht mehr geändert werden.
Fig. 3 zeigt die Vorrichtung 1 umfassend das Sicherheitselement 2 sowie das Be- nutzerverifikationselement 100 mit dem Verifikationscontroller 2, dem Sensor 6 und dem Sensorcontroller 4.
Der Verifikationscontroller 2 weist eine Prozessoreinheit 201, einen flüchtigen Speicher 202 und einen nichtflüchtigen Speicher 203 auf. Zudem weist der Veri- fikationscontroller 2 Kommunikationsschnittstellen 204 und 205 zur Verbin- dung mit dem Sensorcontroller 4 und dem Sicherheitselement 3 auf.
Das Sicherheitselement umfasst eine Prozessoreinheit 301, einen flüchtigen Speicher 302 und einen nichtflüchtigen Speicher 303 sowie eine Kommunikati- onsschnittstelle 304, die mit dem Verifikationscontroller 2 verbunden ist.
Der Sensorcontroller 4 weist eine Prozessoreinheit 401, einen flüchtigen Spei- cher 402, einen nichtflüchtigen Speicher 403 und eine Kommunikationsschnitt- stelle 404 auf, die mit dem Verifikationscontroller 2 verbunden ist.
Dabei ist das Benutzerverifikationselement 100 ausgestaltet und eingerichtet, um eine Benutzerverifikation mit Hilfe des Sensors 6 durchzuführen und den erhaltenen Benutzerverifikationsstatus verschlüsselt an die Vermittleranwen- dung 11 auf dem Sicherheitselement 3 zu übertragen. Insbesondere wird der Benutzerverifikationsstatus verschlüsselt vom Sensorkontroller 4 an den Verifi- kationskontroller 2 und von dort an das Sicherheitselement 3 übermittelt. Das Sicherheitselement 3 ist dabei ausgestaltet und eingerichtet, den vom Be- nutzerverifikationselement 100 übermittelten, verschlüsselten Benutzerverifika- tionsstatus zu entschlüsseln.
Fig. 4 illustriert abschließend die Schritte des erfindungsgemäßen Verfahrens zum Autorisieren einer auf einem Sicherheitselement 3 installierten Anwen- dung 12 mittels einer erfindungsgemäßen Vorrichtung 1 mit Benutzerverifikati- onselement 100 und Sicherheitselement 3:
Schritt 41: Erfassen eines Benutzermerkmals eins Benutzers der Vorrichtung 1 durch einen Sensor 6 eines Benutzerverifikationselements (100) und Er- zeugen von Sensordaten, die das Benutzermerkmal charakterisieren, durch den Sensorcontroller 4 des Benutzerverifikationselements 100;
Schritt 42: Ableiten eines Benutzerverifikationsstatus aus den Sensordaten durch das Benutzerverifikationselement bzw. dessen Sensorcontroller;
Schritt 43: Gesichertes Übermitteln des Benutzerverifikationsstatus von dem Benutzerverifikationselement 100 an das Sicherheitselement 3 zum Auto- risieren der Anwendung 12 durch die Vermittlungsanwendung 11;
Schritt 44: Speichern der Autorisierungsinformationen auf dem Sicherheit- selement 3 (optional); und
Schritte 45, 46: Selektieren der Anwendung 12 auf dem Sicherheitselement
3 und/ oder Durchführen einer Transaktion mit Hilfe der Anwend ung 12, sofern die Autorisierungsinformationen die Anforderungen der Liste erfüllt (optional).

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Autorisieren einer auf einem Sicherheitselement (3) in- stallierten Anwendung (12), umfassend die folgenden Schritte:
Erfassen (41) eines Benutzermerkmals durch einen Sensor (6) eines Be- nutzerverifikationselements (100) und Erzeugen von Sensor da ten, die das Benutzermerkmal charakterisieren;
Ableiten (42) eines Benutzerverifikationsstatus aus den Sensordaten durch das Benutzerverifikationselement (100); und
Übermitteln (43) des Benutzerverifikationsstatus von dem Benutzerveri- fikationselement (100) an das Sicherheitselement (3) zum Autorisieren der Anwendung (12) durch das Sicherheitselement (3).
2. Verfahren nach Anspruch 1, umfassend den Schritt des Bereitstellens ei- ner Vorrichtung (1), die das Sicherheitselement (3) und das Benutzerverifikati- onselement (100) umfasst.
3. Verfahren nach Anspruch 1 oder 2, wobei der Benutzerverifikationssta- tus von einem dem Sensor (6) zugeordneten Sensorcontroller (4) des Benut- zerverifikationselements (100) abgeleitet wird und/ oder der Benutzerverifikati- onsstatus von einem Verifikationscontroller (2) des Benutzerverifikationsele- ments (100) an eine Vermittleranwendung (11) des Sicherheitselements (3) über- mittelt wird.
4. Verfahren nach Anspruch 3, wobei der Verifikationscontroller (2) den Be- nutzerverifikationsstatus aus den Sensordaten ableitet (42) und/ oder der Sen- sorcontroller (4) bestimmt, ob sich aus den Sensordaten ein positiver Benut- zerverifikationsstatus ergibt, und den abgeleiteten Benutzerverifikationsstatus an den Verifikationscontroller (2) weiterleitet.
5. Verfahren nach einem der Ansprüche 1 bis 4, wobei eine Datenkommu- nikation zwischen dem Benutzerverifikationselement (100) und dem Sicherheit- selement (3) verschlüsselt wird und/ oder zumindest teilweise mit Nachrichten- authentifizierungscodes gesichert wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, wobei der Benutzerverifi- kationsstatus gemäß einem Sicherheitsprotokoll von dem Benutzerverifikati- onselement (100) an das Sicherheitselement (3) übermittelt wird (43). 7. Verfahren nach Anspruch 3 und Anspruch 6, wobei der Sensorcontroller
(4) und/ oder der Verifikationscontroller (2) und/ oder die Vermittleranwen- dung (11) vorpersonalisiert werden, insbesondere mit einem das Sicherheits- protokoll betreffenden kryptographischen Schlüsselsatz. 8. Verfahren nach Anspruch 3 und Anspruch 6 oder 7, wobei der Benut- zerverifikationsstatus von dem Verifikationscontroller (2) an die Vermittleran- wendung (11) mittels eines Sicherheitsprotokolls verschlüsselt übermittelt wird (43), welches ein Challenge-Response- Verfahren betrifft. 9. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Benut- zermerkmal durch einen biometrischen Sensor (6) des Benutzerverifikationsele- ments (100) erfasst wird, insbesondere durch einen Fingerabdrucksensor (7).
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Auto- risieren der Anwendung (12) den weiteren Schritt umfasst:
Selektieren (45) der Anwendung (12) auf dem Sicherheitselement (3) und/ oder Durchführen (46) einer Transaktion mit Hilfe der Anwendung (12), sofern eine Vermittleranwendung (11) des Benutzerverifikationsele- ments (100) einen positiven Benutzerverifikationsstatus feststellt.
11. Verfahren nach Anspruch 10, wobei die Vermittleranwendung (11) bei Vorliegen eines positivem Benutzerverifikationsstatus eine auf dem Sicherheit- selement (3) installierte Anwendung (12) bestimmt, welche selektiert (45) und/ oder mit Hilfe welcher Anwend ung (12) eine Transaktion durchgeführt wird (46).
12. Verfahren nach Anspruch 10 oder 11, wobei die Vermittleranwendung (11) über eine Liste von Kommandos verfügt, bei deren Ausführung der Benut- zerverifikationsstatus einer Anwendung (12) zurückgesetzt wird und/ oder nach dem Selektieren (45) der Anwendung und/oder dem Durchführen
(46) der Transaktion den Benutzerverifikationsstatus zurücksetzt, sodass ein weiteres Selektieren (45) und/ oder Durchführen einer Transaktion (46) eine Be- nutzerverifikation erfordert.
13. Verfahren nach einem der Ansprüche 10 bis 12, wobei die Transaktion mittels des Sicherheitselements (3) kontaktlos durchgeführt wird (46) und/oder als Transaktion eine Authentisierungstransaktion, eine Bezahltransaktion und/oder eine Zugangskontrolltransaktion durchgeführt wird (46).
14. Vorrichtung (1) umfassend ein Benutzerverifikationselement (100) mit ei- nem Sensor (6) und ein Sicherheitselement (3) mit einer darauf installierten An- wendung (12), wobei das Benutzerverifikationselement (100) eingerichtet ist, ein Benutzer- merkmal durch den Sensor (6) zu erfassen (41) und daraus einen Benutzerveri- fikationsstatus abzuleiten, der das Benutzermerkmal charakterisiert, sowie den Benutzerverifikationsstatus an das Sicherheitselement (3) zu übermitteln; und das Sicherheitselement (3) eingerichtet ist, zum Autorisieren der Anwen- dung (12) den Benutzerverifikationsstatus entgegenzunehmen.
15. Vorrichtung nach Anspruch 14, wobei die Vorrichtung eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 13 auszuführen.
19
EP22800087.3A 2021-10-27 2022-10-18 Autorisieren einer anwendung auf einem sicherheitselement Pending EP4423641A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021005350.8A DE102021005350A1 (de) 2021-10-27 2021-10-27 Autorisieren einer Anwendung auf einem Sicherheitselement
PCT/EP2022/000097 WO2023072423A1 (de) 2021-10-27 2022-10-18 Autorisieren einer anwendung auf einem sicherheitselement

Publications (1)

Publication Number Publication Date
EP4423641A1 true EP4423641A1 (de) 2024-09-04

Family

ID=84245847

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22800087.3A Pending EP4423641A1 (de) 2021-10-27 2022-10-18 Autorisieren einer anwendung auf einem sicherheitselement

Country Status (5)

Country Link
US (1) US20240427865A1 (de)
EP (1) EP4423641A1 (de)
CN (1) CN118159966A (de)
DE (1) DE102021005350A1 (de)
WO (1) WO2023072423A1 (de)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170357791A1 (en) * 2014-12-04 2017-12-14 Assa Abloy Ab Using sensor data to authenticate a user for a computer device

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2396330B (en) * 2002-12-20 2005-05-11 Motorola Inc A smartcard
RU2007127725A (ru) * 2004-12-20 2009-01-27 ПРОКСЕНС, ЭлЭлСи (US) Аутентификация по биометрическому ключу персональных данных (pdk)
US20090307140A1 (en) 2008-06-06 2009-12-10 Upendra Mardikar Mobile device over-the-air (ota) registration and point-of-sale (pos) payment
US10121144B2 (en) * 2013-11-04 2018-11-06 Apple Inc. Using biometric authentication for NFC-based payments
KR102460459B1 (ko) * 2015-02-27 2022-10-28 삼성전자주식회사 전자 장치를 이용한 카드 서비스 방법 및 장치
KR102324468B1 (ko) * 2017-03-28 2021-11-10 삼성전자주식회사 얼굴 인증을 위한 장치 및 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170357791A1 (en) * 2014-12-04 2017-12-14 Assa Abloy Ab Using sensor data to authenticate a user for a computer device

Also Published As

Publication number Publication date
CN118159966A (zh) 2024-06-07
DE102021005350A1 (de) 2023-04-27
WO2023072423A1 (de) 2023-05-04
US20240427865A1 (en) 2024-12-26

Similar Documents

Publication Publication Date Title
EP2218028B1 (de) Verfahren zum schutz einer chipkarte gegen unberechtigte benutzung, chipkarte und chipkarten-terminal
EP2215609B1 (de) Verfahren zum freischalten einer chipkartenfunktion mittels fernüberprüfung
DE102016113499A1 (de) Authentifizierungsverfahren zur Authentifizierung eines Benutzers eines Endgeräts
EP2389644B1 (de) Verfahren zur freischaltung einer chipkartenfunktion und lesegerät für eine chipkarte
EP3449655A1 (de) Verfahren zur sicheren interaktion eines nutzers mit einem mobilen endgerät und einer weiteren instanz
EP3882796A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
EP4423641A1 (de) Autorisieren einer anwendung auf einem sicherheitselement
EP3336736B1 (de) Hilfs-id-token zur multi-faktor-authentifizierung
DE102020205933A1 (de) Verfahren zur Kopplung eines Authentifizierungsmittels mit einem Fahrzeug
EP4423636B1 (de) Autorisieren einer anwendung auf einem sicherheitselement
EP3336732A1 (de) Nutzerauthentifizierung mit einer mehrzahl von merkmalen
EP2734984B1 (de) Verfahren zum schutz eines chipkarten-terminals gegen unberechtigte benutzung
EP1915718B1 (de) Verfahren zur absicherung der authentisierung eines tragbaren datenträgers gegen ein lesegerät über einen unsicheren kommunikationsweg
WO2005055018A1 (de) Verfahren und vorrichtung zur sicherung digitaler daten
EP2834767B1 (de) Computersystem sowie verfahren zum sicheren booten eines computersystems
DE102019109343A1 (de) Verfahren und Vorrichtung zur Übertragung digitaler Daten
WO2005073826A1 (de) System mit wenigstens einem computer und wenigstens einem tragbaren datenträger
EP1563360A1 (de) Verfahren zum schutz eines tragbaren datentr gers
WO2020234459A1 (de) Verfahren zur authentifizierung eines nutzers und authentifizierungssystem
WO2003088053A2 (de) Programmsicherungsverfahren

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

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

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240527

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 ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250514