Nothing Special   »   [go: up one dir, main page]

EP3345364A1 - Indirekter berechtigungstransport - Google Patents

Indirekter berechtigungstransport

Info

Publication number
EP3345364A1
EP3345364A1 EP16748087.0A EP16748087A EP3345364A1 EP 3345364 A1 EP3345364 A1 EP 3345364A1 EP 16748087 A EP16748087 A EP 16748087A EP 3345364 A1 EP3345364 A1 EP 3345364A1
Authority
EP
European Patent Office
Prior art keywords
authorization
entitlement
carrier
transport
destination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP16748087.0A
Other languages
English (en)
French (fr)
Inventor
Kai Römer
Philipp Spangenberg
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.)
Blueid GmbH
Original Assignee
Blueid 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 Blueid GmbH filed Critical Blueid GmbH
Publication of EP3345364A1 publication Critical patent/EP3345364A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/108—Source integrity
    • 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/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels

Definitions

  • the present invention relates to methods and systems for securely transferring authorizations for control functions of a technical system, such as
  • the security of smart cards is combined with the benefits of Internet-enabled smartphones, so that an authorization for an object to be protected can be transmitted over an insecure channel and still be used safely and reliably.
  • Applicant's European Patent L 910 134 Bi relates to an identification system for authorization-dependent use of a technical system.
  • control functions of a vehicle can be triggered, for example by means of a mobile phone or smartphone, so that the vehicle can be opened and / or started with the mobile phone or smartphone, for example.
  • Mobile phones or similar electronic devices eg smartphones, personal digital assistants (PDAs) and / or tablet computers
  • PDAs personal digital assistants
  • tablet computers can be flexibly provided with appropriate permissions due to their Internet connectivity, if they are connected via a secure connection to the authority that has the permissions issues.
  • the present invention is therefore based on the problem to provide methods and systems with the entitlement carrier, such as smart cards, safe and flexible can be equipped with permissions, so that the above mentioned in connection with the prior art disadvantages are at least partially overcome.
  • the at least one authorization is transmitted via an unsecured communication channel to a
  • Verifying unit of an object to be protected received the at least one authorization is cryptographically signed by a trustworthy entity.
  • the at least one authorization is cryptographically signed by a trustworthy entity (also called “trust center”) and preferably also issued by it, the authorization can be transmitted via an insecure or unsecured channel and nevertheless can be used safely and reliably
  • An unsecured channel is a communication between two units via at least one interface, where the transmission path can not be used to ensure that a data packet can be read or changed by unauthorized parties
  • the Internet an SMS, a QR code, GSM, BTLE, Zigbee, general radio links such. 866 MHz, a transport channel via a
  • a digital signature is an asymmetrical cryptosystem in which a sender uses a secret signature key (the private key) to calculate a value for a digital message (in other words, the at least one authorization), which is also called a digital signature. This value allows anyone, with the help of the public verification key (the public key), to make the non-contestable
  • Authorship and integrity of the message (here the at least one authorization) to examine.
  • a signature method for example, those based on
  • Prime factor decomposition such as RSA, such as based on discrete logarithms, eg El Gamal, DSA, those based on elliptic curves, eg ECDSA, or similar are used.
  • Transport authorization carriers are received.
  • the transport entitlement carrier may have previously received the at least one entitlement from the trusted entity. This makes it possible, for example, the at least one
  • Smartphone which in this example is the transport authorization carrier
  • the verification unit which may be located, for example, in a vehicle as an object to be protected.
  • the flexibility of the method is considerably increased, since any conventional electronic devices, such as smartphones, can be used as a transport medium for the at least one authorization.
  • the authenticity of the transmitted at least one authorization is preserved thanks to the signature described above, although the at least one authorization is transmitted via an unsecured channel (for example the internet-enabled smartphone).
  • the at least one authorization may have one
  • the verification unit (for example in the vehicle) has the at least one authorization directly, e.g. over a
  • the at least one authorization is further from the at least one authorization
  • Verification unit to a destination authorization carrier via a second
  • a smartphone can be used to unlock the vehicle doors, but not for starting the vehicle, which is done in this example by means of the authorization on the smart card.
  • Authorization carrier via an unsecured communication channel, it shows the significant increase in flexibility of the method according to the invention, which thanks to the signature of at least one permission nevertheless highest
  • the present invention also enables a direct transmission of at least one authorization from a transport authorization carrier to a destination authorization carrier.
  • a method for transmitting at least one authorization for a control function of a technical system in which the at least one authorization is received by a transport authorization carrier via a third, preferably unsecured, communication channel at a destination authorization carrier.
  • the at least one authorization is also cryptographically signed by a trustworthy entity.
  • the at least one authorization at the transport authorization carrier can be received by the trustworthy entity via a, preferably unsecured, fourth communication channel. Furthermore, as has likewise been described above, it is possible for the at least one authorization to be checked for authenticity and origin in the trustworthy entity, which is preferably carried out by the verification unit of the object to be protected.
  • the method may include the further step of authenticating the
  • the destination entitlement bearer eg, a smartcard
  • the destination entitlement bearer can uniquely prove its identity to the verification unit.
  • Transport authorization bearer may include an authentication unit to authenticate to the verification unit. It can the
  • Transport authorization bearers have a lower strong authentication unit than the destination authorization bearer.
  • the at least one authorization is one or more
  • Authorization carriers for example, at least the destination authorization carrier assigned. Thus, certain destination entitlement bearers may be authorized for certain control functions (e.g., deactivating the immobilizer of a vehicle)
  • Vehicle unlocking a vehicle, locking a vehicle, releasing the full vehicle power, start booking, end booking, unlocking additional functions such as. Navigation device or seat heating, or the like).
  • the entitlement bearers mentioned here i. the transport entitlement bearer and / or the destination entitlement bearer may be an Internet-enabled entitlement bearer, a mobile phone, a smartphone, a PDA, a tablet computer, a smartwatch, a smartcard, an NFC card, a smart token, a vehicle key, an RFID card and / or a SIM card.
  • the at least one authorization is preferably a certificate, particularly preferably a digital certificate, for example a public-key certificate according to the standard X.509, or else another proprietary certificate system.
  • the at least one entitlement may have one or more of the following limitations: a temporal one
  • Limitation a functional limitation, a channel limitation, a limitation to one or more entitlement carriers and / or entitlement carrier groups, a limitation to one or more objects to be protected, a local limitation and / or a person-related limitation.
  • one or more transport entitlement bearers (20) may be used to transfer the entitlement (or also multiple entitlements) to a destination (i.e., preferably one
  • Authorization holders can also provide without the above confirmation.
  • the present invention further relates to a computer program comprising
  • a system for transmitting at least one authorization for a control function of a technical system having a verification unit of an object to be protected, which is suitable for receiving the at least one authorization via an unsecured one
  • a system for transmitting at least one authorization for a control function of a technical system having a destination authorization carrier which is suitable for receiving the at least one authorization via a third communication channel from a transport authorization carrier, wherein the at least one authorization is from a trustworthy entity is cryptographically signed.
  • a destination authorization carrier which is suitable for receiving the at least one authorization via a third communication channel from a transport authorization carrier, wherein the at least one authorization is from a trustworthy entity is cryptographically signed.
  • embodiments of the systems discussed above may be arranged to accommodate all or at least some of the methods discussed above
  • FIG. 1 is a schematic block diagram illustrating the interaction of various components according to embodiments of the invention.
  • FIG. 2 shows an exemplary authorization in XML format according to embodiments of the invention (so-called "BluelD ticket”).
  • Preferred embodiments of the present invention provide computer-implemented methods and systems that combine the security of smart cards with the benefits of Internet-enabled smartphones.
  • at least one authorization for an object to be protected can be transmitted via an insecure channel to an authorization carrier and nevertheless used safely and reliably.
  • authorization will be used both in the singular and in the plural, but it should be understood that the present invention is applicable to any number of permissions.
  • inventive systems comprise at least a subset of the components explained below with reference to FIG. 1:
  • a trustworthy entity 10 (also called “trust center”) which is suitable for creating and signing one or more authorizations.
  • a trust center is generally a service that all parties trust and that is able to issue and then sign permissions. He takes care that only the authorized person can issue authorizations and that the secrets necessary for issuing the authorization are safely stored and used.
  • a TrustCenter is connected to the Internet so that permissions can be easily and quickly distributed.
  • the TrustCenter should preferably have multiple shifts in order to achieve better protection and, if necessary, better mitigation during attacks.
  • the outermost layer has the task of repelling attacks and protecting the inner layer (s).
  • a second layer is
  • a third layer typically handles the signing of permissions.
  • a fourth layer is provided for the secure storage of the cryptographic secrets.
  • a so-called hardware secure element is often used, which, however, can also be integrated in the third layer.
  • a TrustCenter can be arranged at different places in the overall system. Ideally, the site is protected against unauthorized access (both digital and physical), is monitored to detect tampering, and has high availability for retrieving authorizations created. Usually this will be in a special area of a
  • a trust center can be operated as a cloud service for a large number of users by a trustworthy entity, such as the applicant's company, or locally by the IT department of the respective company.
  • a trustworthy entity such as the applicant's company
  • At least one object to be protected 30 (also called “secured object"), which is managed by the authorization system according to the invention.
  • vehicles e.g., motor vehicles, trucks, etc.
  • Car washes, elevators), locks e.g.
  • Cylinder lock, electronic fitting, electronic door opener), barriers and / or gates, sliding doors and / or hinged doors, or the like act.
  • One or more authorizations which are preferably assigned to one or more defined authorization carriers.
  • a permission can be defined in XML format.
  • the signature that is stored in the field permission-> signature formed over all user data between the permission tags.
  • a verification unit can check the authenticity.
  • One or more entitlement carriers 20, 40 which are suitable for storing one or more (signed) authorizations.
  • a credential carrier 20, 40 may include an authentication unit capable of cryptographically authenticating to the verification unit 35 (see below).
  • Such an authorization carrier 20, 40 is therefore suitable for the transport and storage or use of at least one authorization (for example a smartcard or a smartphone).
  • Authorization bearers 20, 40 without an authentication unit can not authenticate themselves and thus do not represent full-fledged keys; they only serve to transport at least one authorization (for example a USB stick).
  • a verification unit 35 in the object 30 to be protected (or connected to the protective object 30) which is suitable for checking whether the at least one authorization originates correctly and unchanged from the trust center 10 and / or if the authorization carrier 20, 40 is the one for which he pretends (authentication).
  • the verification unit is preferably a sealed system that is protected against manipulation. It may include a processor suitable for controlling communication with the entitlement carrier and / or to perform the verification of the authorization. In a vehicle this is often the BCM (Body Control Module). In particularly small and power-consuming implementations, such as electronic locking cylinders, this is often directly in the BCM (Body Control Module). In particularly small and power-consuming implementations, such as electronic locking cylinders, this is often directly in the BCM (Body Control Module). In particularly small and power-consuming implementations, such as electronic locking cylinders, this is often directly in the BCM (Body Control Module).
  • BCM Body Control Module
  • Communication unit e.g. the BluetoothLE chip.
  • a particular advantage of the present invention is that an authorization bearer 40 not connected to the Internet can be authorized to execute, initiate or trigger a control function of a technical system 30, without the at least one authorization having the authorization bearer 40 at the trust center 10 must be picked up. This is achieved by the fact that the
  • Permission and authentication are separate.
  • the trust center 10 secures the scope and content of the authorization cryptographically, that is to say which authorization carrier 40 is allowed to do something.
  • the identity of the destination entitlement bearer 40 must be known to the trust center 10.
  • the authorization and authorization are not only downloaded directly from the trust center 10 to the authorization medium 40, but also via any unsafe channel (for example via another
  • Authorization carriers 20, a so-called “transport authorization carrier”, can be transferred to the destination authorization carrier 40. Nevertheless, the authorization on the destination authorization carrier 40 can be used safely and reliably.
  • the present invention provides various exemplary
  • the trust center 10 transmits the authorization over the channel 100 (e.g.
  • Transport entitlement carrier 20 e.g., a smartphone.
  • Transport entitlement carrier 20 e.g., a smartphone.
  • Transport entitlement bearer 20 likewise have one or more authorizations for the object 30 to be secured and / or the transferred one
  • the transport authorization carrier 20 preferably transmits the authorization via the channel 600 directly (for example, preferably via NFC, as appropriate)
  • Authorization bearer e.g., BLE Key Fob
  • Bluetooth classic BT 1.0-3.0
  • Bluetooth LE / Smart Bluetooth LE / Smart
  • the authorization is particularly advantageous here for the authorization to be transferred from the trust center 10 to the destination authorization carrier 40 (e.g.
  • Smartcard can be transmitted.
  • no physical contact between target authorization carrier 20 and TrustCenter 10 is necessary.
  • the embodiment can be limited by specifications of the transport authorization carrier 20 (for example, not all currently available
  • Smartphones have a direct communication connection with a smartcard).
  • the trust center 10 transmits the authorization over the channel 100 (e.g.
  • Transport entitlement carrier 20 (e.g., a smartphone).
  • the transport entitlement bearer 20 may also have one or more entitlements for the object 30 to be secured and / or the transferred one
  • the transport authorization carrier 20 transmits the authorization via the channel 200 (eg, preferably Bluetooth LE or classic, NFC, Zigbee, general radio links such as 866 MHz, or another unsafe channel as mentioned above) to the verification unit 35 of the object 30 to be secured (FIG. eg a vehicle).
  • the channel 200 eg, preferably Bluetooth LE or classic, NFC, Zigbee, general radio links such as 866 MHz, or another unsafe channel as mentioned above
  • the verification unit 35 transmits the authorization via the channel 400 (eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination authorization carrier 40 (eg Smartcard), preferably as soon as it communicates with the verification unit 35.
  • the channel 400 eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination authorization carrier 40 (eg Smartcard), preferably as soon as it communicates with the verification unit 35.
  • the authorization can be transmitted via an insecure channel (eg smartphone) from the trust center 10 to the destination authorization carrier 40 (eg smartcard) become.
  • the verification unit 35 can be set up to delete the authorization again from its memory. This may be particularly advantageous in the context of car rental companies, where the verification unit of a given vehicle is loaded in a short time with a plurality of authorizations (for the different customers), which could lead to memory bottlenecks. Further, some automakers require that a permission never be allowed to remain in the vehicle, which is also addressed by this embodiment.
  • Example 3 1. The verification unit 35 of the object 30 to be protected loads the
  • Authorization over the channel 300 preferably directly (e.g., over the Internet, general wireless links such as 866MHz, SMS, GSM, or other such unsafe channel as mentioned above) from the TrustCenter 10.
  • the verification unit 35 transmits the authorization via the channel 400 (eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination authorization carrier 40 (eg a Smartcard), preferably as soon as it communicates with the verification unit 35.
  • the channel 400 eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the destination authorization carrier 40 (eg a Smartcard), preferably as soon as it communicates with the verification unit 35.
  • the authorization can reach the entitlement carrier without time-consuming detours, since the verification unit is preferably connected directly to the Internet.
  • the delivery of a permission can be easily understood.
  • a possible disadvantage here is that an online connection is necessary. As soon as e.g. in an underground car park no internet connection at a e.g. Vehicle is present, no new authorization can be loaded. Here then an alternative channel must be used, since the vehicle is not without
  • the authorization is loaded by the verification unit (eg from a local storage or by the authorization holder) and is authorized by the Verification unit checked. In this case, it is preferable to first create a hash over the content and then to verify the signature by means of the public key of the issuing trust center. Now the content is analyzed. If the authorization for the verification unit is determined and the further limitations arrive, the identity of the associated authorization carrier is determined from the
  • the identity of the authorization holder can be checked. For this purpose, it is preferably checked whether there is a specific secret in the authorization medium.
  • the necessary verification data can be derived from the identity description of the authorization holder. Usually, a random number is sent to the entitlement carrier and its response is cryptographically verified via the public key of the entitlement carrier from the entitlement. If the authorization holder matches the authorization, the action is carried out or released. Further, the present invention also allows embodiments in which the authority remains on the verification unit 35, i. not on the
  • Target authorization carrier 40 is transmitted.
  • the corresponding processes are:
  • the trust center 10 transmits the authorization over the channel 100 (e.g.
  • Internet Internet, Internet, general radio links such. 866 MHz, SMS, GSM, or another as mentioned in the beginning unsafe channel) on the
  • Transport entitlement carrier 20 (e.g., a smartphone).
  • the transport entitlement bearer 20 may also have one or more entitlements for the object 30 to be secured and / or the transferred one
  • the transport authorization carrier 20 transmits the authorization via the channel 200 (eg, preferably NFC, depending on the authorization carrier (eg BLE Key Fob) but also via Bluetooth classic (BT 1.0-3.0) or Bluetooth LE / Smart) to the verification unit 35 of the security to be secured Object 30 (eg a
  • Example 5 1. The verification unit 35 of the object 30 to be protected loads the
  • Authorization over the channel 300 preferably directly (e.g., over the Internet, general wireless links such as 866MHz, SMS, GSM, or other such unsafe channel as mentioned above) from the TrustCenter 10.
  • the entitlement bearer 40 and / or the verification unit 35 must preferably be made known to the trust center 10 in order to enable the authentication. This is preferably done before
  • Advertising can include the following:
  • the verification unit receives the public key of the Trust Center, which it should trust, before the start of the assignment. This usually happens during production or during commissioning by means of a configuration tool.
  • the verification unit must be available to the TrustCenter at the latest when creating an authorization, so that it can be entered in the authorization.
  • Offline devices with asynchronous connection without direct internet connection o NFC card, e.g. Smart card o SmartToken, e.g. Car key, building key, access card, etc. o RFID card o SIM card o Smartwatch
  • the at least one permission discussed herein may include one or more of the following components:
  • each user has a personal loyalty card, namely a smart card 40, which is uniquely assigned to the user.
  • the user books a car directly with his smartphone 20. Shortly before the booking starts, the user receives on the one hand, the digital authorization and the position of the vehicle 30 on his smartphone 20 that are suitable for the time of booking.
  • the user goes to the vehicle 30, which is located in the car rental garage, and opens it with the smartphone 20 by means of, for example, the data channel BLE (FIG. "Bluetooth Low Energy") or
  • Smartphone 20 the authorization to start the vehicle 30 on the
  • Verification unit 35 transmitted, the authorization of the smart card 40 is assigned.
  • the user places the smart card 40 on a reader 35 in the vehicle 30 and the authorization is transferred to the smart card 40.
  • the smartcard 40 can be authenticated by the vehicle 30 or the verification unit 35 and the
  • the vehicle 30 can then be started.
  • the smartcard 40 may also undertake the localization (Thatchem) and / or the certification (e.g., CC EAL 5+).
  • the use of a smart card from a reputable manufacturer such as e.g. G & D also has the advantage that these cards can be purchased in one version on the market, the highest
  • a smart card that uses NFC as a communication channel also solves the problem of identifying the vehicle's credentials, as they can only be read in a reader that has a reading area limited to a few centimeters.
  • TrustCenter Trusted entity
  • Transport authorization carrier 30
  • Object to be protected 35
  • Verification unit 40
  • Target authorization carrier Authentication of the target authorization carrier Transmission of the authorization from the transport authorization carrier to the target authorization carrier

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Lock And Its Accessories (AREA)

Abstract

Die vorliegende Erfindung betrifft Verfahren und Systeme zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems. In einer Ausführungsform umfasst ein entsprechendes Verfahren ein Empfangen der zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal (200, 300) an einer Verifizierungseinheit (35) eines zu schützenden Objekts (30), wobei die zumindest eine Berechtigung voneiner vertrauenswürdigen Instanz (10) kryptographisch signiert ist.

Description

Indirekter Berechtigungstransport l. Technisches Gebiet
Die vorliegende Erfindung betrifft Verfahren und Systeme zum sicheren Übertragen von Berechtigungen für Steuerfunktionen eines technischen Systems, wie
beispielsweise eines Fahrzeugs. In bevorzugten Ausführungsformen wird die Sicherheit von SmartCards mit den Vorzügen Internet-fähiger Smartphones vereint, sodass eine Berechtigung für ein zu schützendes Objekt über einen unsicheren Kanal übertragen werden und trotzdem sicher und zuverlässig verwendet werden kann. 2. Technischer Hintergrund
Aus dem Stand der Technik sind Identifikations- und Schließsysteme zur Organisation von Zugangs- und Nutzungsberechtigungen in Verbindung mit technischen Systemen bekannt. Beispielsweise betrifft das Europäische Patent l 910 134 Bi der Anmelderin ein Identifikationssystem zur berechtigungsabhängigen Nutzung eines technischen Systems. Mit einem solchen System können beispielsweise mittels eines Mobiltelefons bzw. Smartphones Steuerfunktionen eines Fahrzeugs ausgelöst werden, sodass das Fahrzeug mit dem Mobiltelefon bzw. Smartphone beispielsweise geöffnet und/oder gestartet werden kann. Mobiltelefone oder vergleichbare elektronische Endgeräte (z.B. Smartphones, PDAs (Personal Digital Assistants) und/oder Tablet-Computer) lassen sich aufgrund ihrer Internet-Konnektivität flexibel mit entsprechenden Berechtigungen ausstatten, wenn diese über eine sichere Verbindung mit derjenigen Instanz verbunden sind, welche die Berechtigungen ausstellt. Dies funktioniert jedoch nur, wenn tatsächlich auch eine Internetverbindung besteht, was gerade bei Anwendungsfällen wie einer Autovermietung nicht immer der Fall ist, beispielsweise wenn das Fahrzeug sich in einer Tiefgarage befindet.
Andere aus dem Stand der Technik bekannte Identifikations- und Schließsysteme setzen anstatt von Mobiltelefonen oder anderen elektronischen Endgeräten sogenannte Smartcards als„Schlüssel" ein, auf welchen entsprechende Berechtigungen
abgespeichert werden können. In solchen Systemen wird es jedoch bislang als erforderlich angesehen, dass die Smartcard direkt vor Ort bei einer vertrauenswürdigen Instanz (beispielsweise dem Fahrzeugvermieter) mit den Berechtigungen beschrieben wird, was unflexibel und arbeitsintensiv ist. Der vorliegenden Erfindung liegt deshalb das Problem zugrunde, Verfahren und Systeme bereitzustellen, mit dem Berechtigungsträger, beispielsweise Smartcards, sicher und flexibel mit Berechtigungen ausgestattet werden können, sodass die oben im Zusammenhang mit dem Stand der Technik angesprochenen Nachteile zumindest zum Teil überwunden werden.
3. Zusammenfassung der Erfindung
Dieses Problem wird gemäß einem Aspekt der Erfindung durch ein Verfahren zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems gelöst. In der Ausführungsform nach Anspruch l wird die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal an einer
Verifizierungseinheit eines zu schützenden Objekts empfangen. Erfindungsgemäß ist hierbei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz kryptographisch signiert.
Dadurch, dass die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz (auch„TrustCenter" genannt) kryptographisch signiert - und vorzugsweise auch von dieser ausgestellt worden - ist, kann die Berechtigung über einen unsicheren bzw. ungesicherten Kanal übertragen werden und ist trotzdem sicher und zuverlässig verwendbar. Ein ungesicherter Kanal ist eine Kommunikation zwischen zwei Einheiten u ber mindestens eine Schnittstelle, bei der auf dem U bertragungsweg nicht sichergestellt werden kann, dass ein Datenpaket von Unberechtigten ausgelesen oder vera ndert werden kann. Bei einem solchen unsicheren Kanal kann es sich
beispielsweise um das Internet, eine SMS, einen QR-Code, GSM, BTLE, Zigbee, allgemeine Funkstrecken wie z.B. 866 MHz, einen Transportkanal über einen
Berechtigungsträger, oder ähnliches handeln. Denn durch die, vorzugsweise digitale, Signatur sichert das TrustCenter den Umfang und den Inhalt der Berechtigung kryptographisch ab, was vom Empfänger überprüft werden kann. Unter einer digitale Signatur ist ein asymmetrisches Kryptosystem zu verstehen, bei dem ein Sender mit Hilfe eines geheimen Signaturschlüssels (dem Private Key) zu einer digitalen Nachricht (d. h. hier der zumindest einen Berechtigung) einen Wert berechnet, der ebenfalls digitale Signatur genannt wird. Dieser Wert ermöglicht es jedem, mit Hilfe des öffentlichen Verifikationsschlüssels (dem Public Key) die nichtabstreitbare
Urheberschaft und Integrität der Nachricht (hier der zumindest einen Berechtigung) zu prüfen. Als Signaturverfahren können beispielsweise solche basierend auf
Primfaktorzerlegung, wie z.B. RSA, solche basierend auf diskreten Logarithmen, z.B. El-Gamal, DSA, solche basierend auf elliptischen Kurven, z.B. ECDSA, oder ähnliche zum Einsatz kommen.
Gemäß einem Aspekt der vorliegenden Erfindung kann die zumindest eine
Berechtigung über einen ungesicherten Kommunikationskanal von einem
Transportberechtigungsträger empfangen werden. Der Transportberechtigungsträger kann die zumindest eine Berechtigung zuvor von der vertrauenswürdigen Instanz empfangen haben. Hiermit wird es beispielsweise möglich, die zumindest eine
Berechtigung von der vertrauenswürdigen Instanz (dem TrustCenter) auf ein
Smartphone (welches in diesem Beispiel der Transportberechtigungsträger ist) und dann vom Smartphone auf die Verifizierungseinheit (die sich beispielsweise in einem Fahrzeug als zu schützendes Objekt befinden kann) zu übertragen. Hierdurch wird die Flexibilität des Verfahrens erheblich erhöht, da beliebige herkömmliche elektronische Endgeräte, wie beispielsweise Smartphones, als Transportmedium für die zumindest eine Berechtigung verwendet werden können. Gleichzeitig bleibt die Echtheit der übertragenen zumindest einen Berechtigung dank der oben beschriebenen Signatur gewahrt, obwohl die zumindest eine Berechtigung über einen ungesicherten Kanal (z.B. das internetfähige Smartphone) übertragen wird. Es versteht sich, dass anstatt eines Smartphones jede andere Art von Berechtigungsträger zum Einsatz kommen kann (weitere Beispiele siehe unten) und dass der Begriff„Transport"-Berechtigungsträger lediglich verdeutlichen soll, dass der Berechtigungsträger als Transportmittel für die zumindest eine Berechtigung verwendet wird; dies schließt jedoch nicht aus, dass der Berechtigungsträger nicht auch selbst in der Lage ist, Berechtigungen aktiv zu verwenden.
Alternativ oder zusätzlich kann die zumindest eine Berechtigung über einen
ungesicherten Kommunikationskanal von der vertrauenswürdigen Instanz empfangen werden. Beispielsweise ist es vorstellbar, dass die Verifizierungseinheit (beispielsweise im Fahrzeug) die zumindest eine Berechtigung direkt, z.B. über eine
Internetverbindung, vom TrustCenter abholt.
Vorzugsweise wird ferner die zumindest eine Berechtigung von der
Verifizierungseinheit auf einen Zielberechtigungsträger über einen zweiten,
vorzugsweise ungesicherten, Kommunikationskanal übertragen. Hierdurch wird es ermöglicht, dass die zumindest eine Berechtigung, welche die Verifizierungseinheit ggf. von dem oben erläuterten Transportberechtigungsträger, z.B. ein Smartphone, erhalten hat, auf einen weiteren Berechtigungsträger, beispielsweise eine Smartcard, übermittelt wird. Dieser erfindungsgemäße Aspekt trägt der Forderung mancher
Automobilhersteller Rechnung, wonach ein Smartphone zwar zum Entriegeln der Fahrzeugtüren eingesetzt werden kann, nicht jedoch zum Starten des Fahrzeugs, was in diesem Beispiel mittels der Berechtigung auf der Smartcard erfolgt. In diesem Aspekt, d.h. der Übertragung von zumindest einer Berechtigung auf beliebige
Berechtigungsträger über einen ungesicherten Kommunikationskanal, zeigt sich die signifikante Flexibilitätssteigerung des erfindungsgemäßen Verfahrens, welches dank der Signatur der zumindest einen Berechtigung trotzdem höchsten
Sicherheitsstandards genügt. Die vorliegende Erfindung ermöglicht außerdem auch eine direkte Übermittlung zumindest einer Berechtigung von einem Transportberechtigungsträger auf einen Zielberechtigungsträger. Hierzu wird ein Verfahren zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems bereitgestellt, in welchem die zumindest eine Berechtigung von einem Transportberechtigungsträger über einen dritten, vorzugsweise ungesicherten, Kommunikationskanal an einem Zielberechtigungsträger empfangen wird. Um auch hier die Echtheit der zumindest einen Berechtigung zu garantieren, ist diese von einer vertrauenswürdigen Instanz kryptographisch signiert.
Wie weiter oben bereits erläutert wurde, kann die zumindest eine Berechtigung an dem Transportberechtigungsträger von der vertrauenswürdigen Instanz über einen, bevorzugt ungesicherten, vierten Kommunikationskanal empfangen werden. Ferner wird es wie ebenfalls weiter oben beschrieben wurde, möglich dass die zumindest eine Berechtigung auf ihre Echtheit und ihren Ursprung in der vertrauenswürdigen Instanz überprüft wird, was vorzugsweise von der Verifizierungseinheit des zu schützenden Objekts durchgeführt wird.
Ferner kann das Verfahren den weiteren Schritt des Authentisierens des
Zielberechtigungsträgers gegenüber der Verifizierungseinheit aufweisen. Somit kann der Zielberechtigungsträger (beispielsweise eine Smartcard) seine Identität gegenüber der Verifizierungseinheit eindeutig nachweisen. Auch der
Transportberechtigungsträger kann eine Authentifizierungseinheit aufweisen, um sich gegenüber der Verifizierungseinheit zu authentisieren. Dabei kann der
Transportberechtigungsträger eine geringer starke Authentifizierungseinheit als der Zielberechtigungsträger aufweisen. Vorzugsweise ist die zumindest eine Berechtigung einem oder mehreren
Berechtigungsträgern, beispielsweise zumindest dem Zielberechtigungsträger, zugeordnet. Somit können bestimmte Zielberechtigungsträger mit Berechtigungen für bestimmte Steuerungsfunktionen (z.B. Deaktivieren der Wegfahrsperre eines
Fahrzeugs, Entriegeln eines Fahrzeugs, Verriegeln eines Fahrzeugs, Freigeben der vollen Fahrzeugleistung, Buchung beginnen, Buchung beenden, Freischalten von Zusatzfunktionen wie z.B. Navigationsgerät oder Sitzheizung, oder ähnliches) ausgestattet werden.
Die hier genannten Berechtigungsträger, d.h. der Transportberechtigungsträger und/oder der Zielberechtigungsträger kann ein Internet-fähiger Berechtigungsträger, ein Mobiltelefon, ein Smartphone, ein PDA, ein Tablet-Computer, eine Smartwatch, eine Smartcard, eine NFC-Karte, ein Smart Token, ein Fahrzeugschlüssel, eine RFID- Karte und/oder eine SIM-Karte sein.
Die zumindest eine Berechtigung ist bevorzugt ein Zertifikat, besonders bevorzugt ein digitales Zertifikat, beispielsweise ein Public-Key-Zertifikat nach dem Standard X.509, oder auch ein anderes proprietäres Zertifikatsystem. Die zumindest eine Berechtigung kann eine oder mehrere der folgenden Limitierungen aufweisen: eine zeitliche
Limitierung, eine funktionale Limitierung, eine Kanallimitierung, eine Limitierung auf einen oder mehrere Berechtigungsträger und/oder Berechtigungsträgergruppen, eine Limitierung auf ein oder mehrere zu schützende Objekte, eine örtliche Limitierung und/oder eine personenbezogene Limitierung.
In einem weiteren Aspekt der vorliegenden Erfindung können ein oder mehrere Transportberechtigungsträger (20) dafür verwendet werden, die Berechtigung (bzw. Auch mehrere Berechtigungen) an ein Ziel (d.h. vorzugsweise einen
Zielberechtigungsträger (40) oder eine Verifikationseinheit (35)) zu übermitteln, solange bis das Ziel dies dem Sender (10) (d.h. vorzugsweise einer vertrauenswürdigen Instanz), bestätigt. Hierdurch wird der Absender, d.h. im allgemeinen das TrustCenter, darüber informiert, dass die Berechtigung am Ziel angekommen ist, sogar wenn die Berechtigung hierzu über eine Kette von Berechtigungsträgern wandert. Es versteht sich, dass weitere Aspekte der vorliegenden Erfindung eine solche Kette von
Berechtigungsträgern auch ohne die oben genannte Bestätigung vorsehen können.
Die vorliegende Erfindung betrifft ferner ein Computerprogramm, aufweisend
Anweisungen zum Implementieren eines der oben erläuterten Verfahren. Außerdem wird ein System zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems bereitgestellt, wobei das System eine Verifizierungseinheit eines zu schützenden Objekts aufweist, die geeignet ist zum Empfangen der zumindest einen Berechtigung über einen ungesicherten
Kommunikationskanal, wobei die zumindest eine Berechtigung von einer
vertrauenswürdigen Instanz kryptographisch signiert ist. Ferner wird ein System zum Übertragen zumindest einer Berechtigung für eine Steuerfunktion eines technischen Systems bereitgestellt, wobei das System einen Zielberechtigungsträger aufweist, der geeignet ist zum Empfangen der zumindest einen Berechtigung über einen dritten Kommunikationskanal von einem Transportberechtigungsträger, wobei die zumindest eine Berechtigung von einer vertrauenswürdigen Instanz kryptographisch signiert ist. Im Übrigen können Ausführungsformen der oben erläuterten Systeme eingerichtet sein, um alle oder zumindest einige der weiter oben erläuterten Verfahren
durchzuführen. Weitere vorteilhafte Ausgestaltungen der erfindungsgemäßen Systeme sind in den abhängigen Patentansprüchen angegeben.
4. Figurenbeschreibung
Im Folgenden wird die Erfindung unter Bezugnahme auf die beiliegenden Figuren näher beschrieben. Es zeigen:
Fig. 1: Ein schematisches Blockdiagramm, welches das Zusammenspiel verschiedener Komponenten gemäß Ausführungsformen der Erfindung illustriert; und
Fig. 2: Eine beispielhafte Berechtigung im XML-Format gemäß Ausführungsformen der Erfindung (sogenanntes„BluelD Ticket").
5. Beschreibung bevorzugter Ausführungsbeispiele
Bevorzugte Ausführungsformen der vorliegenden Erfindung stellen computer- implementierte Verfahren und Systeme bereit, welche die Sicherheit von Smartcards mit den Vorzügen Internet-fähiger Smartphones vereinen. Hierbei kann zumindest eine Berechtigung für ein zu schützendes Objekt über einen unsicheren Kanal auf einen Berechtigungsträger übertragen und trotzdem sicher und zuverlässig verwendet werden. Nachfolgend wird der Einfachheit halber der Begriff„Berechtigung" sowohl im Singular als auch im Plural verwendet, es versteht sich jedoch, dass die vorliegende Erfindung auf eine beliebige Anzahl von Berechtigungen anwendbar ist. Erfindungsgemäße Systeme umfassen dabei je nach Ausführungsform zumindest eine Teilmenge der nachfolgend mit Verweis auf Fig. l erläuterten Komponenten:
Eine vertrauenswürdige Instanz 10 (auch„TrustCenter" genannt), welche geeignet ist, eine oder mehrere Berechtigungen zu erstellen und zu signieren.
Ein TrustCenter ist allgemein ein Dienst, dem alle Parteien vertrauen und der in der Lage ist, Berechtigungen auszustellen und dann zu signieren. Er kümmert sich darum, dass nur der Berechtigte Berechtigungen ausstellen kann und dass die zur Ausstellung der Berechtigung notwendigen Geheimnisse sicher verwahrt und verwendet werden. Idealerweise, aber nicht zwingend, ist ein TrustCenter an das Internet angeschlossen, damit die Berechtigungen einfach und schnell verteilt werden können. Da dies allerdings ein Sicherheitsrisiko darstellt, sollte das TrustCenter bevorzugt mehrere Schichten aufweisen, um somit einen besseren Schutz und notfalls eine bessere Mitigation bei Angriffen zu erreichen. Dabei hat die äußerste Schicht typischerweise die Aufgabe, Angriffe abzuwehren und die innere(n) Schicht(en) zu schützen. Eine zweite Schicht ist
typischerweise für die Verwaltung und Ausstellung von Berechtigungen und/oder die Überprüfung der Erlaubnis zur Erstellung von Berechtigungen zuständig. Eine dritte Schicht übernimmt typischerweise die Signierung der Berechtigungen. Optimaler Weise ist noch eine vierte Schicht vorgesehen, die der sicheren Abspeicherung der kryptographischen Geheimnisse dient. Hierzu wird häufig ein sogenanntes Hardware Secure Element verwendet, welches allerdings auch in der dritten Schicht integriert sein kann.
Ein TrustCenter kann an verschiedenen Stellen im Gesamtsystem angeordnet werden. Idealerweise ist der Aufstellort gegen unberechtigten Zugriff (digital wie auch physikalisch) geschützt, wird überwacht um Manipulation zu erkennen und hat eine hohe Verfügbarkeit für das Abrufen von erstellten Berechtigungen. Zumeist wird dies in einem besonderen Bereich eines
Rechenzentrums der Fall sein. Es wird allerdings auch häufig ein Aufstellort im Arbeitsraum des Wachmanns gewählt. Somit ist das Sicherheitsniveau niedrig.
Betrieben werden kann ein TrustCenter beispielsweise als CloudService für eine Mehrzahl von Nutzern durch eine vertrauenswürdige Instanz, wie z.B. das Unternehmen der Anmelderin, oder auch lokal durch die IT- Abteilung des jeweiligen Unternehmens. Zumindest ein zu schützendes Objekt 30 (auch„secured Object" genannt), welches durch das erfindungsgemäße Berechtigungssystem verwaltet wird.
Hierbei kann es sich beispielsweise um Fahrzeuge (z.B. KFZ, LKW,
Nutzfahrzeuge), elektrische und/oder elektronische Maschinen (z.B.
Waschanlage für das Auto, Aufzüge), Schlösser (z.B. elektronisches
Zylinderschloss, elektronischer Beschlag, elektronischer Türöffner), Schranken und/oder Tore, Schiebetüren und/oder Drehtüren, oder ähnliches handeln.
Eine oder mehrere Berechtigungen, welche vorzugsweise einem oder mehreren definierten Berechtigungsträgern zugeordnet sind. Eine Berechtigung kann beispielsweise im XML-Format definiert werden.
Im Ausführungsbeispiel nach Fig. 2 wird beispielsweise die Signatur, die im Feld permission->signature abgespeichert ist, über alle Nutzdaten zwischen den permission-Tags gebildet. Somit kann eine Verifizierungseinheit die Echtheit überprüfen.
Ein oder mehrere Berechtigungsträger 20, 40, welche geeignet sind, eine oder mehrere (signierte) Berechtigungen zu speichern. Ein Berechtigungsträger 20, 40 kann eine Authentifizierungseinheit aufweisen, welche geeignet ist, sich gegenüber der Verifizierungseinheit 35 (siehe unten) kryptographisch zu authentisieren. Ein solcher Berechtigungsträger 20, 40 ist somit zum Transport und zur Speicherung bzw. Nutzung zumindest einer Berechtigung geeignet (z.B. eine Smartcard oder ein Smartphone). Berechtigungsträger 20, 40 ohne Authentifizierungseinheit können sich nicht authentisieren und stellen somit keine vollwertigen Schlüssel dar; sie dienen lediglich zum Transport zumindest einer Berechtigung (z.B. ein USB-Stick).
Eine Verifizierungseinheit 35 im zu schützenden Objekt 30 (oder mit dem schützenden Objekt 30 verbunden), welche geeignet ist, zu prüfen ob die zumindest eine Berechtigung korrekt und unverändert vom TrustCenter 10 stammt und/oder ob der Berechtigungsträger 20, 40 der ist, für den er sich ausgibt (Authentifizierung).
Die Verifizierungseinheit ist vorzugsweise ein abgeschlossenes System, das gegen Manipulation geschützt ist. Es kann einen Prozessor aufweisen, der geeignet ist um die Kommunikation mit dem Berechtigungsträger zu steuern und/oder die Verifikation der Berechtigung durchzuführen. Bei einem Fahrzeug ist dies häufig das BCM (Body Control Module). Bei besonders kleinen und stromverbrauchsorientierten Implementierungen, wie beispielsweise elektronischen Schließzylindern, wird dies häufig direkt in der
Kommunikationseinheit, also z.B. dem BluetoothLE-Chip durchgeführt.
Ein besonderer Vorteil der vorliegenden Erfindung ist es, dass ein nicht mit dem Internet verbundener Berechtigungsträger 40 für das Ausführen, Veranlassen bzw. Auslösen einer Steuerungsfunktion eines technischen Systems 30 berechtigt werden kann, ohne dass hierfür die zumindest eine Berechtigung mit dem Berechtigungsträger 40 am TrustCenter 10 abgeholt werden muss. Dies wird dadurch erzielt, dass die
Berechtigung und die Authentifizierung voneinander getrennt sind. Durch eine digitale Signatur sichert das TrustCenter 10 den Umfang und Inhalt der Berechtigung kryptographisch ab, also welcher Berechtigungsträger 40 was machen darf. Zum Zeitpunkt der Berechtigungserstellung muss die Identität des Zielberechtigungsträgers 40 dem TrustCenter 10 bekannt sein.
Nach der Erstellung der Berechtigung im TrustCenter 10 kann dank der
erfindungsgemäßen Verfahren und Systeme die Berechtigung nicht nur direkt vom TrustCenter 10 auf den Berechtigungsträger 40 heruntergeladen werden, sondern über einen beliebigen unsicheren Kanal (beispielsweise über einen weiteren
Berechtigungsträger 20, einen sogenannten„Transportberechtigungsträger") auf den Zielberechtigungsträger 40 übertragen werden. Trotzdem kann die Berechtigung auf dem Zielberechtigungsträger 40 sicher und zuverlässig genutzt werden.
Zum Ausstatten eines Zielberechtigungsträgers 40 mit einer oder mehreren
Berechtigungen sieht die vorliegende Erfindung verschiedene beispielhafte
Ausführungsformen vor:
Beispiel 1:
1. Das TrustCenter 10 überträgt die Berechtigung über den Kanal 100 (z.B.
Internet, SMS, QR-Code, GSM, online angebundener Kartenleser/ -Schreiber, oder einen anderen wie eingangs genannten unsicheren Kanal) auf den
Transportberechtigungsträger 20 (z.B. ein Smartphone). Optional kann der
Transportberechtigungsträger 20 ebenfalls eine oder mehrere Berechtigungen für das zu sichernde Objekt 30 aufweisen und/oder die übertragene
Berechtigung nutzen. 2. Der Transportberechtigungsträger 20 überträgt die Berechtigung über den Kanal 600 vorzugsweise direkt (z.B. vorzugsweise über NFC, je nach
Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0-3.0) oder Bluetooth LE / Smart) auf den Zielberechtigungsträger 40 (z.B. eine Smartcard).
Besonders vorteilhaft ist hierbei, dass die Berechtigung über einen unsicheren Kanal (z.B. Smartphone) vom TrustCenter 10 auf den Zielberechtigungsträger 40 (z.B.
Smartcard) übertragen werden kann. Insbesondere ist kein physischer Kontakt zwischen Zielberechtigungsträger 20 und TrustCenter 10 nötig. Dieses
Ausführungsbeispiel kann jedoch durch Vorgaben des Transportberechtigungsträgers 20 beschränkt werden (beispielsweise erlauben nicht alle derzeit erhältlichen
Smartphones eine direkte Kommunikationsverbindung mit einer Smartcard).
Beispiel 2:
1. Das TrustCenter 10 überträgt die Berechtigung über den Kanal 100 (z.B.
Internet, SMS, QR-Code, GSM, online angebundener Kartenleser/ -Schreiber, oder einen anderen wie eingangs genannten unsicheren Kanal) auf den
Transportberechtigungsträger 20 (z.B. ein Smartphone). Optional kann der Transportberechtigungsträger 20 ebenfalls eine oder mehrere Berechtigungen für das zu sichernde Objekt 30 aufweisen und/oder die übertragene
Berechtigung nutzen.
2. Der Transportberechtigungsträger 20 überträgt die Berechtigung über den Kanal 200 (z.B. vorzugsweise Bluetooth LE oder classic, NFC, Zigbee, allgemeine Funkstrecken wie z.B. 866 MHz, oder einen anderen wie eingangs genannten unsicheren Kanal) auf die Verifizierungseinheit 35 des zu sichernden Objekts 30 (z.B. ein Fahrzeug).
3. Die Verifizierungseinheit 35 überträgt die Berechtigung über den Kanal 400 (z.B. vorzugsweise NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0-3.0) oder Bluetooth LE / Smart) auf den Zielberechtigungsträger 40 (z.B. eine Smartcard), vorzugsweise sobald dieser mit der Verifizierungseinheit 35 kommuniziert.
Auch hier kann die Berechtigung über einen unsicheren Kanal (z.B. Smartphone) vom TrustCenter 10 auf den Zielberechtigungsträger 40 (z.B. Smartcard) übertragen werden. Anschließend kann die Verifizierungseinheit 35 eingerichtet sein, um die Berechtigung wieder aus ihrem Speicher zu löschen. Dies kann insbesondere im Kontext von Autovermietungen vorteilhaft sein, bei denen die Verifizierungseinheit eines gegebenen Fahrzeugs binnen kurzer Zeit mit einer Vielzahl von Berechtigungen (für die verschiedenen Kunden) beladen wird, was zu Speicherengpässen führen könnte. Ferner fordern manche Automobilhersteller, dass eine Berechtigung niemals im Fahrzeug verbleiben darf, was ebenfalls durch dieses Ausführungsbeispiel adressiert wird.
Beispiel 3: 1. Die Verifizierungseinheit 35 des zu schützenden Objekts 30 lädt die
Berechtigung über den Kanal 300 vorzugsweise direkt (z.B. über Internet, allgemeine Funkstrecken wie z.B. 866 MHz, SMS, GSM, oder einen anderen wie eingangs genannten unsicheren Kanal) vom TrustCenter 10 herunter.
2. Die Verifizierungseinheit 35 überträgt die Berechtigung über den Kanal 400 (z.B. vorzugsweise NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0-3.0) oder Bluetooth LE / Smart) auf den Zielberechtigungsträger 40 (z.B. eine Smartcard), vorzugsweise sobald dieser mit der Verifizierungseinheit 35 kommuniziert.
Hierbei ist besonders vorteilhaft, dass die Berechtigung ohne zeitintensive Umwege auf den Berechtigungsträger gelangen kann, da die Verifizierungseinheit bevorzugt direkt mit dem Internet verbunden ist. Zudem kann die Zustellung einer Berechtigung einfach nachvollzogen werden. Ein möglicher Nachteil ist hier, dass eine Onlineanbindung notwendig ist. Sobald z.B. in einer Tiefgarage keine Internetverbindung bei einem z.B. Fahrzeug vorhanden ist, kann keine neue Berechtigung aufgespielt werden. Hier muss dann ein alternativer Kanal benutzt werden, da das Fahrzeug ja nicht ohne
Berechtigung aus der Tiefgarage kommt.
Sobald die Berechtigung auf den Zielberechtigungsträger 40 übertragen wurde, kann diese entsprechend benutzt werden. Um zu überprüfen, ob ein Berechtigungsträger eine Aktion durchführen darf, werden in bevorzugten Ausführungsformen zwei Schritte durchgeführt:
1. Die Berechtigung wird von der Verifizierungseinheit geladen (z.B. aus einem lokalen Speicher oder vom Berechtigungsträger) und wird von der Verifizierungseinheit überprüft. Dabei wird bevorzugt zunächst ein Hash über den Inhalt erstellt und dann die Signatur mittels Public-Key des ausstellenden TrustCenters verifiziert. Nun wird der Inhalt analysiert. Wenn die Berechtigung für die Verifizierungseinheit bestimmt ist und die weiteren Limitierungen eintreffen, wird die Identität des dazugehörigen Berechtigungsträgers aus der
Berechtigung ausgelesen.
2. Nun kann die Identität des Berechtigungsträgers überprüft werden. Hierzu wird vorzugsweise überprüft, ob in dem Berechtigungsträger ein bestimmtes Geheimnis vorhanden ist. Die dazu nötigen Überprüfungsdaten lassen sich aus der Indentitätsbeschreibung des Berechtigungsträgers herleiten. Üblicherweise wird dazu eine Zufallszahl an den Berechtigungsträger gesandt und dessen Antwort kryptographisch über den Public-Key des Berechtigungsträgers aus der Berechtigung verifiziert. Wenn der Berechtigungsträger zur Berechtigung passt, so wird die Aktion durchgeführt bzw. freigegeben. Ferner erlaubt die vorliegende Erfindung auch Ausführungsformen, in welchen die Berechtigung auf der Verifizierungseinheit 35 verbleibt, d.h. nicht auf den
Zielberechtigungsträger 40 übertragen wird. Die entsprechenden Abläufe sind:
Beispiel 4:
1. Das TrustCenter 10 überträgt die Berechtigung über den Kanal 100 (z.B.
Internet, Internet, allgemeine Funkstrecken wie z.B. 866 MHz, SMS, GSM, oder einen anderen wie eingangs genannten unsicheren Kanal) auf den
Transportberechtigungsträger 20 (z.B. ein Smartphone). Optional kann der Transportberechtigungsträger 20 ebenfalls eine oder mehrere Berechtigungen für das zu sichernde Objekt 30 aufweisen und/oder die übertragene
Berechtigung nutzen.
2. Der Transportberechtigungsträger 20 überträgt die Berechtigung über den Kanal 200 (z.B. vorzugsweise NFC, je nach Berechtigungsträger (z.B. BLE Key Fob) aber auch über Bluetooth classic (BT 1.0-3.0) oder Bluetooth LE / Smart) auf die Verifizierungseinheit 35 des zu sichernden Objekts 30 (z.B. ein
Fahrzeug).
Beispiel 5: 1. Die Verifizierungseinheit 35 des zu schützenden Objekts 30 lädt die
Berechtigung über den Kanal 300 vorzugsweise direkt (z.B. über Internet, allgemeine Funkstrecken wie z.B. 866 MHz, SMS, GSM, oder einen anderen wie eingangs genannten unsicheren Kanal) vom TrustCenter 10 herunter.
Hierdurch können besonders schnelle Verifikationszeiten erreicht werden (siehe den Pfeil 500 in Fig. 1), da die Berechtigung nicht auf den Zielberechtigungsträger 40 übertragen werden muss. Zudem kann eine Vorverifikation der Berechtigung stattfinden. Somit muss die Berechtigung nicht mehr zum Zeitpunkt der Ausführung überprüft werden, sondern kann dann bereits als sicher angesehen werden.
In allen dargestellten Ausführungsformen muss der Berechtigungsträger 40 und/oder die Verifizierungseinheit 35 vorzugsweise am TrustCenter 10 bekannt gemacht werden, um die Authentifizierung zu ermöglichen. Dies geschieht vorzugsweise vor der
Erstellung der zumindest einen Berechtigung durch das TrustCenter 10. Das
Bekanntmachen kann dabei folgendes umfassen:
1. Die Verifizierungseinheit erhält vor Einsatzbeginn den Public-Key des Trust Centers, dem sie vertrauten soll. Dies passiert meist bei der Produktion oder bei der Inbetriebname mittels eines Konfigurationstools.
2. Die Identität der Berechtigungsträger und der Identifier der
Verifikationseinheit muss dem TrustCenter spätestens beim Erstellen einer Berechtigung vorliegen, damit diese in die Berechtigung eingetragen werden können.
Alle hier beschriebenen Ausführungsformen haben gemeinsam, dass die
Berechtigungen vom TrustCenter 10 signiert sind und von der Verifizierungseinheit 35 auf ihre Echtheit und ihren Ursprung im TrustCenter 10 überprüft werden können, sodass die Berechtigungen auch über ungesicherte bzw. unsichere Kanäle vertrieben werden können.
Im Rahmen der vorliegenden Erfindung können unter anderem die folgenden
Berechtigungsträger 20, 40 zum Einsatz kommen:
Internet-verbundene bzw. temporär mit dem Internet verbundene, im
Allgemeinen Internet-fähige Vorrichtungen: o Smartphone o Mobiltelefone mit der Möglichkeit zum Aufspielen von
Anwendungsprogrammen (sogenannten„Apps") o Smartwatch
Offline-Vorrichtungen bzw. Vorrichtungen mit asynchroner Anbindung ohne direkte Internetverbindung: o NFC-Karte, z.B. Smartcard o SmartToken, z.B. Autoschlüssel, Gebäudeschlüssel, Zugangskarte, usw. o RFID-Karte o SIM-Karte o Smartwatch
Die hier erläuterte zumindest eine Berechtigung kann eine oder mehrerer der folgenden Komponenten umfassen:
Zeitliche Limitierung, z.B. Gültigkeitszeitraum
Funktionale Limitierung, z.B. nur Funktion„Öffnen"
Kanalgebundenheit, z.B. nur NFC
Limitierung auf einen oder mehrere Berechtigungsträger oder deren Gruppe
Limitierung auf ein oder mehrere zu schützende Objekte
Örtliche Limitierung, z.B. nur in München oder nur im Umkreis von x Metern von einem bestimmten Ort
Limitierung auf Personen, Personengruppen und/oder Benutzerrollen
Nachfolgend wird ein illustratives Anwendungsbeispiel erläutert, welches die Vorteile der vorliegenden Erfindung verdeutlichen soll:
Bei einer Autovermietung hat jeder Nutzer eine persönliche Kundenkarte, nämlich eine Smartcard 40, welche dem Benutzer eindeutig zugeordnet ist. Der Benutzer bucht ein Auto direkt mit seinem Smartphone 20. Kurz vor Buchungsbeginn erhält der Benutzer zum einen die zeitlich zur Buchung passende digitale Berechtigung und die Position des Fahrzeugs 30 auf sein Smartphone 20. Der Benutzer begibt sich zum Fahrzeug 30, welches sich in der Tiefgarage der Autovermietung befindet, und öffnet dieses mit dem Smartphone 20 mittels z.B. des Datenkanals BLE („Bluetooth Low Energy") bzw.
mittels eines der in den Europäischen Patenten EP 1 910 134 Bi, EP 2 564 583 Bi und EP 2 193 607 Bi der Anmelderin beschriebenen Verfahren und setzt sich hinein. Um die Sicherheit zu erhöhen, kann das Starten des Fahrzeugs 30 nur mit der persönlichen Smartcard 40 erfolgen. Deshalb wurde während des Öffnungsvorgangs vom
Smartphone 20 die Berechtigung zum Starten des Fahrzeugs 30 auf dessen
Verifizierungseinheit 35 übertragen, wobei die Berechtigung der Smartcard 40 zugeordnet ist. Der Benutzer legt die Smartcard 40 auf einen Leser 35 im Fahrzeug 30 und die Berechtigung wird auf die Smartcard 40 übertragen. Nun kann die Smartcard 40 vom Fahrzeug 30 bzw. der Verifizierungseinheit 35 authentifiziert und die
Berechtigung verifiziert werden. Das Fahrzeug 30 kann anschließend gestartet werden.
Ferner kann die Smartcard 40 auch die Lokalisierung (Thatchem) und/oder die Zertifizierung (z.B. CC EAL 5+) übernehmen. Die Verwendung einer SmartCard von einem renomierten Hersteller wie z.B. G&D bringt zudem den Vorteil, dass diese Karten in einer Ausführung am Markt erworben werden können, die höchsten
Anforderungen an Identitätsträger genügt. Dies ist z.B. eine Zertifizierung nach Common Criteria (z.B. EAL 5+). Eine SmartCard, die NFC als Kommunikationskanal verwendet, löst zudem das Problem der Erkennung des Berechtigungsträgers im Fahrzeug, da diese nur in einem Leser gelesen werden können, der einen auf wenige Zentimeter beschränkten Lesebereich hat.
Bezugszeichenliste:
10 Vertrauenswürdige Instanz („TrustCenter") 20 Transportberechtigungsträger 30 Zu schützendes Objekt 35 Verifizierungseinheit 40 Zielberechtigungsträger
100 Übertragung der Berechtigung vom TrustCenter auf den
Transportberechtigungsträger Übertragung der Berechtigung vom Transportberechtigungsträger auf die Verifizierungseinheit Übertragung der Berechtigung vom TrustCenter auf die Verifizierungseinheit Übertragung der Berechtigung von der Verifizierungseinheit auf den
Zielberechtigungsträger Authentifizierung des Zielberechtigungsträgers Übertragung der Berechtigung vom Transportberechtigungsträger auf den Zielberechtigungsträger

Claims

Ansprüche
1. Ein Verfahren zum Übertragen zumindest einer Berechtigung für eine
Steuerfunktion eines technischen Systems, wobei das Verfahren die folgenden Schritte aufweist: a. Empfangen der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200, 300) an einer Verifizierungseinheit (35) eines zu schützenden Objekts (30); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen
Instanz (10) kryptographisch signiert ist.
2. Das Verfahren nach Anspruch 1, wobei die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal (200) von einem
Transportberechtigungsträger (20) empfangen wird.
3. Das Verfahren nach Anspruch 1, wobei die zumindest eine Berechtigung über einen ungesicherten Kommunikationskanal (300) von der vertrauenswürdigen Instanz (10) empfangen wird.
4. Das Verfahren nach einem der vorstehenden Ansprüche, ferner aufweisend:
Übertragen der zumindest einen Berechtigung von der Verifizierungseinheit (35) auf einen Zielberechtigungsträger (40) über einen zweiten Kommunikationskanal (400).
5. Ein Verfahren zum Übertragen zumindest einer Berechtigung für eine
Steuerfunktion eines technischen Systems, wobei das Verfahren die folgenden Schritte aufweist: a. Empfangen der zumindest einen Berechtigung über einen dritten
Kommunikationskanal (600) an einem Zielberechtigungsträger (40) von einem Transportberechtigungsträger (20); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen
Instanz (10) kryptographisch signiert ist.
6. Das Verfahren nach einem der vorstehenden Ansprüche 2, 4 oder 5, ferner aufweisend:
Empfangen der zumindest einen Berechtigung an dem
Transportberechtigungsträger (20) von der vertrauenswürdigen Instanz (10) über einen vierten Kommunikationskanal (100).
7. Das Verfahren nach einem der vorstehenden Ansprüche, ferner aufweisend:
Überprüfen der zumindest einen Berechtigung auf ihre Echtheit und ihren Ursprung in der vertrauenswürdigen Instanz (10).
8. Das Verfahren nach einem der vorstehenden Ansprüche 4-7, ferner aufweisend: Authentisieren (500) des Zielberechtigungsträgers (40) gegenüber der
Verifizierungseinheit (35) in der Verifizierungseinheit (35).
9. Das Verfahren nach einem der vorstehenden Ansprüche 2 oder 5-8, wobei der Transportberechtigungsträger (20) eine Authentifizierungseinheit aufweist, um sich gegenüber der Verifizierungseinheit (35) authentisieren zu können.
10. Das Verfahren nach Anspruch 9, wobei der Transportberechtigungsträger (20) eine geringer starke Authentifizierungseinheit als der Zielberechtigungsträger (40) aufweist.
11. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die zumindest eine Berechtigung einem Berechtigungsträger (20, 40) oder mehreren
Berechtigungsträgern (20, 40) zugeordnet ist.
12. Das Verfahren nach einem der vorstehenden Ansprüche, wobei der
Transportberechtigungsträger (20) und/oder der Zielberechtigungsträger (40) ein Internet-fähiger Berechtigungsträger, ein Mobiltelefon, ein Smartphone, ein Tablet-Computer, eine Smartwatch, eine Smartcard, eine NFC-Karte, ein Smart Token, ein Fahrzeugschlüssel, eine RFID-Karte und/oder eine SIM-Karte ist.
13· Das Verfahren nach einem der vorstehenden Ansprüche, wobei die zumindest eine Berechtigung ein Zertifikat ist.
14. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die zumindest eine Berechtigung eine oder mehrere der folgenden Limitierungen aufweist: eine zeitliche Limitierung, eine funktionale Limitierung, eine Kanallimitierung, eine Limitierung auf einen oder mehrere Berechtigungsträger und/oder
Berechtigungsträgergruppen, eine Limitierung auf ein oder mehrere zu schützende Objekte, eine örtliche Limitierung und/oder eine personenbezogene Limitierung.
15. Das Verfahren nach einem der vorstehenden Ansprüche, wobei ein oder mehrere Transportberechtigungsträger (20) dafür verwendet werden, die Berechtigung an ein Ziel, vorzugsweise einen Zielberechtigungsträger (40) oder eine
Verifikationseinheit (35) zu übermitteln, solange bis das Ziel dies dem Sender (10), vorzugsweise einer vertrauenswürdigen Instanz, bestätigt.
16. Ein Computerprogramm, aufweisend Anweisungen zum Implementieren eines Verfahrens nach einem der vorstehenden Ansprüche 1-15.
17. Ein System zum Übertragen zumindest einer Berechtigung für eine
Steuerfunktion eines technischen Systems, wobei das System aufweist: a. eine Verifizierungseinheit (35) eines zu schützenden Objekts (30), die geeignet ist zum Empfangen der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200, 300); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen
Instanz (10) kryptographisch signiert ist.
18. Das System nach Anspruch 17, ferner aufweisend: einen Transportberechtigungsträger (20), der geeignet ist zum Senden der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (200) an die Verifizierungseinheit (35).
19. Das System nach Anspruch 15, ferner aufweisend: die vertrauenswürdige Instanz (10), die geeignet ist zum Senden der zumindest einen Berechtigung über einen ungesicherten Kommunikationskanal (300) an die Verifizierungseinheit (35).
20. Das System nach einem der vorstehenden Ansprüche 17-19, ferner aufweisend: einen Zielberechtigungsträger (40), der geeignet ist zum Empfangen der zumindest einen Berechtigung von der Verifizierungseinheit (35) über einen zweiten Kommunikationskanal (400).
21. Ein System zum Übertragen zumindest einer Berechtigung für eine
Steuerfunktion eines technischen Systems, wobei das System aufweist: a. einen Zielberechtigungsträger (40), der geeignet ist zum Empfangen der zumindest einen Berechtigung über einen dritten Kommunikationskanal (600) von einem Transportberechtigungsträger (20); b. wobei die zumindest eine Berechtigung von einer vertrauenswürdigen
Instanz (10) kryptographisch signiert ist.
EP16748087.0A 2015-08-31 2016-07-27 Indirekter berechtigungstransport Withdrawn EP3345364A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015216630.9A DE102015216630A1 (de) 2015-08-31 2015-08-31 Indirekter Berechtigungstransport
PCT/EP2016/067909 WO2017036686A1 (de) 2015-08-31 2016-07-27 Indirekter berechtigungstransport

Publications (1)

Publication Number Publication Date
EP3345364A1 true EP3345364A1 (de) 2018-07-11

Family

ID=56611237

Family Applications (1)

Application Number Title Priority Date Filing Date
EP16748087.0A Withdrawn EP3345364A1 (de) 2015-08-31 2016-07-27 Indirekter berechtigungstransport

Country Status (4)

Country Link
US (1) US20190028487A1 (de)
EP (1) EP3345364A1 (de)
DE (1) DE102015216630A1 (de)
WO (1) WO2017036686A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102445514B1 (ko) * 2017-10-26 2022-09-21 현대자동차주식회사 차량 및 차량 시스템
EP3732843A1 (de) * 2017-12-28 2020-11-04 BlueID GmbH Systeme und verfahren zur bereitstellung von authentifizierung und / oder autorisierung
BR112022004889A2 (pt) * 2019-09-17 2022-09-27 Cezar Carvalho Nilton Sistema de gerenciamento remoto aplicado em fechaduras eletrônicas com controle de acesso via dispositivo móvel

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090183541A1 (en) * 2006-04-28 2009-07-23 Babak Sadighi Access Control System and Method for Operating Said System
DE102011083820A1 (de) * 2011-09-30 2013-04-04 Ford Global Technologies, Llc Verfahren zur Kontrolle des Zugangs zu einem Kraftfahrzeug sowie Steuerungseinrichtung

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005033913A1 (de) * 2003-09-30 2005-04-14 Siemens Aktiengesellschaft Einräumung eines zugriffs auf ein computerbasiertes objekt
DE102005031376B3 (de) * 2005-07-05 2007-03-29 Siemens Ag Steuermodul und Verfahren zum Betreiben eines Kraftfahrzeugs
WO2007009453A2 (de) 2005-07-19 2007-01-25 Baimos Technologies Gmbh Identifikations- und/oder schliesssystem zur identifikation und/oder freigabe eines technischen systems und verfahren zu seinem betrieb
ATE551782T1 (de) 2007-08-15 2012-04-15 Baimos Technologies Gmbh Verfahren und system zum lokalisieren des absenders eines frequenzsprung-funksignals
ES2539253T3 (es) * 2010-04-28 2015-06-29 Baimos Technologies Gmbh Dispositivo, sistema y procedimiento para la identificación de un campo magnético generado artificialmente sobre un teléfono móvil
US9466162B2 (en) * 2011-11-22 2016-10-11 Mitsubishi Electric Coporation Electronic key system, and lock-side terminal and portable terminal employed in same
CN104115464B (zh) * 2012-02-22 2017-09-29 诺基亚通信公司 控制访问
DE102013225106A1 (de) * 2013-12-06 2015-06-11 Bundesdruckerei Gmbh Zugangs- und Nutzungskontrolle für ein Kraftfahrzeug

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090183541A1 (en) * 2006-04-28 2009-07-23 Babak Sadighi Access Control System and Method for Operating Said System
DE102011083820A1 (de) * 2011-09-30 2013-04-04 Ford Global Technologies, Llc Verfahren zur Kontrolle des Zugangs zu einem Kraftfahrzeug sowie Steuerungseinrichtung

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
DE102015216630A1 (de) 2017-03-02
WO2017036686A1 (de) 2017-03-09
US20190028487A1 (en) 2019-01-24

Similar Documents

Publication Publication Date Title
DE102006015212B4 (de) Verfahren zum Schutz eines beweglichen Gutes, insbesondere eines Fahrzeugs, gegen unberechtigte Nutzung
DE102013215303B4 (de) Mobiles elektronisches Gerät und Verfahren
DE102016218986B4 (de) Verfahren zur Zugriffsverwaltung eines Fahrzeugs
AT506344B1 (de) Verfahren und vorrichtung zur steuerung der zutrittskontrolle
EP2777309B1 (de) Verfahren und system zur freigabe einer technischen vorrichtung
EP3078218B1 (de) Zugangs- und nutzungskontrolle eines kraftfahrzeugs
EP3256977A1 (de) Computerimplementiertes verfahren zur zugriffskontrolle
DE102016220656A1 (de) Bereitstellung und Prüfung der Gültigkeit eines virtuellen Dokuments
EP2864967A1 (de) Vorrichtung und verfahren zum steuern einer zugangsberechtigung und/oder fahrberechtigung für ein fahrzeug
EP3649625B1 (de) Verfahren zur delegation von zugriffsrechten
EP3699791B1 (de) Zugangskontrolle mit einem mobilfunkgerät
DE102016215628B4 (de) Kommunikationssystem zur Verwaltung von Nutzungsrechten an einem Fahrzeug
EP2624223B1 (de) Verfahren und Vorrichtung zur Zutrittskontrolle
DE102014219502A1 (de) System und Verfahren für einen beschränkten Zugang zu einem Fahrzeug
DE102016218071B4 (de) Authentifikationssystem für ein Kraftfahrzeug
WO2017036686A1 (de) Indirekter berechtigungstransport
DE102013100756B3 (de) Verfahren und Vorrichtung zur Authentifizierung eines Nutzers
EP3135546A1 (de) Autoschlüssel, kommunikationssystem sowie verfahren hierzu
DE102014110540A1 (de) Delegierbare Zugriffssteuerung
EP3336736B1 (de) Hilfs-id-token zur multi-faktor-authentifizierung
DE102017215806B3 (de) Sicheres Authentifizierungsverfahren für ein Fahrzeug
DE102017215000B4 (de) Steuerung einer Funktion eines Kraftfahrzeugs
WO2020147875A1 (de) System und verfahren zum verwalten einer berechtigung für ein fahrzeug
EP2797043A2 (de) Durchführung einer Chipkartenfunktion
DE102014211839A1 (de) Verfahren zum Authentifizieren einer Entität

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20180329

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: BA ME

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

Effective date: 20200318

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200729