WO2023217645A1 - Abgesichertes zugriffssystem - Google Patents

Abgesichertes zugriffssystem Download PDF

Info

Publication number
WO2023217645A1
WO2023217645A1 PCT/EP2023/061904 EP2023061904W WO2023217645A1 WO 2023217645 A1 WO2023217645 A1 WO 2023217645A1 EP 2023061904 W EP2023061904 W EP 2023061904W WO 2023217645 A1 WO2023217645 A1 WO 2023217645A1
Authority
WO
WIPO (PCT)
Prior art keywords
mobile device
authentication
server
interface
aut
Prior art date
Application number
PCT/EP2023/061904
Other languages
English (en)
French (fr)
Inventor
Johannes Rietschel
Original Assignee
Barix Ag
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 Barix Ag filed Critical Barix Ag
Publication of WO2023217645A1 publication Critical patent/WO2023217645A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • 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/08—Access security
    • H04W12/084—Access security using delegated authorisation, e.g. open authorisation [OAuth] protocol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/50—Service provisioning or reconfiguring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the present invention relates to a method and a system for secure access to an electrical or electronic device.
  • Cyber attacks on infrastructure are becoming increasingly sophisticated. More and more not only servers, but also LoT (Internet of Things) devices are becoming victims of attacks. Once a hacker has penetrated a device, he can often attack other local targets undetected, send spied data from the network (also encrypted), etc.
  • LoT Internet of Things
  • the local (initial) device configuration of such devices is therefore a very critical aspect. It is often necessary at later times to carry out certain functions on the devices such as reconfigurations, start firmware updates, etc.
  • a common way to perform such functions on devices is through a web server. This is then protected with a password, secure connections (https etc.) in such a way that unauthorized access is prevented if possible.
  • Access passwords if they fall into the wrong hands, can be used at any time to make changes to the device.
  • the devices are often (rightly) prohibited from establishing connections to the Internet. Any access authorization can therefore only be checked locally.
  • WO-A-2021099063 relates to a method for reconfiguring an LoT device, wherein the LoT device can be connected to a cloud backend via a network.
  • the method includes the following preparatory steps: - storing an access code to be entered locally in the cloud backend and - storing the access code or test information formed depending on it on the LoT device.
  • the method further includes the following steps for reconfiguring the LoT device: - querying the access code from the cloud backend, - entering the requested access code a local configuration interface of the loT device or on an input device connected to the local configuration interface of the loT device, - comparing the entered access code with the access code stored on the loT device or the test information formed depending on it and - releasing the loT device for Reconfiguration in the event of a positive comparison of the entered access code with the access code stored on the LoT device or the test information formed depending on it.
  • an implantable device assembly includes an implantable device and an NFC component externally attached to the implantable device.
  • the NFC component is configured to transmit identification information associated with the implantable device to a reader using the N FC protocol. The transmission occurs in response to a received request signal.
  • both devices i.e. the mobile device (MG) and the further device (G) have a common interface for data exchange.
  • Handover of the encrypted challenge from the mobile device via a data connection to the server as an authentication server to which the user of the mobile device is logged in (the login to the authentication server can already have taken place before the communication request to the other device, or can be as part of the handover of the encrypted challenge and is optional);
  • the secure connection for exchanging data between the device and the server using encrypted tunnels can be established through the mobile.
  • the user of the mobile device can then be logged in to the server and communicate with the tunneled device via the server if this is authorized, but the process can also be structured in such a way that there is no direct connection between the user (on his mobile device) and the tunneled device device exists.
  • the big advantage of this method is that essentially all of the security can be done at the time the additional device is set up by storing the corresponding keys on the device and on the authentication server.
  • the corresponding information can also be stored in a public blockchain as a server, together with other data characterizing the device, such as its age, delivery status, version, invoicing, owner, delivery date. Other such parameters are the device controlling or controlling parameters but also the software version, etc.
  • Another major advantage of the proposed method is that no device-specific passwords are required, but only authorization from the user to log in to the authentication server.
  • the proposed method has the advantage that access to the authentication server can be specifically defined by an administrator, namely for specific users, specific devices, specific time windows, etc.
  • the depth of communication can also be specified, for example a specific user can be assigned Only the reading of data can be made possible within a certain time window, but not the changing of the configuration of the device or an update of the software, etc.
  • the data exchange between the further device and the server preferably takes place via the mobile device, and parameters controlling the further device, which are on the are stored on the server, or are placed on the server by the user of the mobile device, are written into the other device (G) by the server via the mobile device.
  • This preferably without direct and/or indirect influence on the part of the user and more preferably while logging the data transmission to the user via a display of the mobile device (MG).
  • the tunnel which is created via the mobile device, can also be created temporarily by someone completely uninvolved (e.g. a school technician who doesn't know the devices at all) via their mobile device so that a 'remote' technician can configure and maintain the device online can;
  • Every change to the device is documented both by who made it and when (on the server) as well as when it was transferred to the device G via a tunnel via a mobile device MG (and optionally, if the user of the mobile device MG has to actively log in, who that was).
  • the device is therefore preferably equipped with an individual “shared secret” during manufacture, which is simultaneously stored in a secure data storage, blockchain, etc., for later use by the portal (authentication server).
  • a counter is preferably initialized in the device at the time of manufacture (e.g. set to 1 as the initial value), and this value is also stored for the portal. This counter is useful for identifying playback attacks, but is not absolutely necessary.
  • standardized certificates can also be used.
  • the "index" for the key information on the server can be an immutable serial number of the device.
  • the authenticity of the mediator is typically checked first (this is usually done using a client certificate, for example). and/or user login).
  • the mediator will then typically request a specific data set from the device, viz
  • This data is preferably sent to the server by the mediator.
  • the server can now use device D to check whether the mediator (user) is authorized to access this device.
  • the device can, if it has the data record (cryptogram K1 , random number C2) from the server, check the authenticity of the server (is the cryptogram K1 calculated correctly) and in turn calculate a cryptohash K2 using the random number C2 transmitted by the server and send it back to the server via Mediator.
  • the device can, if it has the data record (cryptogram K1 , random number C2) from the server, check the authenticity of the server (is the cryptogram K1 calculated correctly) and in turn calculate a cryptohash K2 using the random number C2 transmitted by the server and send it back to the server via Mediator.
  • the server can also check the authenticity of the device using the hash K2 and the server-mediator-device association is authenticated.
  • the mediator will communicate with the server via an encrypted, secured communication interface (e.g. web socket) and the communication between the mediator and the device will take place, for example, via independent encryption or a direct wire connection.
  • an encrypted, secured communication interface e.g. web socket
  • Both sides can preferably also log unauthenticated attempts and use back-off algorithms to prevent brute force attacks.
  • the basic principle is preferably always that both the device (via Mediator) authenticates itself to the server and the server authenticates itself to the device via Mediator without any doubt using cryptographic procedures.
  • the data exchange that follows should preferably take place via a connection encrypted by the mediator, but end-to-end encryption can be set up between the server and the device using known methods using the “shared secret”.
  • the following data is held in the device (preferably at least two of them, particularly preferably all of them):
  • a preferred embodiment of the proposed method is characterized in that the common interface is a wireless interface, preferably a Bluetooth, BLE, WLAN, NFC, RFID, radio connection, or also sound (sound via loudspeaker/microphone, sounds in the audible and/or inaudible range) interface.
  • the common interface is a wireless interface, preferably a Bluetooth, BLE, WLAN, NFC, RFID, radio connection, or also sound (sound via loudspeaker/microphone, sounds in the audible and/or inaudible range) interface.
  • the method is further preferably characterized in that the common interface is a wired interface, preferably a serial interface, a USB interface, Ethernet, CAN bus or other available local interfaces (including I2C).
  • the common interface is a wired interface, preferably a serial interface, a USB interface, Ethernet, CAN bus or other available local interfaces (including I2C).
  • the authentication can contain, in addition to the pure authorization information, information about the scope of the authorization, in particular user information, time information (duration of access, start of access, end of access), permitted depth of intervention.
  • the access authorization in the authentication server it is possible to take into account not only the encrypted challenge, but also additional information about the mobile device, preferably in the form of hardware-specific and individualized information, and/or information about the mobile device and/or user logged in to the authentication server, and/or information from a token of such user.
  • the mobile device is a laptop or a cell phone.
  • the method is further characterized in that, as part of the released data exchange, data is read from the memory of the other device (for example data that was previously recorded by a sensor and logged, for example the contents of an error message memory), an update is loaded onto the device, the device restarts configured, or a combination thereof.
  • the further device typically has at least the interface mentioned, as well as a data processing unit with memory, as well as at least one further functionality, in particular a sensor, an output interface, in particular a display, or a loudspeaker, or a combination of such functionalities.
  • This can be a complex device such as a printer or an industrial robot, but it can also be very simple devices in the sense of LoT devices that, for example, only have one sensor.
  • Private keys for the generation of challenges or authentication and the verification of this encrypted information are typically present on the authentication server and the device, as well as preferably corresponding associated public keys on the other device.
  • the device can also use an incrementing number, and it is also possible to have several keys (on both sides), which are then changed either randomly or after a certain time and/or reaching a certain number.
  • the keys can be stored on a public blockchain, if necessary together with hardware-specific and individualized information about the device.
  • the authentication server can, according to a further preferred embodiment, transmit an authentication to the mobile device, which is either recognized as non-authorization directly on the mobile device and is used to issue a corresponding message to the user mobile device, or the authentication can be transmitted to the other device and a corresponding output can be output on it or such an output can be transmitted back from the other device to the mobile device for output. It may make sense to inform the device of the invalid authentication so that it blocks it for some time after a certain number of attempts, for example.
  • an identifier can also be provided on the further device, preferably in the form of a barcode or a QR code, which can be read by the mobile device, for example by a camera, and for the identification of the further device and for communication with it
  • Authentication server is used by transmitting the corresponding device identifier together with the challenge to the authentication server.
  • the present invention further relates to a system for carrying out a method as described above, wherein the system has at least one authentication server, at least one mobile device and at least one further device preferably has a plurality of further devices, and wherein there is a data connection between the authentication server and the mobile device, and the mobile device and the further device have at least one common interface for data exchange.
  • Data processing software that implements the proposed method is also provided on the various components.
  • the present invention also relates to a data processing program, preferably on a data memory, for carrying out a method as described above, wherein the data processing program on the mobile device communicates with an output interface, preferably in the form of a display of the mobile device, for communication with the user.
  • Fig. 1 shows schematically the step-by-step authentication process on a device.
  • the method proposed here for authenticating a mobile device MG on a local device G is shown schematically in FIG.
  • the prerequisite for the method is that a data structure is stored on an authentication server AS, which makes it possible to verify an encrypted verification information provided by the device G, which is hereinafter referred to as challenge Ch, and can provide an authentication Aut upon verification .
  • the authentication can also contain other information, such as the duration of the released access, the scope of the released access (up to what level of intervention), the amount of released data to be exchanged, Etc.
  • a data structure is stored on the device G, which, on the one hand, makes it possible to provide encrypted verification information, the challenge, after setting up a communication request KA from a mobile device MG. Furthermore, the data structure on the device makes it possible to check an authentication Aut provided by the authentication server and, if positive Verification result to release the device G to the extent of the authentication Aut for communication with the mobile device MG. If the authentication Aut contains, in addition to the actual control of the release of access, also other information such as the duration of the released access, the scope of the released access, etc., the device G releases the communication accordingly.
  • a device G in the sense of the present invention is a device that in any case provides an interface for exchanging information with a mobile device, for example in the form of a wireless communication connection, for example Bluetooth, Bluetooth Low Energy, WLAN (IEEE 802.11), but also in the form of a wired connection, for example in the form of a USB connection, a serial interface.
  • the device also has a data processing unit (CPU) with storage capability that is connected to the interface, as well as at least one further functionality that makes up the actual device, for example a sensor, an output interface (for example loudspeakers, display), but it can may also be a robotic device or similar that performs certain automated tasks.
  • the device G also has a power supply (for example in the form of a battery, a rechargeable battery or a wired power supply).
  • the device G can have a direct or indirect Internet connection, but does not have to be. If such an Internet connection is available, it can be used to transmit data that the device generates or receives to a cloud backend. The data can be transferred to or received from the Internet via a WLAN or a similar connection via a server. However, the device does not have to have such a connection; the method is particularly characterized by the fact that it works without a connection to a cloud backend.
  • the authentication server AS is a cloud backend that can be contacted by the mobile device MG via an Internet connection or a mobile phone connection.
  • the following procedure for releasing access to the device G is now possible, for example if maintenance work or new configurations are to be carried out on the device G.
  • the corresponding person approaches the device G with their mobile device MG, which has a communication interface that corresponds to that on the device G, and sets up a communication connection KA with the device, typically using specially designed authentication software (Fig. 1 a) upper arrow).
  • the device G is now configured so that it does not wait for the corresponding request from the authentication software to enter an access code or something similar, but rather rather, the aforementioned challenge Ch, ie encrypted verification information, is transmitted to the mobile device MG (FIG. 1 a, lower arrow).
  • This challenge Ch is now not verified or processed in the mobile device MG, but is transmitted unchanged to the authentication server AS via a wireless data connection provided in the mobile device MG (FIG. 1 b)). This transmission is only released by the authentication server AS if the corresponding user of the mobile device MG has validly logged on to the authentication server.
  • the authentication server AS determines that the mobile device MG or its users or both are authorized to access the device G, the authentication server transmits an authentication Aut to the mobile device MG (Fig. 1 c)).
  • This authentication Aut is in turn transmitted unchanged by the mobile device via the local interface (Fig. 1 d)).
  • the device G then checks the authentication Aut, and if the check is positive, the communication specified in the scope of the authentication is released (Fig. 1 e)).
  • Time windows can be defined on the authentication server and users and authorized access devices can be defined so that authentication is only effectively issued within the framework of these specifications.
  • the 'secret' required to access the device is, in my opinion, never given to anyone. It is securely on a cloud service AS.
  • a technician or owner of device G must identify themselves to Cloud Service AS using the known procedures (including 2FA).
  • an administrator can also assign time windows for access, for example, so that a technician can only access the device for a certain time.
  • the technician goes on site with his mobile device MG, for example.
  • the device G has no network-side access options 'open'.
  • the technician can connect his cell phone as a mobile device MG to the device using, for example, an app.
  • the device G gives the mobile phone the challenge Ch.
  • the device G checks the response based on an individual key agreed with the Cloud Portal AS and if this is OK, access is released.
  • the employee can then deliver configurations or data available on the cloud to device G, the device can deliver data (encrypted) to the cloud service via the employee's cell phone, a web server can be activated, etc.
  • the cloud server AS is generally and independently of the other features in the exemplary embodiment, in other words and in particular preferably not only an authentication server, but also a general data server, which is used in particular for the central management of the parameters (including software updates, etc.).
  • the device G is provided.
  • the user with his mobile device MG can communicate with the device G directly via his mobile device MG in accordance with the time authorization or local authorization set on the cloud server and, if necessary, also influence the device G and change parameters on this device G.
  • parameters on the device G are not simply changed independently via the mobile device MG on the device G, but rather it is ensured that the current parameterization of the device G is always available and stored on the cloud server AS.
  • parameters changed by the user on the mobile device MG for the device G are first transmitted to the server AS, written into the parameters stored for the device G in its database, and then from the cloud server AS via the mobile device MG to the device G transmitted.
  • the connection establishment between the device G and the mobile device MG with regard to these parameters only serves as an intermediary of a connection between the device G and the cloud server AS in order to enable the control of the device G by the cloud server AS or the adjustment of the parameterization , but not to be controlled intervened.
  • the user's mobile device MG if it is prepared for such actions, with or without further influence from the user, simply when locally present in the vicinity of the device G, the connection with both the device G via the secure protocol as described above builds up, and then the mobile device MG becomes autonomously active as an intermediary for data transmission between the device G and the cloud server AS.
  • the user of the mobile device can then, if necessary, be informed via corresponding output on the display about which actions were carried out and whether such actions were effectively completed (which can be important if the user is out of the connection area or the range of the connection between the mobile device and the device G).
  • the central authentication server or database (cloud server AS), preferably in the form of a blockchain, especially when it comes to the parameters, regulates in other words the authorizations, who is allowed to change the configuration on which device, when, view data and so on (this is done via login of the user on the computer, possibly even with a web browser without a local app etc.
  • it is about the time/location/device-specific authorization to view and change data for the device G, coupled with the possibly same person who happens to be on site and creates the tunnel with their mobile device MG without necessarily being actively involved to be.
  • the tunnel can also be created temporarily by a completely uninvolved person (e.g. a school technician who does not know the devices at all) via his mobile device MG so that a 'remote' technician can configure and maintain the device G online;
  • a completely uninvolved person e.g. a school technician who does not know the devices at all
  • the process can be used universally for different devices that do not need to have an internet connection. It is also suitable, for example, for cars Unlock lost keys, open safes, etc.
  • the basic condition is that the device and the cloud service have exchanged a mutually known but otherwise secret 'secret' at the time of birth of the device, which is needed for authentication, and access to this secret by the cloud service is only possible after an arbitrarily rigid check of the access authorization Cloud system is granted.
  • the access data to the device can, for example, also be stored in a public blockchain to protect them against loss forever - then only the associated key to the encrypted blockchain entries is necessary (which is managed by the cloud portal, for example).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Verfahren zur Freigabe einer Kommunikationsverbindung von einem mobilen Gerät (MG) zu einem weiteren Gerät (G), insbesondere auch für Datentaustausch zwischen dem weiteren Gerät (G) und einem Server (AS), gekennzeichnet durch folgende Schritte in der angegebenen Reihenfolge: Kommunikationsanfrage (KA) durch das mobile Gerät (MG) an das weitere Gerät (G); Übermittlung eines verschlüsselten Challenge (Ch) vom weiteren Gerät (G) an das mobile Gerät (MG); Übergabe des Challenge (Ch) vom mobilen Gerät (MG) über eine Datenverbindung an den Server als Authentifikationsserver (AS) und Überprüfen der Zugriffsberechtigung im Authentifikationsserver (AS), und oder bei fehlender Zugriffsberechtigung Generierung einer verschlüsselten Authentifikation (Aut), deren Inhalt eine fehlende Authentifikation ist, und bei gegebener Zugriffsberechtigung Generierung einer verschlüsselten Authentifikation (Aut) und folgende Schritte in der angegebenen Reihenfolge: Übergabe der verschlüsselten Authentifikation (Aut) vom Authentifikationsserver (AS) an das mobile Gerät (MG); Übermittlung der verschlüsselten Authentifikation (Aut) vom mobilen Gerät (MG) an das Gerät (G); überprüfen der Zugriffsberechtigung im Gerät (G) auf Basis der verschlüsselten Authentifikation (Aut), und bei fehlender Zugriffsberechtigung Ausgabe respektive Übermittlung einer entsprechenden Meldung an das mobile Gerät (MG) bei gegebener Zugriffsberechtigung Freigabe des Datenaustauschs zwischen dem mobilen Gerät (MG) und dem weiteren Gerät (G) und/oder des Datenaustauschs zwischen dem weiteren Gerät (G) und dem Server (AS) über das mobile Gerät (MG) im Umfang der Authentifikation (Aut).

Description

TITEL
ABGESICHERTES ZUGRIFFSSYSTEM
TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft ein Verfahren sowie ein System für den gesicherten Zugriff auf ein elektrisches oder elektronisches Gerät.
STAND DER TECHNIK
Cyberangriffe auf Infrastruktur werden immer ausgeklügelter. Es werden mehr und mehr nicht nur Server, sondern auch loT (Internet of things) Geräte Opfer von Attacken. Ist ein Hacker einmal in ein Gerät eingedrungen, kann er von diesem aus oft unerkannt weitere dann lokale Ziele attackieren, ausspionierte Daten aus dem Netzwerk schicken (auch verschlüsselt) etc.
Die lokale (initiale) Gerätekonfiguration derartiger Geräte ist also ein sehr kritischer Aspekt. Oft ist es auch zu späteren Zeiten nötig, an den Geräten gewisse Funktionen wie z.B. Rekonfigurationen durchzuführen, Firmware Updates zu starten, etc.
Ein üblicher Weg, um solche Funktionen auf Geräten auszuführen, ist ein webserver. Dieser wird dann mit Passwort, secure connections (https etc.) so geschützt, dass ein unberechtigter Zugriff nach Möglichkeit verhindert wird.
Zertifikatsmanagement mit den Geräten ist mühsam, und auch mit verschlüsseltem Zugriff ist es immer noch nötig, sich gegenüber dem Gerät zu authentisieren.
Zugriffspasswörter, wenn in falsche Hände geraten, können jederzeit genutzt werden, um am Gerät Änderungen vorzunehmen.
Oft wird den Geräten (zu Recht) untersagt Verbindungen ins Internet aufzubauen. Eine eventuelle Zugriffsberechtigung kann also nur lokal geprüft werden.
Der Nutzen von Private/Public Key, asymmetrischer Verschlüsselung, ist aufwändig und für loT Devices oft nicht machbar, insbesondere wenn sie keinen online Zugang haben und damit auch die Authentizität eines Server-Zertifikates gar nicht prüfen können.
Die WO-A-2021099063 betrifft ein Verfahren zur Rekonfiguration eines loT-Geräts, wobei das loT-Gerät über ein Netzwerk mit einem Cloud-Backend verbindbar ist. Das Verfahren umfasst die folgenden vorbereitenden Schritte: - Speichern eines lokal einzugebenden Zugangscodes in dem Cloud-Backend und - Speichern des Zugangscodes oder einer davon abhängig gebildeten Prüfinformation auf dem loT-Gerät. Das Verfahren umfasst ferner die folgenden Schritte zum Rekonfigurieren des loT-Geräts: - Abfragen des Zugangscodes von dem Cloud-Backend, - Eingeben des abgefragten Zugangscodes an einer lokalen Konfigurationsschnittstelle des loT-Geräts oder an einem mit der lokalen Konfigurationsschnittstelle des loT-Geräts verbundenen Eingabegerät, - Abgleichen des eingegebenen Zugangscodes mit dem auf dem loT-Gerät gespeicherten Zugangscode bzw. der davon abhängig gebildeten Prüfinformation und - Freigeben des loT-Geräts zur Rekonfiguration bei einem positiven Abgleich des eingegebenen Zugangscodes mit dem auf dem loT-Gerät gespeicherten Zugangscode bzw. der davon abhängig gebildeten Prüfinformation.
LIS2014273824 beschreibt Systeme, Vorrichtungen und Verfahren, die konfiguriert sind, um das Koppeln eines implantierbaren Geräts mit einem entfernten Gerät unter Verwendung eines an dem implantierbaren Gerät angebrachten Nahfeldkommunikations- (NFC-)Geräts zu erleichtern. In einem Aspekt umfasst eine implantierbare Vorrichtungsanordnung eine implantierbare Vorrichtung und eine NFC-Komponente, die extern an der implantierbaren Vorrichtung angebracht ist. Die NFC-Komponente ist dazu konfiguriert, mit dem implantierbaren Gerät verbundene Identifikationsinformationen unter Verwendung des N FC-Protokolls an ein Lesegerät zu übertragen. Die Übertragung erfolgt als Antwort auf ein empfangenes Anforderungssignal.
US2016050565 beschreibt Techniken zum sicheren Bereitstellen eines Client-Geräts. Ein Client-Gerät kann erste Client-Informationen über eine sichere Schnittstelle an ein vertrauenswürdiges Gerät ausgeben, um an einen Authentifizierungsserver übertragen zu werden. Zweite Client-Informationen, die sich auf die ersten Client-Informationen beziehen, können an den Authentifizierungsserver übertragen werden. Der Authentifizierungsserver kann die zweiten Client-Informationen und die ersten Client-Informationen verknüpfen. Das Clientgerät kann einen verschlüsselten Authentifizierungsnachweis von dem Authentifizierungsserver empfangen. Der Authentifizierungsnachweis kann zumindest teilweise basierend auf den ersten Client-Informationen oder den zweiten Client- Informationen verschlüsselt werden. Das Client-Gerät kann den verschlüsselten Authentifizierungsnachweis unter Verwendung der ersten Client-Informationen, der zweiten Client-Informationen oder eines gemeinsamen geheimen Schlüssels entschlüsseln
DARSTELLUNG DER ERFINDUNG
Es ist entsprechend unter anderem Aufgabe der vorliegenden Erfindung eine verbesserte und sichere aber dennoch einfache und zuverlässige Möglichkeit des Zugriffs auf Geräte, insbesondere auf Geräte, die nicht permanent oder gar nicht am Internet sind, bereitzustellen. Der Zugriff soll dabei über ein mobiles Gerät erfolgen oder nur mittels eines mobilen Geräts durch einen Server respektive von einem Server aus. Die Verbindung zwischen dem Gerät und einem Server wird dann mittels eines mobilen Gerätes (Mobiltelefon) vermittelt, das über einen Internetzugang verfügt. Das mobile Gerät selbst braucht ggf. keine Berechtigung, die Kommunikation zwischen Gerät und Server geschieht durch respektive über das mobile Gerät verschlüsselt.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 gelöst.
Konkret geht es um ein Verfahren zur Freigabe einer Kommunikationsverbindung von einem mobilen Gerät zu einem weiteren Gerät insbesondere für Datentaustausch zwischen dem weiteren Gerät (G) und einem Server (AS), wobei beide Geräte, d.h. das mobile Gerät (MG) und das weitere Gerät (G), über eine gemeinsame Schnittstelle für einen Datenaustausch verfügen.
Das Verfahren ist gekennzeichnet durch folgende Schritte in der angegebenen Reihenfolge:
Kommunikationsanfrage durch das mobile Gerät an das weitere Gerät über die Schnittstelle;
Übermittlung eines verschlüsselten Challenge vom weiteren Gerät an das mobile Gerät über die Schnittstelle;
Übergabe des verschlüsselten Challenge vom mobilen Gerät über eine Datenverbindung an den Server als einen Authentifikationsserver, an dem der Benutzer des mobilen Geräts angemeldet ist (die Anmeldung am Authentifikationsserver kann bereits vor der Kommunikationsanfrage an das weitere Gerät erfolgt seien, oder kann im Rahmen der Übergabe des verschlüsselten Challenge erfolgen, und ist optional);
Überprüfen der Zugriffsberechtigung im Authentifikationsserver auf Basis des verschlüsselten Challenge.
Stellt bei dieser Überprüfung der Authentifikationsserver fest, dass keine Zugriffsberechtigung gegeben ist, erfolgt die Ausgabe einer entsprechenden Meldung an das mobile Gerät zwecks Ausgabe an den Benutzer und/oder es erfolgt ein Abbruch der Kommunikation durch den Authentifikationsserver, der dann vom Datenverarbeitungsprogramm des mobilen Geräts als nicht-Authentifikation erkannt wird. Bei fehlender Zugriffsberechtigung ist auch die Generierung einer verschlüsselten Authentifikation durch den Authentifikationsserver möglich, deren Inhalt eine fehlende Authentifikation ist.
Bei gegebener Zugriffsberechtigung erfolgt die Generierung einer verschlüsselten Authentifikation.
Wenn eine derartige Authentifikation erzeugt wird (sei es nun mit dem Inhalt der fehlenden Authentifikation oder mit dem Inhalt der gegebenen Authentifikation) folgen folgende Schritte in der angegebenen Reihenfolge:
Übergabe der verschlüsselten Authentifikation vom Authentifikationsserver an das mobile Gerät über die Datenverbindung;
Übermittlung der verschlüsselten Authentifikation vom mobilen Gerät an das Gerät über die Schnittstelle;
Überprüfen der Zugriffsberechtigung im Gerät auf Basis der verschlüsselten Authentifikation, und bei fehlender Zugriffsberechtigung Ausgabe respektive Übermittlung einer entsprechenden Meldung an das mobile Gerät bei gegebener Zugriffsberechtigung Freigabe des Datenaustauschs zwischen dem mobilen Gerät (MG) und dem weiteren Gerät (G) und/oder des Datenaustauschs zwischen dem weiteren Gerät (G) und dem Server (AS) über das mobile Gerät (MG) im Umfang der Authentifikation.
Die gesicherte Verbindung für den Austausch von Daten zwischen dem Gerät und dem Sever mittels verschlüsselten Tunnels kann durch das mobile erfolgen. Der Benutzer des mobilen Geräts kann dann am Server angemeldet sein und via Server auch mit dem getunnelten Gerät kommunizieren, wenn das autorisiert ist, aber das Verfahren kann auch so strukturiert werden, dass es gar keine direkte Verbindung User (auf seinem mobilen Gerät) mit dem Gerät gibt.
Der große Vorteil dieses Verfahrens ist, dass im wesentlichen die gesamte Absicherung zum Zeitpunkt des Aufsetzens des weiteren Geräts erfolgen kann, indem die entsprechenden Schlüssel auf dem Gerät und auf dem Authentifikationsserver hinterlegt werden. Die entsprechenden Informationen können auch in einer öffentlichen Blockchain als Server hinterlegt werden, zusammen gegebenenfalls mit weiteren, dass Gerät charakterisierenden Daten, wie beispielsweise dessen Alter, Auslieferungszustand, Version, Fakturierung, Eigentümer, Lieferdatum. Weitere derartige Parameter sind das Gerät steuernde oder kontrollierende Parameter aber auch die Softwareversion, etc.
Ein weiterer großer Vorteil des vorgeschlagenen Verfahrens ist, dass keine gerätespezifischen Passwörter erforderlich sind, sondern nur vom Benutzer eine Autorisierung für die Anmeldung beim Authentifikationsserver erforderlich ist. Zudem ergibt sich beim vorgeschlagenen Verfahren der Vorteil, dass auf dem Authentifikationsserver der Zugriff spezifisch von einem Administrator festgelegt werden kann, namentlich für bestimmte Benutzer, bestimmte Geräte, bestimmte Zeitfenster etc. Auch die Tiefe der Kommunikation kann festgelegt werden, beispielsweise kann einem bestimmten Benutzer in einem bestimmten Zeitfenster nur das Auslesen von Daten ermöglicht werden, nicht aber die Änderung der Konfiguration des Geräts oder ein Update der Software, etc.
Vorzugsweise erfolgt der Datenaustausch zwischen dem weiteren Gerät und dem Server über das mobile Gerät, und das weitere Gerät kontrollierende Parameter, die auf dem Server hinterlegt sind, oder vom Benutzer des mobilen Geräts auf den Server gelegt werden, vom Server über das mobile Gerät in das weitere Gerät (G) eingeschrieben werden. Dies vorzugsweise ohne direkte und/oder indirekte Einflussnahme des Benutzers und weiter vorzugsweise unter Protokollierung der Datenübermittlung über ein Display des mobilen Geräts (MG) an den Benutzer.
Die Vorteile dieses Vorgehens sind u.a. wie folgt:
• es gibt keine Möglichkeit für einen Benutzer, das Gerät lokal ohne Serververbindung zu konfigurieren und damit einen nicht synchronisierten Parameterstand ins Gerät zu bringen (Verhinderung undokumentierter Systemänderung);
• der Tunnel, der über das mobile Gerät gestellt wird, kann auch durch einen völlig unbeteiligten (z.B. einen Schul-Techniker, der die Geräte gar nicht kennt) via sein Mobilgerät temporär erstellt werden damit ein ‘remote’ Techniker das Gerät online konfigurieren und warten kann;
• oder ein Techniker kann eine neue Konfiguration vorbereiten, die dann durch den vor-Ort Mitarbeiter ohne Änderungsberechtigungen an die Geräte G durch Herstellung des Tunnels verteilen;
• jede Änderung am Gerät ist sowohl dokumentiert wer sie wann gemacht hat (auf dem Server) als auch wann sie via Tunnel über ein mobiles Gerät MG ins Gerät G übertragen wurde (und optional, wenn der Benutzer des mobilen Geräts MG aktiv einloggen muss, wer das war).
Das Gerät ist schon "bei Geburt" bekannt und entsprechend kann ein "shared key", oder genereller gesagt, Key Material direkt in der Fabrik in das Gerät geschrieben werden. Letztendlich nutzt man vorzugsweise public/private key Verfahren eigentlich nur, um einen session key sicher auszuhandeln.
Das Gerät wird vorzugsweise deshalb vorzugsweise bei Herstellung mit einer individuellen "shared secret" ausgestattet, die gleichzeitig in einem sicheren Datenspeicher, Blockchain etc., zur späteren Nutzung durch das Portal (Authentifikationsserver) gespeichert wird.
Im Gerät wird zum Herstellungszeitpunkt vorzugsweise auch ein Zähler initialisiert (z.B. auf 1 als Initialwert gesetzt), und dieser Wert wird ebenfalls für das Portal abgelegt. Dieser Zähler ist hilfreich, um "playback" Attacken zu identifizieren, aber nicht unbedingt notwendig.
Alternativ zu einer "shared secret" können auch standardisierte Zertifikate genutzt werden. Der "Index" für die Schlüsselinformationen auf dem Server kann eine unveränderliche Seriennummer des Gerätes sein.
Beim Verbindungsaufbau wird typischerweise zuerst einmal die Authentizität des Mediators (mobile Gerät) überprüft (dies erfolgt z.B. üblicherweise mittels eines Client Zertifikates und/oder user login).
Der Mediator wird dann typischerweise vom Gerät einen spezifischen Datensatz anfordern, nämlich
• Gerätei D
• Sequenznummer S1
• Challenge C1 (im Gerät erzeugte Zufallszahl)
Diese Daten werden vorzugsweise vom Mediator an den Server geschickt.
Der Server kann nun an Hand der Gerätei D überprüfen ob der Mediator (Nutzer) zum Zugriff auf dieses Gerät berechtigt ist.
Falls ja, wird er vorzugsweise über challenge C1 und Sequenznummer S1 mit der gerätespezifischen "Secret" ein Kryptogramm K1 berechnen und dieses samt einer vom Server generierten Zufallszahl/Challenge C2 an den Mediator zur Weiterleitung übermitteln Das Gerät kann, wenn es den Datensatz (Kryptogramm K1 , Zufallszahl C2) vom Server erhält, die Authentizität des Servers prüfen (ist das Kryptogramm K1 richtig berechnet) und seinerseits über die vom Server übermittelte Zufallszahl C2 einen Cryptohash K2 berechnen und diesen an den Server via Mediator zurückschicken.
Nun kann der Server an Hand des Hashes K2 auch die Authentizität des Gerätes prüfen und die Assoziation Server-Mediator-Gerät ist authentifiziert.
In einer präferierten Ausführung wird der Mediator die Kommunikation mit dem Server über eine verschlüsselte, gesicherte Kommunikationsschnittstelle (z.B. Websocket) durchführen und die Kommunikation zwischen Mediator und Gerät z.B. über eine unabhängige Verschlüsselung oder eine direkte Drahtverbindung erfolgen.
Die Reihenfolge der Authentifizierungen kann auch umgedreht werden.
Beide Seiten können vorzugsweise auch nicht authentifizierte Versuche loggen und entsprechend mit Back-off Algorithmen brute force Attacken verhindern.
Das Grundprinzip ist vorzugsweise immer, dass sich sowohl das Gerät (via Mediator) beim Server, als auch der Server beim Gerät via Mediator, zweifelsfrei mit Hilfe kryptografischer Verfahren authentisiert.
Der dann folgende Datenaustausch sollte vorzugsweise über eine vom Mediator verschlüsselte Verbindung erfolgen, es kann aber mittels bekannter Verfahren unter Zuhilfenahme der "shared secret" eine End-to-End Verschlüsselung zwischen Server und Gerät aufgesetzt werden.
Dabei werden z.B. folgende Speicherstrukturen eingesetzt:
Im Gerät werden die folgenden Daten gehalten (vorzugsweise wenigstens zwei davon, insbesondere vorzugsweise alle):
• Gerätei D • Shared Secret
• Sequenznummer (wird bei jeder erfolgten Authentisierung erhöht)
• Challenge (volatil, wird nur bis zur Überprüfung des vom Server zurückgeschickten Kryptogrammes gehalten)
Im Server oder auf externer Blockchain ausgelagert (vorzugsweise wenigstens zwei davon, insbesondere vorzugsweise alle):
• Shared Secret, pro Gerät, indiziert mit den Gerätei Ds
• letzte Sequenznummer
• letztes Zugriffsdatum, Zähler für erfolgreiche und nicht erfolgreiche Verbindungen etc (Statistik)
• Erzeugter Challenge (volatil, wird nur für die Überprüfung des vom Gerät zurückgeschickten Kryptogrammes gehalten). Eine bevorzugte Ausführungsform des vorgeschlagenen Verfahrens ist dadurch gekennzeichnet, dass es sich bei der gemeinsamen Schnittstelle um eine kabellose Schnittstelle handelt, vorzugsweise um eine Bluetooth, BLE, WLAN, NFC, RFID, Funkverbindung, oder auch Schall (Ton via Lautsprecher/Mikrofon, Töne im hörbaren und/oder nicht hörbaren Bereich) Schnittstelle.
Das Verfahren ist weiterhin vorzugsweise dadurch gekennzeichnet, dass es sich bei der gemeinsamen Schnittstelle um eine kabelgebundene Schnittstelle handelt, bevorzugt um eine serielle Schnittstelle, eine USB-Schnittstelle, Ethernet, CAN Bus oder andere verfügbare lokale Interfaces (einschliesslich I2C).
Die Authentifikation kann, wie weiter oben erwähnt, neben der reinen Berechtigungsinformation Informationen über den Umfang der Berechtigung beinhaltet, insbesondere Benutzerinformationen, Zeitinformationen (Dauer des Zugriffs Beginn des Zugriffs, Ende des Zugriffs), erlaubte Eingriffstiefe.
Bei der Überprüfung der Zugriffsberechtigung im Authentifikationsserver ist es möglich, nicht nur den verschlüsselten Challenge zu berücksichtigen, sondern zusätzlich Informationen über das mobile Gerät, bevorzugt in Form einer Hardware-spezifischen und individualisierten Information, und/oder Informationen über den bei mobilen Gerät und/oder beim Authentifikationsserver angemeldeten Benutzer, und/oder Informationen von einem Token eines derartigen Benutzers.
Typischerweise handelt es sich beim mobilen Gerät um einen Laptop oder ein Mobiltelefon. Bevorzugtermassen ist das Verfahren weiterhin dadurch gekennzeichnet, dass im Rahmen des freigegebenen Datenaustauschs Daten aus dem Speicher des weiteren Geräts ausgelesen werden (beispielsweise Daten, die von einem Sensor in der Zeit vorher aufgenommen wurden und geloggt wurden, z.B. den Inhalt eines Fehlermeldungsspeichers), ein Update auf das Gerät geladen wird, das Gerät neu konfiguriert wird, oder eine Kombination davon.
Das weitere Gerät weist typischerweise wenigstens die genannte Schnittstelle auf, sowie eine Datenverarbeitungseinheit mit Speicher, sowie wenigstens eine weitere Funktionalität, insbesondere einen Sensor, eine Ausgabeschnittstelle, insbesondere ein Display, oder einen Lautsprecher, oder eine Kombination solcher Funktionalitäten. Es kann sich dabei um ein komplexes Gerät wie beispielsweise einen Drucker oder einen Industrieroboter handeln, es kann sich aber auch um ganz einfache Geräte im Sinne von loT Geräten handeln, die zum Beispiel nur einen Sensor aufweisen.
Auf dem Authentifikationsserver und dem Gerät sind typischerweise private Schlüssel für die Generierung von Challenge respektive Authentifikation und die Verifikation dieser verschlüsselten Information vorhanden, sowie vorzugsweise entsprechende zugehörige öffentliche Schlüssel auf dem jeweils anderen Gerät.
Zur Erhöhung der Sicherheit kann das Gerät auch eine inkrementierende Zahl nutzen, und es ist weiter möglich mehrere Schlüssel vorzuhalten (auf beiden Seiten), die dann entweder zufällig oder nach einer bestimmten Zeit und/oder Erreichen einer bestimmten Zahl gewechselt werden.
Die Schlüssel können, gegebenenfalls zusammen mit einer Hardware-spezifischen und individualisierten Information des Geräts, auf einer öffentlichen Blockchain abgelegt sein.
Wenn der Challenge bei der Überprüfung auf dem Authentifikationsserver zu einer Nichtberechtigung führt, kann der Authentifikationsserver gemäß einer weiteren bevorzugten Ausführungsform eine Authentifikation an das mobile Gerät übermitteln, die entweder direkt am mobilen Gerät als Nichtberechtigung erkannt wird und zur Ausgabe einer entsprechenden Meldung an den Benutzer am mobilen Gerät führt, oder es kann die Authentifikation an das weitere Gerät übermittelt werden, und auf diesem eine entsprechende Ausgabe ausgegeben werden oder eine solche vom weiteren Gerät an das mobile Gerät für die Ausgabe zurück übermittelt werden. Es kann dabei sinnvoll sein, die ungültige Authentifikation dem Gerät mitzuteilen damit dieses z.B. nach einer bestimmten Zahl Versuche für einige Zeit blockiert.
Bevorzugtermassen kann zudem auf dem weiteren Gerät eine Kennung, vorzugsweise in Form eines Barcode oder eines QR-Code, vorgesehen sein, die vom mobilen Gerät, beispielsweise durch eine Kamera, ausgelesen werden kann und für die Identifikation des weiteren Geräts und für die Kommunikation mit dem Authentifikationsserver eingesetzt wird, indem die entsprechende Gerätekennung zusammen mit dem Challenge an den Authentifikationsserver übermittelt wird.
Weiter betrifft die vorliegende Erfindung ein System zur Durchführung eines Verfahrens wie oben beschrieben, wobei das System wenigstens einen Authentifikationsserver, wenigstens ein mobiles Gerät und wenigstens ein weiteres Gerät vorzugsweise eine Mehrzahl von weiteren Geräten aufweist, und wobei zwischen Authentifikationsserver und mobilem Gerät eine Datenverbindung vorhanden ist, und das mobile Gerät und das weitere Gerät wenigstens eine gemeinsame Schnittstelle für Datenaustausch aufweisen. Auf den verschiedenen Bauteilen ist zudem jeweils eine Datenverarbeitungssoftware vorgesehen, die das vorgeschlagene Verfahren implementiert.
Entsprechend betrifft die vorliegende Erfindung auch ein Datenverarbeitungsprogramm, vorzugsweise auf einem Datenspeicher, zur Durchführung eines Verfahrens wie oben beschrieben, wobei das Datenverarbeitungsprogramm auf dem mobilen Gerät mit einer Ausgabeschnittstelle, vorzugsweise in Form eines Displays des mobilen Geräts zur Kommunikation mit dem Benutzer kommuniziert.
Weitere Ausführungsformen sind in den abhängigen Ansprüchen angegeben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Bevorzugte Ausführungsformen der Erfindung werden im Folgenden anhand der Zeichnungen beschrieben, die lediglich zur Erläuterung dienen und nicht einschränkend auszulegen sind. In den Zeichnungen zeigt:
Fig. 1 schematisch den schrittweisen Authentifizierungsvorgang an einem Gerät.
BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
In Fig. 1 ist schematisch das hier vorgeschlagene Verfahren für die Authentifizierung eines mobilen Geräts MG an einem lokalen Gerät G wiedergegeben.
Voraussetzung für das Verfahren ist, dass auf einem Authentifikationsserver AS eine Datenstruktur hinterlegt ist, die es ermöglicht, eine verschlüsselte, vom Gerät G bereitgestellte Verifikationsinformation, die in der Folge als Challenge Ch bezeichnet wird, verifizieren kann, und bei Verifikation eine Authentifikation Aut bereitstellen kann. Neben der eigentlichen Authentifikation im Sinne der Information zur Kontrolle der Freigabe des Zugriffs kann die Authentifikation auch noch weitere Informationen beinhalten, so beispielsweise die Dauer des freigegebenen Zugriffs, den Umfang des freigegebenen Zugriffs (bis auf welche Eingriffstiefe), die Menge der freigegebenen auszutauschenden Daten, etc.
Weitere Voraussetzung Verfahren ist, dass auf dem Gerät G eine Datenstruktur hinterlegt ist, die es einerseits ermöglicht, nach Aufbau einer Kommunikationsanfrage KA von einem mobilen Gerät MG aus, eine verschlüsselte Verifikationsinformation, den Challenge, bereitzustellen. Weiter ermöglicht die Datenstruktur auf dem Gerät, eine vom Authentifikationsserver bereitgestellte Authentifikation Aut zu prüfen und bei positivem Überprüfungsresultat das Gerät G im Umfang der Authentifikation Aut für die Kommunikation mit dem mobilen Gerät MG freizugeben. Beinhaltet die Authentifikation Aut neben der eigentlichen Kontrolle der Freigabe des Zugriffs auch noch weitere Informationen wie beispielsweise die Dauer des freigegebenen Zugriffs, den Umfang des freigegebenen Zugriffs etc., so gibt das Gerät G die Kommunikation entsprechend frei.
Ein Gerät G im Sinne der vorliegenden Erfindung ist ein Gerät, das auf jeden Fall über eine Schnittstelle zum Austausch von Information mit einem mobilen Gerät bereitstellt, beispielsweise in Form einer drahtlosen Kommunikationsverbindung, zum Beispiel Bluetooth, Bluetooth Low Energy, WLAN (IEEE 802.11), aber auch in Form einer kabelgebundenen Verbindung, beispielsweise in Form einer USB-Verbindung, einer seriellen Schnittstelle. Weiter verfügt das Gerät über eine Datenverarbeitungseinheit (CPU) mit Speichermöglichkeit, die an die Schnittstelle angebunden ist, sowie über wenigstens eine weitere Funktionalität, die das eigentliche Gerät ausmacht, beispielsweise einen Sensor, eine Ausgabeschnittstelle (beispielsweise Lautsprecher, Display), es kann sich aber auch um ein Robotergerät o. ä. handeln, das bestimmte automatisierte Aufgaben übernimmt. Weiter verfügt das Gerät G über eine Stromversorgung (zum Beispiel in Form einer Batterie, eines Akkus oder einer kabelgebundenen Stromversorgung).
Das Gerät G kann über direkte oder indirekte eine Internetverbindung verfügen, muss aber nicht. Wenn eine derartige Internetverbindung vorhanden ist, kann diese zur Übermittlung von Daten, die das Gerät erzeugt, oder entgegennehmen soll, zu einem Cloud-Backend erfolgen. Die Daten können dabei über ein WLAN oder eine ähnliche Verbindung über einen Server an das Internet übergeben respektive von diesem empfangen werden. Das Gerät muss aber auch nicht über eine derartige Verbindung verfügen, das Verfahren ist insbesondere auch dadurch gekennzeichnet, dass es ohne eine Verbindung an ein Cloud- Backend funktioniert.
Der Authentifikationsserver AS ist ein Cloud-Backend, das über eine Internetverbindung oder eine Mobiltelefonverbindung von dem Mobilgerät MG kontaktiert werden kann.
Unter diesen Rahmenbedingungen ist nun folgendes Verfahren zur Freigabe des Zugriffs auf das Gerät G möglich, beispielsweise wenn Wartungsarbeiten oder neue Konfigurationen am Gerät G vorgenommen werden sollen. Dazu nähert sich die entsprechende Person mit ihrem mobilen Gerät MG, das über eine Kommunikationsschnittstelle verfügt, die jener am Gerät G entspricht, dem Gerät G, und baut, typischerweise über eine eigens dafür vorgesehene Authentifikationsoftware, eine Kommunikationsverbindung KA mit dem Gerät auf (Fig. 1 a) oberer Pfeil).
Das Gerät G ist nun so konfiguriert, dass es auf die entsprechende Anfrage der Authentifikationsoftware nicht auf die Eingabe eines Zugriffscodes o. ä. wartet, sondern vielmehr den genannten Challenge Ch, d. h. eine verschlüsselte Verifikationsinformation, an das mobile Gerät MG übermittelt (Fig. 1 a) unterer Pfeil).
Dieser Challenge Ch wird nun im mobilen Gerät MG nicht verifiziert oder bearbeitet, sondern unverändert über eine drahtlose Datenverbindung, die im mobilen Gerät MG vorgesehen ist, an den Authentifikationsserver AS übermittelt (Fig. 1 b)). Diese Übermittlung wird vom Authentifikationsserver AS nur freigegeben, wenn sich der entsprechende Benutzer des mobilen Geräts MG beim Authentifikationsserver gültig angemeldet hat.
Erst auf diesem wird nun der Challenge Ch überprüft. Wenn der Authentifikationsserver AS feststellt, dass das mobile Gerät MG oder dessen Benutzer oder beide berechtigt sind, Zugriff auf das Gerät G zu nehmen, übermittelt der Authentifikationsserver eine Authentifikation Aut an das mobile Gerät MG (Fig. 1 c)).
Diese Authentifikation Aut wird wiederum vom mobilen Gerät unverändert über die lokale Schnittstelle übermittelt (Fig. 1 d)).
Daraufhin überprüft das Gerät G die Authentifikation Aut, und wenn die Überprüfung positiv ist, wird die im Umfang der Authentifikation festgelegte Kommunikation freigegeben (Fig. 1 e)).
Auf dem Authentifikationsserver können entsprechend Zeitfenster definiert werden, Benutzer sowie berechtigte Zugriffsgeräte definiert werden, sodass die Authentifikation nur im Rahmen dieser Vorgaben effektiv ausgestellt wird.
Das zum Zugriff auf das Gerät nötige 'Geheimnis' wird m.a.W. niemals irgendjemandem gegeben. Es liegt sicher auf einem Cloud Service AS.
Ein Techniker oder Besitzer des Gerätes G muss sich mit den bekannten Verfahren (inkl. 2FA) beim Cloud Service AS ausweisen. Hier kann ein Administrator auch z.B. Zeitfenster für einen Zugriff vergeben, so dass ein Techniker nur für einen bestimmten Zeitpunkt an dem Gerät zugreifen darf.
Der Techniker geht entsprechend mit seinem mobilen Gerät MG beispielsweise vor Ort. Das Gerät G hat keine netzwerkseitigen Zugriffsmöglichkeiten 'offen'.
Über einen lokal vorhandenen Anschluss (z.B. BLE/Bluetooth/Serial etc) kann der Techniker sein Handy als mobiles Gerät MG mittels z.B. einer App mit dem Gerät verbinden. Das Gerät G übergibt dem Handy den Challenge Ch.
Dieser wird vom Handy MG an den Cloud Service AS übermittelt in dem sich der Benutzer eingeloggt hat.
Nur wenn der Benutzer berechtigt ist, an dem spezifischen Gerät zu diesem spezifischen Zeitpunkt zu arbeiten, wird der Challenge Ch im Cloud Server AS korrekt ausgerechnet und die entsprechende Response Aut an die App (und von dieser an das Gerät) übermittelt. Das Gerät G überprüft die Antwort auf der Basis eines mit dem Cloud Portal AS vereinbarten individuellen Schlüssels und wenn diese OK ist, wird der Zugriff freigegeben. Je nach Anwendung kann der Mitarbeiter dann auf der Cloud bereitliegende Konfigurationen oder Daten ins Gerät G liefern, das Gerät kann Daten (verschlüsselt) über das Handy des Mitarbeiters an den Cloud service liefern, ein Webserver kann freigeschaltet werden etc.
Beim Cloudserver AS handelt es sich generell und unabhängig von den weiteren Merkmalen i.Z.m dem Ausführungsbeispiel mit anderen Worten und insbesondere bevorzugt nicht nur um einen Authentifikationsserver, sondern auch um einen generellen Datenserver, der insbesondere zur zentralen Verwaltung der Parameter (inkl. Softwareupdates etc.) auf dem Gerät G vorgesehen ist. Der Benutzer mit seinem mobilen Gerät MG kann direkt über sein mobiles Gerät MG entsprechend der auf dem Cloudserver festgelegten zeitlichen Berechtigung respektive örtlichen Berechtigung mit dem Gerät G kommunizieren und gegebenenfalls auch auf das Gerät G Einfluss nehmen und Parameter auf diesem Gerät G ändern. Bevorzugtermassen werden aber Parameter auf dem Gerät G nicht einfach unabhängig über das mobile Gerät MG am Gerät G verändert, sondern es wird sichergestellt, dass auf dem Cloudserver AS immer die aktuelle Parametrisierung des Geräts G vorhanden und abgelegt ist. Dies kann entweder so gewährleistet werden, dass bei Eingabe eines Parameters durch den Benutzer auf dem mobilen Gerät MG der entsprechende Parameter gleichzeitig an das Gerät G und an den Server übergeben wird, sodass an beiden Orten G und AS die korrekten Parameter hinterlegt sind, oder, vorzugsweise, vom Benutzer auf dem mobilen Gerät MG für das Gerät G geänderte Parameter werden zunächst an den Server AS übermittelt, in dessen Datenbank in die für das Gerät G hinterlegten Parameter eingeschrieben, und anschliessend vom Cloudserver AS über das mobile Gerät MG an das Gerät G übermittelt.
Alternativ ist es möglich, dass derartige Parameter für das Gerät G nur vom Cloudserver AS über das mobile Gerät MG an das Gerät G übermittelt werden können, und auf dem Cloudserver AS und dem Gerät G auch nicht vom Benutzer über das mobile Gerät MG geändert werden können, sondern nur über direkten Zugriff (z.B. einloggen) auf dem Cloudserver AS. In diesem Fall dient der Verbindungsaufbau zwischen dem Gerät G und dem mobilen Gerät MG in Bezug auf diese Parameter nur als Vermittler einer Verbindung zwischen dem Gerät G und dem Cloudserver AS, um die Kontrolle des Geräts G durch den Cloudserver AS respektive die Anpassung der Parametrisierung ermöglichen, nicht aber eingreifend zu steuern. In einer solchen Strukturierung ist es auch möglich, dem Benutzer am mobilen Gerät MG überhaupt keine Möglichkeit zu geben, direkt auf das Gerät G zuzugreifen, abgesehen ggf. von einem passiven Auslesen. Es ist in dieser Situation möglich, dass das mobile Gerät MG des Benutzers, wenn es für derartige Handlungen vorbereitet ist, mit oder ohne weitere Einflussnahme des Benutzers einfach nur bei lokaler Anwesenheit in der Nähe des Gerätes G die Verbindung sowohl mit dem Gerät G über das sichere Protokoll wie oben beschrieben aufbaut, und anschliessend das mobile Gerät MG als Mittler für die Datenübermittlung zwischen dem Gerät G und dem Cloudserver AS autonom aktiv wird. Der Benutzer des mobilen Geräts kann dann gegebenenfalls noch über entsprechende Ausgaben über das Display darüber informiert werden, welche Aktionen durchgeführt wurden, und ob derartige Aktionen auch effektiv abgeschlossen wurden (was wichtig sein kann, wenn der Benutzer sich aus dem Verbindungsbereich respektive der Reichweite der Verbindung zwischen dem mobilen Gerät und dem Gerät G entfernen könnte).
Der zentrale Authentifikationsserver respektive die Datenbank (Cloudserver AS), bevorzugt in Form einer Blockchain, v.a. was die Parameter angeht, regelt mit anderen Worten die Berechtigungen, wer darf wann die Konfiguration an welchem Gerät verändern, Daten einsehen und so weiter (das geschieht per login des users an dem Rechner, eventuell sogar mit Webbrowser ohne lokale app etc).
Bevorzugt geht es also um die zeit-/orts-/gerätespezifische Berechtigung, Daten für das Gerät G einzusehen und zu ändern, gekoppelt mit der zufällig eventuell gleichen Person, die vor Ort steht und mit ihrem mobilen Gerät MG den Tunnel herstellt ohne zwingend aktiv involviert zu sein.
Die Vorteile dieses Vorgehens sind wie folgt:
• es gibt keine Möglichkeit für einen Benutzer, das Gerät lokal ohne Serververbindung zu konfigurieren und damit einen nicht synchronisierten Parameterstand ins Gerät zu bringen (Verhinderung undokumentierter Systemänderung);
• der Tunnel kann auch durch einen völlig unbeteiligten (z.B. einen Schul-Techniker, der die Geräte gar nicht kennt) via sein Mobilgerät MG temporär erstellt werden damit ein ‘remote’ Techniker das Gerät G online konfigurieren und warten kann;
• oder ein Techniker kann eine neue Konfiguration vorbereiten, die dann durch den vor-Ort Mitarbeiter ohne Änderungsberechtigungen an die Geräte G durch Herstellung des Tunnels verteilen
• JEDE Änderung am Gerät ist sowohl dokumentiert wer sie wann gemacht hat (auf dem Server) als auch wann sie via Tunnel über ein mobiles Gerät MG ins Gerät G übertragen wurde (und optional, wenn der Benutzer des mobilen Geräts MG aktiv einloggen muss, wer das war).
Das Verfahren kann ganz universell für unterschiedliche Geräte eingesetzt werden die auch keinen Internetanschluss haben müssen. Es eignet sich auch z.B. um Autos bei Schlüsselverlust aufzuschliessen, Tresore zu öffnen, etc.
Grundbedingung ist, dass das Gerät und der Cloud Service zur Geburtsstunde des Gerätes eine gemeinsam bekannte aber ansonsten geheime 'secret' ausgetauscht haben, die für die Authentisierung gebraucht wird, und der Zugang zu dieser Secret durch den Cloudservice nur nach beliebig rigider Prüfung der Zutrittsberechtigung im Cloudsystem erteilt wird.
Die Zugangsdaten zum Gerät (Security/Secret) können z.B. auch in einer public Blockchain gespeichert sein, um sie für immer vor Verlust zu schützen - dann ist nur der zugehörige Schlüssel zu den verschlüsselten Blockchain entries notwendig (der z.B. vom Cloud Portal verwaltet wird).
BEZUGSZEICHENLISTE
AS Authentifikationsserver / G Endgerät, loT Datenserver KA Kommunikationsaufbau
Aut Authentifikation MG mobiles Gerät
Ch Challenge

Claims

PATENTANSPRÜCHE
1. Verfahren zur Freigabe einer Kommunikationsverbindung von einem mobilen Gerät (MG) zu einem weiteren Gerät (G), insbesondere auch für Datentaustausch zwischen dem weiteren Gerät (G) und einem Server (AS), wobei das mobile Gerät (MG) und das weitere Gerät (G) über eine gemeinsame Schnittstelle für einen Datenaustausch verfügen, gekennzeichnet durch folgende Schritte in der angegebenen Reihenfolge:
Kommunikationsanfrage (KA) durch das mobile Gerät (MG) an das weitere Gerät (G) über die Schnittstelle;
Übermittlung eines verschlüsselten Challenge (Ch) vom weiteren Gerät (G) an das mobile Gerät (MG) über die Schnittstelle;
Übergabe des verschlüsselten Challenge (Ch) vom mobilen Gerät (MG) über eine Datenverbindung an den Server als Authentifikationsserver (AS), an dem der Benutzer des mobilen Geräts (MG) angemeldet ist oder an dem der Benutzer des mobilen Geräts (MG) nicht angemeldet ist;
Überprüfen einer Zugriffsberechtigung im Authentifikationsserver (AS) auf Basis des verschlüsselten Challenge (Ch), und bei fehlender Zugriffsberechtigung Ausgabe einer entsprechenden Meldung und/oder Abbruch der Kommunikation durch den Authentifikationsserver; oder bei fehlender Zugriffsberechtigung Generierung einer verschlüsselten Authentifikation (Aut), deren Inhalt eine fehlende Authentifikation ist, und bei gegebener Zugriffsberechtigung Generierung einer verschlüsselten Authentifikation (Aut) und folgende Schritte in der angegebenen Reihenfolge:
Übergabe der verschlüsselten Authentifikation (Aut) vom Authentifikationsserver (AS) an das mobile Gerät (MG) über die Datenverbindung;
Übermittlung der verschlüsselten Authentifikation (Aut) vom mobilen Gerät (MG) an das Gerät (G) über die Schnittstelle;
Überprüfen der Zugriffsberechtigung im Gerät (G) auf Basis der verschlüsselten Authentifikation (Aut), und bei fehlender Zugriffsberechtigung Ausgabe respektive Übermittlung einer entsprechenden Meldung an das mobile Gerät (MG) bei gegebener Zugriffsberechtigung Freigabe des Datenaustauschs zwischen dem mobilen Gerät (MG) und dem weiteren Gerät (G) und/oder des Datenaustauschs zwischen dem weiteren Gerät (G) und dem Server (AS) über das mobile Gerät (MG) im Umfang der Authentifikation (Aut).
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass der Datenaustausch zwischen dem weiteren Gerät (G) und dem Server (AS) über das mobile Gerät (MG) erfolgt, und das weitere Gerät (G) kontrollierende Parameter, die auf dem Server (AS) hinterlegt sind, oder vom Benutzer des mobilen Geräts (MG) auf den Server (AS) gelegt werden, vom Server (AS) über das mobile Gerät (MG) in das weitere Gerät (G) eingeschrieben werden, vorzugsweise ohne direkte und/oder indirekte Einflussnahme des Benutzers und weiter vorzugsweise unter Protokollierung der Datenübermittlung über ein Display des mobilen Geräts (MG) an den Benutzer. .
3. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass es sich bei der gemeinsamen Schnittstelle um eine kabellose Schnittstelle handelt, vorzugsweise um eine Bluetooth, BLE, WLAN, NFC, RFID, und/oder Schall Schnittstelle und/oder dass es sich bei der gemeinsamen Schnittstelle um eine kabelgebundene Schnittstelle handelt, bevorzugt um eine serielle Schnittstelle, eine USB-Schnittstelle, Ethernet, CAN Bus.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Authentifikation (Aut) neben der reinen Berechtigungsinformation Informationen über den Umfang der Berechtigung beinhaltet, insbesondere Benutzerinformationen, Zeitinformationen, Ortsinformationen, erlaubte Eingriffstiefe.
5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei der Überprüfung der Zugriffsberechtigung im Authentifikationsserver (AS) nicht nur der verschlüsselten Challenge (Ch) berücksichtigt wird, sondern zusätzlich Informationen über das mobile Gerät (MG), bevorzugt in Form einer Hardware-spezifischen und individualisierten Information, und/oder Informationen über den bei mobilen Gerät und/oder beim Authentifikationsserver angemeldeten Benutzer, und/oder Informationen von einem Token eines derartigen Benutzers.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass es sich beim mobilen Gerät (MG) um einen Laptop oder ein Mobiltelefon handelt.
7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen des freigegebenen Datenaustauschs Daten aus dem Speicher des weiteren Geräts (G) ausgelesen werden, ein Update auf das Gerät geladen wird, das Gerät neu konfiguriert wird, oder eine Kombination davon.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das weitere Gerät (G) wenigstens die genannte Schnittstelle aufweist sowie eine Datenverarbeitungseinheit (CPU) mit Speicher, sowie wenigstens eine weitere Funktionalität, insbesondere einen Sensor, eine Ausgabeschnittstelle, insbesondere ein Display, oder einen Lautsprecher, oder eine Kombination solcher Funktionalitäten.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auf dem Authentifikationsserver (AS) und dem Gerät (G) private Schlüssel für die Generierung von Challenge (Ch) respektive Authentifikation (Aut) und die Verifikation dieser verschlüsselten Information vorhanden sind, sowie vorzugsweise entsprechende zugehörige öffentliche Schlüssel auf dem jeweils anderen Gerät, wobei vorzugsweise auf dem Gerät eine inkrementierende Zahl geführt wird.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass auf dem Authentifikationsserver (AS) und dem Gerät (G) mehrere Schlüssel vorgehalten werden, die dann entweder zufällig oder nach einer bestimmten Zeit und/oder Erreichen einer bestimmten Zahl gewechselt werden.
11. Verfahren nach Anspruch 9 oder 10, dadurch gekennzeichnet, dass die Schlüssel, gegebenenfalls zusammen mit einer Hardware-spezifischen und individualisierten Information des Geräts, auf einer öffentlichen Blockchain abgelegt sind.
12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass, wenn der Challenge (Ch) bei der Überprüfung auf dem Authentifikationsserver (AS) zu einer Nichtberechtigung führt, der Authentifikationsserver (AS) eine Authentifikation (Aut) an das mobile Gerät (MG) übermittelt, die entweder direkt am mobilen Gerät (MG) als Nichtberechtigung erkannt wird und zur Ausgabe einer entsprechenden Meldung an den Benutzer am mobilen Gerät (MG) führt, oder dass die Authentifikation (Aut) an das weitere Gerät (G) übermittelt wird, und auf diesem eine entsprechende Ausgabe ausgegeben wird oder eine solche vom weiteren Gerät (G) an das mobile Gerät für die Ausgabe (MG) zurück übermittelt wird.
13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass auf dem weiteren Gerät (G) eine Kennung, vorzugsweise in Form eines Barcode oder eines QR-Code, vorgesehen ist, die vom mobilen Gerät (MG) ausgelesen werden kann und für die Identifikation des weiteren Geräts (G) und für die Kommunikation mit dem Authentifikationsserver (AS) eingesetzt wird, indem die entsprechende Gerätekennung zusammen mit dem Challenge (Ch) an den Authentifikationsserver (AS) übermittelt wird.
14. System zur Durchführung eines Verfahrens nach einem der vorhergehenden Ansprüche, wobei das System einen Server und/oder Authentifikationsserver (AS), wenigstens ein mobiles Gerät (MG) und wenigstens ein weiteres Gerät (G) vorzugsweise eine Mehrzahl von weiteren Geräten aufweist, und wobei zwischen Server und/oder Authentifikationsserver (AS) und mobilem Gerät (MG) eine Datenverbindung vorhanden ist, und das mobile Gerät (MG) und das weitere Gerät (G) wenigstens eine gemeinsame Schnittstelle für Datenaustausch aufweisen.
15. Datenverarbeitungsprogramm, vorzugsweise auf einem Datenspeicher, zur Durchführung eines Verfahrens nach einem der Ansprüche 1-13, wobei das Datenverarbeitungsprogramm auf dem mobilen Gerät (MG) mit einer Ausgabeschnittstelle, vorzugsweise in Form eines Displays des mobilen Geräts (MG) zur Kommunikation mit dem Benutzer kommuniziert.
PCT/EP2023/061904 2022-05-10 2023-05-05 Abgesichertes zugriffssystem WO2023217645A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP22172558 2022-05-10
EP22172558.3 2022-05-10

Publications (1)

Publication Number Publication Date
WO2023217645A1 true WO2023217645A1 (de) 2023-11-16

Family

ID=81648092

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2023/061904 WO2023217645A1 (de) 2022-05-10 2023-05-05 Abgesichertes zugriffssystem

Country Status (1)

Country Link
WO (1) WO2023217645A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118503944A (zh) * 2024-07-12 2024-08-16 宁波银行股份有限公司 一种鉴权方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140273824A1 (en) 2013-03-15 2014-09-18 Medtronic, Inc. Systems, apparatus and methods facilitating secure pairing of an implantable device with a remote device using near field communication
US20160050565A1 (en) 2014-08-18 2016-02-18 Qualcomm Incorporated Secure provisioning of an authentication credential
WO2021099063A1 (de) 2019-11-20 2021-05-27 Siemens Energy Global GmbH & Co. KG Geschütztes rücksetzen eines iot-geräts

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140273824A1 (en) 2013-03-15 2014-09-18 Medtronic, Inc. Systems, apparatus and methods facilitating secure pairing of an implantable device with a remote device using near field communication
US20160050565A1 (en) 2014-08-18 2016-02-18 Qualcomm Incorporated Secure provisioning of an authentication credential
WO2021099063A1 (de) 2019-11-20 2021-05-27 Siemens Energy Global GmbH & Co. KG Geschütztes rücksetzen eines iot-geräts

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN118503944A (zh) * 2024-07-12 2024-08-16 宁波银行股份有限公司 一种鉴权方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
EP3731119A1 (de) Computerimplementiertes verfahren zur zugriffskontrolle
EP3422628B1 (de) Verfahren, sicherheitseinrichtung und sicherheitssystem
DE112008001436T5 (de) Sichere Kommunikation
EP2805446A1 (de) Funktion zur challenge-ableitung zum schutz von komponenten in einem challenge-response authentifizierungsprotokoll
DE102009026953A1 (de) Verfahren zum Einbuchen eines Mobilfunkgeräts in ein Mobilfunknetz
EP3246839A1 (de) Zugangskontrolle mit einem mobilfunkgerät
EP2446390A1 (de) System und verfahren zur zuverlässigen authentisierung eines gerätes
DE102014204252A1 (de) Sicherheitssystem mit Zugriffskontrolle
EP3935808B1 (de) Kryptographisch geschütztes bereitstellen eines digitalen zertifikats
WO2023217645A1 (de) Abgesichertes zugriffssystem
DE102016222100A1 (de) Verfahren und System zum Nachweis eines Besitzes eines Fahrzeugs
EP3465513B1 (de) Nutzerauthentifizierung mittels eines id-tokens
DE102017121648B3 (de) Verfahren zum anmelden eines benutzers an einem endgerät
EP3244360A1 (de) Verfahren zur registrierung von geräten, insbesondere von zugangskontrollvorrichtungen oder bezahl- bzw. verkaufsautomaten bei einem server eines systems, welches mehrere derartige geräte umfasst
DE102017006200A1 (de) Verfahren, Hardware und System zur dynamischen Datenübertragung an ein Blockchain Rechner Netzwerk zur Abspeicherung Persönlicher Daten um diese Teils wieder Blockweise als Grundlage zur End zu Endverschlüsselung verwendet werden um den Prozess der Datensammlung über das Datenübertragungsmodul weitere Daten in Echtzeit von Sensoreinheiten dynamisch aktualisiert werden. Die Blockmodule auf dem Blockchaindatenbanksystem sind unbegrenzt erweiterbar.
DE602004009932T2 (de) Netzwerkgerät, System und Verfahren zur Authentifizierung
EP3882796A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
EP3288215A1 (de) Verfahren und vorrichtung zur ausgabe von authentizitätsbescheinigungen sowie ein sicherheitsmodul
DE102015208176A1 (de) Gerät und Verfahren zur Autorisierung eines privaten kryptographischen Schlüssels in einem Gerät
DE102017012249A1 (de) Mobiles Endgerät und Verfahren zum Authentifizieren eines Benutzers an einem Endgerät mittels mobilem Endgerät
DE102018132979A1 (de) Abgesichertes und intelligentes Betreiben einer Ladeinfrastruktur
EP4128658B1 (de) Verfahren zum login eines autorisierten nutzers auf ein gerät, insbesondere auf ein gerät für eine energieerzeugungsanlage
EP3881486B1 (de) Verfahren zur bereitstellung eines herkunftsortnachweises für ein digitales schlüsselpaar

Legal Events

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

Ref document number: 23723573

Country of ref document: EP

Kind code of ref document: A1