WO2022106653A1 - Dezentrale bereitstellung von benutzerdaten - Google Patents

Dezentrale bereitstellung von benutzerdaten Download PDF

Info

Publication number
WO2022106653A1
WO2022106653A1 PCT/EP2021/082369 EP2021082369W WO2022106653A1 WO 2022106653 A1 WO2022106653 A1 WO 2022106653A1 EP 2021082369 W EP2021082369 W EP 2021082369W WO 2022106653 A1 WO2022106653 A1 WO 2022106653A1
Authority
WO
WIPO (PCT)
Prior art keywords
user data
user
decentralized
authentication
computer
Prior art date
Application number
PCT/EP2021/082369
Other languages
English (en)
French (fr)
Inventor
Dirk Bolte
Beatrix Reiß
Dominik Deimel
Dietmar Klotz
Yannik Klaus GOLDGRÄBE
Original Assignee
comuny 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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=78821445&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=WO2022106653(A1) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by comuny GmbH filed Critical comuny GmbH
Priority to EP21819361.3A priority Critical patent/EP4248348A1/de
Publication of WO2022106653A1 publication Critical patent/WO2022106653A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/604—Tools and structures for managing or administering access control systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present invention relates to a method and a device for the selective provision of user data, in particular to provide adequate data protection when transmitting user data to a client.
  • user data may be required in order to ensure that access to certain services is granted to an authorized person. For example, a login may be provided for a user using a client such as a browser to request, manage, and/or customize specific user information. The user data can be requested in order to authenticate a user and only activate individual services if a specific user can be identified with sufficient validity.
  • the request for user data also allows a user to exercise some control over the provision of user data so that it can only be provided if the user is authorized to use a particular service.
  • the user data can be a variety of data, which can be at least partially self-selected, for example in the case of a user name or e-mail address, or also personal, for example in the case of a date of birth, a place of birth or a home address.
  • the user data can contain data assigned by a sovereign authority and/or centrally assigned data. For example, ID card number or insurance number or bank account number can be assigned, which can be assigned to a specific person.
  • the user data can therefore contain sensitive data.
  • Unauthorized access to user data by third parties can therefore pose a potential risk for the user concerned.
  • the authentication can be impaired, for example, by hack attempts, phishing or software-related changes.
  • identity management services can be provided for services that request user data, which verify the authentication of the user and enable authorization on the part of the user.
  • One option for authentication is service-related authentication and storage of user data.
  • a user is identified in this way by or for the respective service and, for example, corresponding login data are provided and stored for future use of this service.
  • Identity management systems of this kind which are responsible for authentication, are developed for the respective service and generally act independently of other services. For both the service and the user, it must be taken into account that the access management and the implemented procedures for processing identities are designed to be sufficiently secure. If these functions are not part of an organization's core business, appropriate implementation and maintenance of such functions and security aspects can be costly and there can be an increased risk of implementation errors.
  • user data must be stored or even generated several times for each service. For each service, respective registration data, user data and/or identities may be required, which may need to be updated at different intervals.
  • service-specific data such as login credentials
  • the user is generally more likely to reuse such data. If, for example, a password is used several times for different services by the user, there is a risk that a data leak from one service endangers the data integrity of other services.
  • An alternative authentication method provides that user data such as an identity or login data of a user for a specific service or client are stored or made available centrally. Such methods are based on standardized protocols such as OAuth, OpenID or SAML and offer identification, authentication and authorization as services or functions for the respective services or clients. These functions are present in a central system such as a central authentication server and are available to services or clients accordingly in order to provide requested user data with appropriate authorization.
  • the authentication can be made easier for the user because it is carried out by a central unit and the number of different authentication methods or authentication systems for different services is correspondingly smaller.
  • the security of the user data is reduced by providing it on a central unit, especially since a user's user data can be made available for a large number of services and could therefore be recorded by third parties in the event of a potential central attack. This is especially true when the user uses the same login credentials for different services. Accordingly, not only user data of different users, but also different user data of one user are potentially at risk.
  • the user data can be viewed by the central unit or the authentication server, which means that there is a potentially large number of user data for an individual user in a system.
  • this data for example, very specific data profiles of the user can be created, which significantly affect the user's privacy.
  • SSI decentralized or self-sovereign identity
  • DIDs can, for example, be generated using blockchain technology and stored in a blockchain network to allow independent verification of validity. Signing and encrypting such technologies increases the security factor and the use of e.g. B. unique identifiers for each system or each service or client means that data profiling is not possible when the data is intercepted by third parties.
  • the authorization and the provision of the requested user data takes place by means of a decentralized device, the provision of the requested user data comprising the encryption of user data stored on the decentralized device.
  • a service or client may require a specific user's credentials for login and the appropriate user credentials at from a central entity such as an authentication server.
  • the corresponding user data can then be at least partially encrypted on the decentralized or local device upon receipt of a corresponding request and made available for transmission to the central unit. Because the central unit, which then forwards transmitted user data to the service or client, unlike the service or client, does not have the key to decrypt the encrypted user data, this user data cannot be viewed and/or used by the central unit will.
  • a secure, encrypted transmission of the requested user data can be provided so that, for example, the interception of an identity or data profiling or data mining by unauthorized third parties can be largely avoided.
  • the provision of user data continues to be selective after appropriate authorization from the user and only for the requested user data, so that the secure use and provision of user data can be further improved.
  • a service or client can be a web service or browser function, for example, which requires certain user data such as a unique login and possibly other personal user data of a user.
  • Such login or username is also known as “subject” in the above protocols
  • certain user data is known as “userinfo” and is defined by certain claims and scopes, also known as “claims” and “scope”, respectively
  • a standard protocol such as OpenID Connect
  • the user name and an optional number of user data can be provided centrally by means of an identification token and, if necessary, further or specific user data or "userinfo” by means of an access token with appropriate authorization, with these tokens being stored accordingly in a central authentication service or authentication server are cached.
  • identification tokens and user info can be generated and provided on the decentralized device, being encrypted as part of the provision.
  • the corresponding—encrypted—user data or tokens can also be transmitted in encrypted form, for example using SSL, and even temporarily stored on the central unit. According to the protocol, the tokens can thus be transmitted to the service that requested the user data without the central unit being able to see the data.
  • the central unit can function and interact externally in such a way that the protocol can provide for it, so that the encryption and decentralized provision of the user data is compatible with a corresponding protocol.
  • the requested user data can also contain different user data that are more or less relevant to the user.
  • the user data can contain personal data or data issued by a central authority, which are correspondingly sensitive and misuse of this data can have serious consequences for the user.
  • only sensitive user data contained in a payload can be encrypted. This allows unencrypted user data to be used faster and encrypted user data to be decrypted for use at a later time, for example.
  • all of the user data provided is preferably encrypted. This ensures that none of the user data can be intercepted and/or sensitive user data is accidentally added and transmitted unencrypted.
  • a symmetric key is used.
  • a key can, for example, be present or stored in a service or client requesting the user data for decryption.
  • the encryption can be carried out using symmetrical keys, with a key rotation being optionally provided at predetermined time intervals.
  • the application parts responsible for the encryption can also be stored on the decentralized device in specified time intervals are exchanged. This reduces the probability that keys possibly intercepted by third parties will enable decryption in the future transmission of provided user data.
  • the encryption can be done using an asymmetric key. This means that an interim interpretation of the encrypted user data by third parties can be largely ruled out.
  • a key rotation as described above can also be provided in this case in order to further reduce the risk of using possibly compromised keys. Irrespective of the key symmetry, the user data provided can also be transmitted to the central unit in encrypted form through the encryption.
  • the size of the requested user data can be further padded when encrypting according to a given cryptographic standard.
  • the padding means that the size of the user data provided, for example the payload of the data to be transmitted, is always the same, so that fluctuations in the size of the requested user data do not offer any possibility for data interpretation or data profiling.
  • the padding is preferably performed according to PKCS#1, but can also be done using other protocols or standards.
  • the encryption and/or the filling can also be carried out using encryption methods that deviate from a standard and corresponding specially developed algorithms (so-called “self-made encryption”), as long as they are supported by a protocol that is used by the central unit.
  • Authentication of the user data and assurance of origin can also be achieved, at least in part, by signing the data provided before encrypting it.
  • a public signing key can be provided for the decentralized device.
  • public signing keys of multiple decentralized devices can be integrated as part of JWKS (“JSON Web Key Sets”), which is implemented in protocols such as OAuth2 and OpenID Connect, for example.
  • the central unit or an authentication server can generate a database with all the public keys of the decentralized devices.
  • query parameters can also be provided, for example in a URI (“uniform resource identifier”) of the JWKS, so that the key to be used can be specified.
  • the public key is provided dynamically, particularly preferably by means of one provided by the decentralized device Authorization Response.
  • the public key can be provided by dynamically updating the JWKS.
  • the central entity can provide that the JWKS URI is not cached. This requires a service or client to re-fetch the full JWKS for each authentication or user data request.
  • the decentralized device can transmit a current key in an authorization response to the central unit, which transmits the authorization response to the service or client requesting the user data.
  • the service receives the authorization response, it can request the current JWKS from the JWKS URI, which now contains the corresponding key.
  • the current key is preferably provided together with verification information such as a certificate, for example a connection to a device connection service or a FIDO2 server, in order to certify the authenticity and trustworthiness of the current key.
  • the central unit is a central authentication server, which causes the user to be authenticated in response to at least one authentication request received from a client and transmits the user data provided to the client.
  • such authentication servers or authentication services can provide a specific protocol such as OpenID Connect, in which case a client requires specific user data to authenticate a user, for example to enable a user to log in using a web browser.
  • OpenID Connect a specific protocol
  • no direct communication or bidirectional communication is provided between the authentication server and a client, especially since the authentication server does not know the client and requests are therefore only made from the client in the direction of the authentication server.
  • the user is authenticated and the user data provided is also transmitted preferably only in response to the initiating authentication request.
  • the data provided can be transmitted by redirection using a URI contained in the authentication request.
  • the central unit or the authentication server can also transmit an authentication response or authorization response using so-called “traps” or “callbacks” or “webhooks”, in which case active communication can be present at least temporarily.
  • the central unit can send a direct message when a specific event has occurred.
  • at least one key required to encrypt the requested user data is included in an authentication request received from the decentralized device.
  • this key could also have been transmitted in advance to the decentralized device outside of the authentication request or could still be present, for example from a previous authentication request that is assigned to the same client. Accordingly, the at least one key cannot be specified or can be valid for a limited time and can be exchanged for further authentication requests, for example.
  • Multiple keys are preferably used for encryption and decryption, which are asymmetrical, so that the encrypted user data cannot be interpreted even if they are intercepted by third parties, for example the central unit.
  • a key rotation is also preferably provided.
  • a client can specify the keys to be used and define them in the authentication request, for example as part of a dynamic client registration or as a JWKS or a JWKS URI.
  • the client can also transmit the at least one key to be used outside of the protocols (“out-of-band”) of the decentralized device or the decentralized device can receive the at least one key to be used directly from the client. This would make the creation of a profile by the central unit even more difficult, since the central unit has no knowledge of the client's encryption key.
  • the keys preferably contain a corresponding header so that the decentralized device which receives the keys can verify the integrity of the key or keys.
  • the one or more keys may include an x5c or x5u header according to an RFC 7517 standard.
  • JWK JSON Web Key
  • RFC Real-Fi Protected Access
  • a certificate that may be provided was signed by an entity that is classified as trustworthy by the corresponding client.
  • entity can, for example, be stored externally or also in the decentralized device, preferably as an application component or as an independent application.
  • a central certificate administration can also be provided, which is linked to the operating system, for example, and in which keys from trustworthy entities can be stored.
  • the at least one key can also be present and stored in the decentralized device and made available, for example, upon delivery of the decentralized device or an application on the decentralized device. It can optionally be provided that the at least one key is contained in a future authentication request.
  • the decentralized device can encrypt the requested user data accordingly and transmit it to the central unit in accordance with the protocol.
  • the remote device may provide an authorization response containing the provided user data in response to an authentication request.
  • the user can authorize the received request, for example from a client, with a corresponding authentication at the decentralized device, with the user data provided being contained in a corresponding response.
  • Such an authorization response may be provided in accordance with protocols such as in OpenID Connect.
  • the term "providing” can generally be understood to mean that this can include not only the local or decentralized encryption of user data, but also the transmission of the requested user data, so that an encrypted transmission of the authorization response can be provided as part of the process.
  • the provided user data can be present not only directly, but at least partially in the form of a token in the authorization response.
  • An identification token can thus be present in the authorization response, with which, among other things, a user name or other user data such as an e-mail address can be transmitted.
  • (encrypted) hash values for a code and/or for an access token can be present in the identification token.
  • the decentralized device can accordingly generate so-called hash or at hash elements for the code or the access token and include them in the identification token.
  • the tokens can be cached on the central unit and made available to a service or client that requests the user data when the corresponding hash value is transmitted.
  • the user data provided preferably contain a unique identifier, preferably in the form of a decentralized or centrally generated identifier.
  • An identifier such as a login name or subject should be unique so that double assignment is avoided.
  • an identifier can be in the form of a decentralized identifier (DID), which was generated using blockchain technology, or can also be provided as a hash function if the entropy of a decentralized algorithm is sufficient.
  • DID decentralized identifier
  • the identifier can also be issued or validated by a central authority.
  • a central authority For example, a sovereign authority can assign a person or a user a unique or unique identity card number, so that a person can be clearly identified with this number as an identifier.
  • a central release and assignment of an identifier can also be carried out by an entity that checks the uniqueness of a self-determined identifier. For example, a self-chosen e-mail address can be checked during registration with a provider to determine whether it has not yet been assigned and has not been assigned to another user.
  • the sensitive user data can be transmitted to the central unit, with the encryption of the user data and a preferred, additional encrypted transmission ensuring that at least the identifier cannot be viewed by third parties.
  • the user data stored on the decentralized device can, alternatively or additionally, be at least partially linked to the decentralized device.
  • the authenticity and affiliation of this user data present on the decentralized device can be checked in an authentication process originating from the decentralized device.
  • the decentralized device can thus be registered with a central instance, with a serial number or production number being stored, for example. In such a case, it may already be sufficient that this has been done for the authenticity and affiliation of the user data, especially since simple user data copies do not include any corresponding registration data.
  • device management functions can be provided, with registration being carried out using an identifier or being assigned to a specific person.
  • functions can be provided which require device binding and/or multi-instance verification of authenticity, for example using blockchain technology. In this way it can be ensured that only trustworthy devices can be assigned to the user data or a specific identity.
  • the authentication of the user can include the detection of a unique identifier issued by the central unit, preferably an optical or acoustic identifier, by the decentralized device, the decentralized device being the collection receives information that is necessary to provide the requested user data.
  • the identifier can, for example, be an optical element such as a barcode or QR code, which can be shown on a display or monitor when an authentication request is received from a service or client.
  • the central unit can represent the optical element, which can then be read out by a readout unit of the decentralized device.
  • the optical element can also be a numeric representation of a PIN, with a URL being calculated by entering the PIN, for example, in order to retrieve further information.
  • the optical identifier is preferably a QR code, so that a higher level of data complexity is provided and correspondingly more and/or more complex data can be read out or retrieved.
  • the QR code can also be a link to a specific source where the further information can be retrieved, where the QR code can contain a corresponding random value which has been signed by the central entity (for the purpose of integrity checking by decentralized devices).
  • the unique identifier is not limited to an optical identifier and can additionally or alternatively be an acoustic signal, for example in the non-audible range such as a Ultrasonic range, which is detected by the decentralized device.
  • an audible signal may be preferred so that the user is informed in this way that information is (to be) retrieved.
  • information can be present in the signal, for example by means of modulation, and/or a link can be included in the signal in order to acquire the necessary information.
  • a modulation can also be present in a light signal, which is output, for example, by a display in the form of an optical identifier, in order to provide corresponding information.
  • the required information can also be transmitted by means of device coupling if the central unit transmits the information to a computer unit such as a notebook, for example, which is coupled to the decentralized device such as a user's mobile terminal device.
  • a device pairing enabled or initiated by the user can take place, for example, using NFC or BLE.
  • the identifier can alternatively also be transmitted to the decentralized device via a deep link or universal link.
  • a user can open a mobile service on the end device such as a smartphone and this service can request corresponding user data from the central unit, with the identifier being returned to the decentralized device or smartphone as part of a deep link/universal link.
  • the link can then subsequently be opened by the decentralized device, after which the information required for providing the user data can be retrieved and the user data can be provided on the decentralized device.
  • a QR code or barcode can be displayed, for example in a web service, as described above.
  • Both optical and acoustic transmission as well as transmission via device coupling require the direct, physical presence of the user, so that the security of the authentication and the provision of user data can be further increased.
  • This can also be provided when using a deep link if, for example, a physical key combination or a click by a user on the end device is required to call up the link.
  • the provision of a visual or audible identifier may be particularly preferred, especially since the reading in these cases requires the immediate vicinity of the decentralized device.
  • the information is only provided when a device is coupled when a predetermined or minimum signal strength of the decentralized device is detected. It is thus also possible for the user to be authenticated indirectly.
  • the unique identifier can only be read out by a specific decentralized device or the information can only be called up by a specific decentralized device, with the respective identifier being generated for the respective decentralized device.
  • the information required to provide the requested user data can contain, for example, at least one key for encrypting the user data and/or procedural specifications that are required for authentication and providing the requested user data.
  • protocol specifications and attributes to be provided which are required for the transmission of the user data according to the protocol, can be contained in the information.
  • the information may include attributes such as “nonce”, “iss”, “aud”, “scope”, “claims”, and/or “acr_values”.
  • the information is not limited to these attributes and accordingly may include additional and/or alternative attributes depending on the protocol and required user data.
  • further data with hash values can be provided for transmission to the decentralized device.
  • This data can be queried by the central unit shortly before the creation of the identification token or the "userinfo" by the decentralized device and enables the client to establish a connection between the access token and authorization code that may be required to query the user data during authentication.
  • Capturing the unique identifier may further prompt authentication on the remote device.
  • the decentralized device can for example, verify successful device registration and/or features on the remote device such as jailbreak detection and fingerprint verification and/or face recognition.
  • a device connection can be checked or a multi-instance device check can be carried out. The one or more checks are preferably carried out when the decentralized device is started, for example when an implemented application is started, or during the acquisition of the information, but can also take place at a different point in time, but at the latest before or during a transmission of the requested user data.
  • the user data provided can contain at least one identification token, as can be provided according to the protocol, for example in the case of an authentication request from a client via a central authentication server. This allows identifying information such as a unique username (“subject”) to be requested and entered upon appropriate authentication and authorization. Furthermore, hash values for a code and/or an access token and possibly further user data can be contained in the identification token, so that further user-specific information can be recorded and processed in order to verify the user and, if necessary, to manage the user data.
  • identifying information such as a unique username (“subject”)
  • hash values for a code and/or an access token and possibly further user data can be contained in the identification token, so that further user-specific information can be recorded and processed in order to verify the user and, if necessary, to manage the user data.
  • user data is not limited to a specific type of data.
  • user data such as an e-mail address or date of birth, but also more specific data such as bank details, medical data, health insurance data and/or insurance data can be requested.
  • bank details such as bank details, medical data, health insurance data and/or insurance data
  • the user data in the identification token can also be supplemented with hash values, as described above. These hash values can be queried by the decentralized device using the unique identifier at the central unit shortly before the creation of the identification token or the “userinfo”. These hash values can be used to ensure that the requested user data is accessed once and that a data copy is largely ruled out.
  • an “at_hash”, which is provided for an access token provided by the central entity, and/or “c_hash”, which is provided for an authorization code for requesting the access token and the identification token in the authorization response, is provided for the identification token, which thus pair the identification token with the corresponding code and/or access token.
  • the identification token including the hash values is preferably signed and encrypted, so that these cannot be viewed or changed by the central unit.
  • the identification token can only be decrypted by a service or client that has the key intended for decryption. This can then check the signature of the token and hash values and thus check the integrity of the token and the link to the code and/or access token.
  • the authentication of the user can also include the generation of at least one data packet in addition to the requested user data on the decentralized device, the data packet being signed by the decentralized device when the requested user data is generated and being contained in the identification token.
  • the data packet is thus signed simultaneously with or immediately after the generation of the user data or a specific set of user data with the signature of the decentralized device that is present at the time.
  • the identification token is also provided with a signature of the decentralized device when the requested user data is provided.
  • the service or client that requested the user data can now use the signatures to check the transmitted user data to determine whether the identification token has a valid signature and the user data has a valid signature.
  • the signature of the data packet which occurs when the corresponding user data is created or generated, can also be used to check whether the signature of the data packet corresponds to the signature of the identification token that contains the signed data packet. If these signatures do not match, this can indicate an unauthorized copy and/or transfer of the user data to another decentralized device. Accordingly, the identification token can be checked for correctness and the existence of possible token manipulations can be largely ruled out.
  • authentication may fail and/or the user may be prompted to regenerate the user data or to confirm that the signature of the remote device has changed.
  • the data packet is preferably a crypto token that is contained in the payload of the identification token or the "user info".
  • the data packet can contain random data in addition to a device-specific indicator, so that the data packet can have a predetermined size and unique data, for example.
  • the validity of the identification token can be limited to a specified time, with the decentralized device providing at least one additional identification token before, after or when the specified time has expired.
  • the at least one further identification token can be provided periodically by the decentralized device, depending on a push notification, and/or depending on an at least partially re-authentication of the user.
  • the periodic provision of a further identification token can be provided in the background of an application present on the decentralized device.
  • the decentralized device can, for example, request an access token for the next at hash function at regular and predetermined time intervals, with a new identification token being generated and transmitted to the central unit.
  • Push notifications can also be provided.
  • a client or service can temporarily register for push notifications for a current session. Accordingly, if a new identification token is required, a push message may be sent to the remote device, which processes the request and provides the identification token.
  • the user can be re-authenticated, which can be carried out in a simplified manner if necessary. Accordingly, it can be provided that renewed authentication is always required or this can be initiated, for example, if a corresponding request is received within a background interval.
  • the decentralized device preferably provides a predefined number of identification tokens with different periods of validity.
  • a cache can be present, with tokens such as identification tokens being provided and signed in a bundle, for example between 2 and 10, preferably between 3 and 7 or 5, and having different periods of validity.
  • This temporal validity also known as nbf (in English: “not before"), serves to ensure that tokens cannot be used at any time and possibly misused and, on the other hand, tokens by the number of tokens and the corresponding validity for a given period time to be provided. This means that tokens can be made available in good time, even in the case of delayed push notifications, and any undesired re-authentications can be largely avoided. At the same time, this can improve the energy consumption and the service life of a battery in a decentralized device.
  • a direct logoff of a current session cannot be initiated by the central unit, especially since the central unit has no knowledge of the respective user due to the encryption of the user data and thus cannot assign logoff requests directly to a user.
  • the remote device can cache a session log or session history and either directly interact with logoff components of the central entity or avoid recovery of authentication data.
  • the user preferably selects a current session on the decentralized device, with the decentralized device generating an authentication in order to interact with a logout endpoint of the central unit.
  • the decentralized device can then cause the central unit to terminate the selected session and then terminate any processes that may be present on the decentralized device for re-encrypting this session.
  • a device for selectively providing user data is proposed, the device being a decentralized device with user data of a user stored therein and set up to communicate with a central unit, the device further comprising means for executing the method according to the invention described above.
  • the decentralized device preferably has at least one processor, a main memory, a storage medium and a (wireless) communication module, with the processor and the main memory retrieving or temporarily storing user data stored in the storage medium upon receipt of an authentication request by means of the communication module and after authorization of the user and instructions are executed in order to at least partially encrypt the user data and make it available via the communication module for transmission to the central unit.
  • the communication module can include a WLAN module and/or be compatible with alternative transmission technologies such as 3G, 4G, 5G or Bluetooth.
  • the decentralized device can have an optical and/or acoustic sensor, which is particularly preferably set up to initialize an authentication on the decentralized device, for example as an optical reading device for detecting an optical identifier such as a QR code.
  • the decentralized device can furthermore have an application or implementation which is configured to carry out the device-related method steps of the method according to the invention.
  • the decentralized device is preferably designed as a computer unit, medical device, portable device or mobile end device of a user.
  • the device can thus be a mobile device or smartphone of the user or also a body-hugging, wearable device such as a wearable or smartwatch.
  • the decentralized device can also be embodied as a patient-related medical device, for example as a portable blood pressure measuring device, EKG device, or blood glucose meter.
  • the decentralized device can also be designed as a local, stationary computer or desktop computer or computer unit.
  • a device coupled thereto can be provided in order, for example, to detect an optical identifier emitted by the display, so that the physical presence of the user is still required in order to enable the user to be authenticated.
  • a system for the selective provision of user data which comprises a central unit, preferably an authentication server, and at least one decentralized device as described above.
  • authentication requests can be forwarded via the central unit to a targeted decentralized device and correspondingly requested user data can be provided via the central unit in an encrypted way without the central unit seeing the user data or with a service or client that requires the user data , (bidirectional) can communicate.
  • a computer program product is proposed which comprises instructions which, when the program is executed by a processor, cause the latter to execute the method according to the invention described above.
  • a computer-readable storage medium which comprises instructions which, when executed by a processor, cause the latter to carry out the method according to the invention described above.
  • FIG. 1 is a schematic representation of a process flow according to the invention
  • Figure 2 is a schematic representation of an embodiment of the method of the present invention in a system
  • Figure 3 is a schematic representation of an embodiment for authenticating the user
  • FIG. 4 shows a more detailed schematic illustration of a method sequence according to the invention.
  • FIG. 5 shows an embodiment of an identification token with an additional data packet.
  • FIG. 1 shows a process sequence which is preferably carried out on a decentralized device.
  • certain user data of a user are provided to the user, for example, for a service or on a Identify or authenticate the client.
  • the decentralized device can receive an authentication request from a client, with specific user data present on the decentralized device being requested. According to the method, it is therefore provided that an authentication 100 of the user is carried out. If it is determined that the remote device is the correct user, authorization 200 from the user is required so that the requested user data can be released and the requested user data 300 can be provided.
  • Encryption of user data 302 is also provided when user data 300 is provided, so that the requested user data is provided at least partially in encrypted form. All user data that has been requested is preferably encrypted.
  • the encryption ensures that only an authorized entity can access the user data using a corresponding key and that the user data cannot be viewed even if intercepted by third parties.
  • the provision of the user data 300 can thus optionally also include the transmission of the user data 400 provided, as indicated by the dashed lines, with the requested—and at least partially already encrypted—user data also being able to be transmitted in encrypted form.
  • the point in time of authentication 100 can also be selected after or during authorization 200, so that the user first confirms the release of the requested user data, but these are only provided after authentication 100 has taken place.
  • the authentication 100 can be carried out in parallel in the background, for example. If, for example, an identity of the user or the legitimacy of the use of the user data in the authentication 100 cannot be determined, the provision of the requested user data 300 can be prevented in order to avoid potential misuse.
  • the authentication 100 of the user is to be understood in such a way that the user is identified as an authorized person on the decentralized device, for example by means of a device or application password, fingerprint verification or facial recognition.
  • An authentication request from a client or a service is to be understood in such a way that specific user data is requested in order to enable authentication on the client or for the service or to provide corresponding user data for this purpose.
  • the user data 302 is preferably encrypted using asymmetric keys, it being possible for the keys to be used to be contained in an authentication request.
  • the keys required to decrypt the encrypted user data are only available at the service or client, so that a central unit that transmits the request for the user data and the user data provided cannot view the user data, but can temporarily store it for retrieval. In this way, the method can easily be implemented in existing authentication protocols, which provide a central authentication server, for example.
  • FIGS. 2 to 5 Further optional and/or preferred embodiments of the method according to the invention are shown in FIGS. 2 to 5, these being described for explanation in the context of an authentication protocol such as OpenID Connect and in a corresponding authentication system.
  • an authentication protocol such as OpenID Connect
  • the embodiments should not be construed as being limited to such a protocol, and the optional features can be provided both individually and in combination.
  • FIG. 2 shows a schematic representation of an embodiment of the method according to the invention in a system, with a decentralized device 12 being operated by a user 10 and with a client 16 requesting specific user data via a central unit 14 for authentication.
  • the decentralized device 12 is embodied here as a mobile terminal device, the central unit 14 as a central authentication server and the client 16 as a web browser.
  • the authentication can be initiated by the client 16 sending an authentication request 102 via the web browser, with the authentication request being transmitted 104 to the mobile terminal device via the central authentication server.
  • the transmitted authentication request 104 does not fully match the authentication request 102, but is to be understood as an authentication request, which can contain information for providing the requested user data, both directly and indirectly.
  • the authentication request 102 may contain a client ID, with the central authentication server receiving a public key corresponding to the client ID in the authentication query, with which the decentralized device 12 can encrypt the requested user data. Further information such as protocol specifications can also be transmitted, as will be described below, for example with regard to FIG.
  • An authentication 106 is now initiated on the mobile terminal, which, for example performs an authentication of the user 10 by means of fingerprint detection and/or checks whether the mobile terminal device has not been manipulated, for example by jailbreak attempts.
  • the order is arbitrary, so that this can also take place when an application is started or in the background, but at the latest before the requested user data 300 is provided or before the user data is transmitted 400 .
  • the user 200 can then authorize the authentication request 200 on the mobile device, so that the requested user data is provided and encrypted 300, 302.
  • the key to be used can be specified by the client 16 and defined accordingly in the authentication request 104, as described above, for example as JWKSJJRI.
  • the user data is also signed before encryption 302 so that the origin of the user data can be verified.
  • the user data provided is transmitted in encrypted form to the authentication server 400, with the authentication server transmitting the data in the form of an authorization response via an authorization interface 18 to the client 16 402.
  • the authorization response can be transmitted, for example, by means of a URI redirection ("redirect URF") or via a deep link/universal link previously registered by the client (if the client is on the same mobile device as the decentralized component, for example).
  • the requested user data can be identification data of the user 10, which are required for a login.
  • OIDC OpenID Connect
  • the user data can be defined accordingly as “subject” and, if necessary, as “claims” and “scope”, whereby the user data can be provided by means of a corresponding identification token.
  • an identification token is present in an authorization message in signed and encrypted form and is cached on the authentication server 400.
  • the client 16 can request the identification token accordingly from a token interface 20 of the authentication server, after which the identification token is accordingly sent to the Client 16 is transmitted 406.
  • the identification token can be requested using an authorization code or access token received from the client 16, which was transmitted as part of the authorization response 402.
  • the client 16 can decrypt the identification token accordingly and check the signature to verify the authenticity and origin of the user data and enable a secure login.
  • further user data may optionally be required, which are not contained in the identification token and are also provided in encrypted form by the mobile terminal device and can be present in the authorization message.
  • Such data may be defined by "claims” and "scope” in accordance with the protocol and may be provided as such.
  • This additional user data can be stored in encrypted form as “userinfo” in a user data interface 22 on the authentication server 408 and can be requested 410 by means of a corresponding access token, which is output in encrypted form at the token interface 22 with the appropriate authorization of the client 16.
  • “Claims” can be used more detailed information regarding the requested user data is made possible, whereby certain user data or content is to be provided in "userinfo", but not in the identification token. Restrictions can also be provided in this way, whereby authentication is only successful, for example, if certain values are contained in the "userinfo”.
  • the identification token 412 can optionally be updated, for example in order to extend a current session in the case of time-limited hash functions which are sent with the identification token.
  • Such an update can be provided periodically in the background on the mobile terminal, for example.
  • An update is preferably requested, additionally or alternatively, by means of a push message registration, it also being possible for renewed authentication to be provided if neither a background update nor a push message occurs in good time.
  • further identification tokens can be provided in a row by the mobile terminal and temporarily stored on the authentication server, with the identification tokens being provided with a different respective validity.
  • a possible authentication of the user is shown, which requires a physical presence or proximity.
  • a device connection can be provided (not shown), with the decentralized device 12 generating a device identity and this being registered in a verifiable, confidential and central authority.
  • a User ID are generated, which is accordingly both client-bound and device-bound.
  • the user ID can be a decentralized identifier (DID), which is based on blockchain technology, for example.
  • the present embodiment is based on a representation of a unique optical identifier in the form of a QR code.
  • this QR code is generated by a backend 14A of the central unit or an authentication server and displayed accordingly on the frontend 110, for example on a display of a computer which used by the user for a web browser and login.
  • the user's decentralized device 12 captures the optical identifier or the QR code, for example by means of a camera integrated in the decentralized device 12 .
  • the decentralized device 12 is preferably designed as the user's mobile terminal device and is therefore user-specific, so that the camera function can only be activated after approval by the user, for example by fingerprint verification.
  • the information includes information that is required to provide the requested user data and thus includes protocol specifications in particular.
  • the information may contain appropriate attributes such as wks", “nonce”, “iss”, “aud”, “scope”, “claims”, “acr_values” , code” and/or “token”, where the information are not limited to these attributes and further attributes can be provided
  • the information is preferably signed, whereby the key can be specified as part of the decentralized device or as a JWKS_URI.
  • FIG. 4 shows a more detailed schematic representation of a method sequence according to the invention with further optional and/or preferred functions.
  • the user is first authenticated 100 on the decentralized device 12, for example by means of a device or application password, fingerprint verification and/or facial recognition.
  • a device or application password By reading out an optical identifier generated by the backend 14A of a central unit, required protocol information can be retrieved and processed by the decentralized device 12 subsequently, or alternatively prior to the authentication 100 114, 116.
  • the device binding 118 is also checked, with the decentralized device 12 checking a successful registration with a device or a central service for device binding 46 and/or checking whether the device has not been manipulated.
  • Signing is also provided to provide the requested user data, with a temporary signing key first being generated 304 and then signed 306 by the device binding service 46 and stored 308 in a data memory 44 of the decentralized device 12 .
  • further user data can be provided which, for example, do not include identification data or a login or user name. Accordingly, such user data can be provided, signed with the generated key and then encrypted 310. An identification token is also generated and provided for the user's login, the identification token also being signed with this key and then encrypted 312. According to the figure, a unencrypted identification token stored 314, which can be used for example for update requests. According to the figure, a push notification is registered 316 with a central push notification service 48 for regular updating. A corresponding device token can be transmitted accordingly to the backend 14A of the central unit, for example embedded in an authorization message or authorization response.
  • the provided and encrypted user data is then transmitted and transmitted in the form of an authorization response via the backend 14A of the central unit to the corresponding client, 400, 402.
  • the authorization response contains the signed and encrypted identification token and the signed and encrypted additional user data, which can also be used as “userinfo” are known.
  • a temporary signing key is sent so that the origin of the user data can be checked.
  • the backend 14A of the central unit can update a JWKS 414 so that the client which has requested the user data can retrieve the corresponding signing key.
  • the identification token 24 has both identity data 26 such as a user name or "subject 1 " and other data 28 assigned to the user, such as version backup data or certain "user info". Both the identity data 26 and the associated data 28 are signed with a corresponding key 30 or 32, so that the authenticity and origin of the corresponding user data can be verified.
  • the identification token 24 as such contains a signature 42 of the decentralized device, which was provided with the current key.
  • the signature 42 corresponds to the signature that is present and valid at the time of an authentication request for the decentralized device.
  • it can also be checked from which decentralized device the user data were provided.
  • a respective data packet in the form of a crypto token 34 or 36 is provided in the payload both for the identity data 26 and for the associated data 28 .
  • the respective crypto token 34, 36 contains a device-specific indicator and random data, so that the data packet has a predetermined size and unique data, i. H. non-falsifiable or reusable data.
  • each crypto token 34, 36 contains a signature of the decentralized device, specifically a signature with the key that was valid at the time the user data was generated. In other words, the respective crypto token 34, 36 was generated simultaneously with or immediately after the generation of the respective user data or a specific set of user data and signed with the signature of the decentralized device that was available at the time.
  • the service or client that has requested the user data can now use the signatures to check the transmitted user data to determine whether the identification token 24 has a valid signature 42 and the user data has a valid signature 30, 32.
  • the signature 38, 40 of the crypto token 34, 36 which takes place when generating or generating the corresponding user data, it can also be checked whether the signature of the crypto token 34, 36 of the signature 42 of the identification token 24, wherein the signed Crypto tokens 34, 36 are included, corresponds. If these signatures do not match, this can indicate an unauthorized copy and/or transfer of the user data to another decentralized device. Accordingly, the identification token 24 can be checked for correctness and the presence of possible token manipulations can be largely ruled out. As far as applicable, all individual features that are presented in the exemplary embodiments can be combined with one another and/or exchanged without departing from the scope of the invention.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Automation & Control Theory (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Abstract

Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum selektiven Bereitstellen von Benutzerdaten, insbesondere um einen hinreichenden Datenschutz bei der Übertragung von Benutzerdaten an einen Client bereitzustellen. Entsprechend wird ein computerimplementiertes Verfahren zum selektiven Bereitstellen von Benutzerdaten vorgeschlagen, umfassend die Schritte: - Authentifizieren (100) eines Benutzers (10); - Autorisieren (200) einer Bereitstellung von mittels einer zentralen Einheit (14) angeforderten Benutzerdaten des Benutzers (10); und - Bereitstellen (300) der angeforderten Benutzerdaten zum Übertragen an die zentrale Einheit (14). Das Autorisieren (100) und das Bereitstellen (300) der angeforderten Benutzerdaten erfolgt dabei mittels einer dezentralen Vorrichtung (12), wobei das Bereitstellen (300) der angeforderten Benutzerdaten das Verschlüsseln (302) von auf der dezentralen Vorrichtung (12) gespeicherten Benutzerdaten umfasst.

Description

Dezentrale Bereitstellung von Benutzerdaten
Technisches Gebiet
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum selektiven Bereitstellen von Benutzerdaten, insbesondere um einen hinreichenden Datenschutz bei der Übertragung von Benutzerdaten an einen Client bereitzustellen.
Stand der Technik
Um bestimmte Dienste wie webbasierte oder mittels einer Applikation bereitgestellte Dienste zu bedienen oder erst zu ermöglichen, können Benutzerdaten erforderlich sein, um somit sicherzustellen, dass Zugriff auf bestimmte Dienste für eine dazu befugte Person gewährt wird. So kann beispielsweise mithilfe eines Clients wie eines Browsers ein Login für einen Benutzer bereitgestellt sein, um bestimmte Benutzerdaten anzufordern, zu verwalten und/oder anzupassen. Die Benutzerdaten können angefordert werden, um einen Benutzer zu authentifizieren und einzelne Dienste nur dann freizuschalten, wenn ein konkreter Benutzer mit einer hinreichenden Validität festgestellt werden kann.
Die Sicherheit des Diensts wird somit erhöht, zumal unberechtigte Zugriffe weitestgehend vermieden werden können.
Die Anforderung von Benutzerdaten bietet einem Benutzer ebenfalls die Möglichkeit eine gewisse Kontrolle über die Bereitstellung der Benutzerdaten auszuüben, sodass diese nur bei entsprechender Autorisierung des Benutzers für einen bestimmten Dienst bereitgestellt werden können.
Bei den Benutzerdaten kann es sich um eine Vielzahl von Daten handeln, wobei diese zumindest teilweise selbstgewählt, beispielsweise im Falle eines Benutzernamens oder E-Mailadresse, oder auch personengebunden, beispielsweise im Falle eines Geburtsdatums, eines Geburtsorts oder einer Wohnadresse, sein können. Weiterhin können die Benutzerdaten von einer Hoheitsinstanz zugeordnete Daten und/oder zentralvergebene Daten enthalten. So können beispielsweise Personalausweisnummer bzw. Versicherungsnummer oder Bankkontonummer vergeben werden, welche einer bestimmten Person zugeordnet werden können. Die Benutzerdaten können somit sensible Daten enthalten.
Ein unerlaubter Zugriff auf Benutzerdaten durch Dritte kann mithin ein potenzielles Risiko für den betreffenden Benutzer darstellen. Die Authentifizierung kann dabei beispielsweise durch Hackversuche, Phishing oder auch durch softwarebezogene Änderungen beeinträchtigt werden. Entsprechend können für Dienste, die Benutzerdaten anfordern, Identitätsmanagementdienste vorgesehen sein, welche die Authentifizierung des Benutzers verifizieren und eine Autorisierung seitens des Benutzers ermöglichen.
Eine Möglichkeit zur Authentifizierung ist eine dienstbezogene Authentifizierung und Hinterlegung von Benutzerdaten. Mit anderen Worten findet auf diese Weise eine Identifizierung eines Benutzers durch bzw. für den jeweiligen Dienst statt und es werden beispielsweise entsprechende Anmeldedaten für die zukünftige Verwendung dieses Diensts bereitgestellt und hinterlegt. Solche für die Authentifizierung zuständige Identitätsmanagementsysteme werden für den jeweiligen Dienst entwickelt und agieren grundsätzlich unabhängig von anderen Diensten. Für sowohl den Dienst als auch den Benutzer muss dabei berücksichtigt werden, dass die Zugriffsverwaltung sowie die implementierten Verfahren zum Verarbeiten von Identitäten hinreichend sicher gestaltet sind. Wenn diese Funktionen nicht zum Kerngeschäft eines Unternehmens gehören, können eine entsprechende Implementierung und Erhaltung solcher Funktionen und Sicherheitsaspekte kostspielig sein und es kann ein erhöhtes Risiko auf Implementierungsfehler vorliegen.
Für den Benutzer bedeutet ein solches Authentifizierungsverfahren zudem, dass für jeden Dienst eine separate und ggf. unterschiedliche Authentifizierung erfolgen muss, was für den Benutzer als umständlich, unangenehm und/oder verwirrend empfunden werden und die Erfolgschance einer vollständig und korrekt ausgeführten Authentifizierung reduzieren kann.
Weiterhin müssen Benutzerdaten für jeden Dienst mehrmals hinterlegt oder sogar erzeugt werden. So können für jeden Dienst jeweilige Anmeldedaten, Benutzerdaten und/oder Identitäten erforderlich sein, welche ggf. mit unterschiedlichen Zeitabständen jeweils aktualisiert werden müssen. Wenn ein Benutzer mehrere dienstspezifische Daten wie Anmeldedaten verwalten muss, ist die Wahrscheinlichkeit einer Wiederverwendung solcher Daten seitens des Benutzers generell erhöht. Sollte beispielsweise ein Kennwort mehrmals für unterschiedliche Dienste durch den Benutzer verwendet werden, so besteht das Risiko, dass beispielsweise ein Datenleck eines Diensts die Datenintegrität anderer Dienste gefährdet. Ein alternatives Authentifizierungsverfahren sieht vor, dass Benutzerdaten wie eine Identität oder Anmeldedaten eines Benutzers für einen spezifischen Dienst oder Client zentral gespeichert bzw. bereitgestellt werden. Solche Verfahren basieren auf standardisierten Protokollen wie beispielsweise OAuth, OpenID oder SAML und bieten die Identifizierung, Authentifizierung und Autorisierung als Leistungen oder Funktionen an für jeweilige Dienste oder Clients. Diese Funktionen sind in einem zentralen System wie beispielsweise ein zentraler Authentifizierungsserver vorhanden und stehen Diensten bzw. Clients entsprechend zur Verfügung, um angeforderte Benutzerdaten bei entsprechender Autorisierung bereitzustellen.
Auf diese Weise kann die Authentifizierung für den Benutzer dadurch erleichtert werden, dass diese durch eine zentrale Einheit durchgeführt wird und die Anzahl verschiedener Authentifizierungsverfahren bzw. Authentifizierungssysteme für verschiedene Dienste entsprechend geringer ist. Die Sicherheit der Benutzerdaten wird durch die Bereitstellung auf einer zentralen Einheit jedoch reduziert, zumal Benutzerdaten eines Benutzers für eine Vielzahl von Diensten bereitgestellt werden können und somit bei einem potenziellen zentralen Angriff durch Dritte erfasst werden könnten. Dies gilt insbesondere dann, wenn der Benutzer für verschiedene Dienste dieselben Anmeldedaten verwendet. Entsprechend sind nicht nur Benutzerdaten unterschiedlicher Benutzer, sondern auch unterschiedliche Benutzerdaten eines Benutzers potenziell gefährdet.
Weiterhin sind die Benutzerdaten für die zentrale Einheit bzw. den Authentifizierungsserver einsehbar, wodurch eine potenziell hohe Anzahl an Benutzerdaten eines einzelnen Benutzers in einem System vorhanden ist. Bei Missbrauch oder unerlaubter Verwendung dieser Daten können beispielsweise sehr spezifische Datenprofile des Benutzers erstellt werden, welche die Privatsphäre des Benutzers erheblich beeinträchtigen.
Anstatt einer dienstbezogenen oder zentralen Authentifizierung kann die Authentifizierung ebenfalls durch den Benutzer selbst veranlasst werden. Benutzerdaten können auf diese Weise eine dezentrale Identität oder Selbstbestimmte Identität (auf Englisch „self-sovereign identity" oder SSI) und beispielsweise verifizierbare Anmeldedaten und eindeutige Kennungen generieren. Dezentrale Identifikatoren (auf Englisch „decentralized identifiers" oder DIDs) können beispielsweise mittels Blockchaintechnologie erzeugt und in einem Blockchain-Netzwerk hinterlegt werden, um eine unabhängige Prüfung der Validität überprüfen zu lassen. Das Signieren und Verschlüsseln solcher Technologien erhöht den Sicherheitsfaktor und die Verwendung von z. B. eindeutigen Kennungen für jedes System bzw. jeden Dienst oder Client bewirkt, dass eine Datenprofilierung beim Abfangen der Daten durch Dritte nicht möglich ist. Obwohl die Sicherheit der Benutzerdaten durch eine Selbstbestimmte Identität oder dezentrale Identität verbessert wird, sind Implementierungen solcher Identitäten nicht unmittelbar kompatibel mit Authentifizierungsverfahren, welche eine zentrale Einheit wie einen Authentifizierungsserver verwenden bzw. benötigen. Ebenfalls schließt dies Authentifizierungen und Erzeugung von Kennungsdaten durch einen Dienst oder Client grundsätzlich aus. Für den Benutzer kann eine umfangreiche Änderung des Authentifizierungsverfahrens zudem als störend empfunden werden, da dieser in einem solchen Fall auf Selbstbestimmte Identitäten oder SSI migrieren müsste.
Entsprechend besteht ein Bedarf, ein hinreichender Schutz von Benutzerdaten bei einer Kompatibilität mit bestehenden Authentifizierungssystemen zu ermöglichen.
Darstellung der Erfindung
Ausgehend von dem bekannten Stand der Technik ist es eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zum selektiven Bereitstellen von Benutzerdaten, sowie eine entsprechende Vorrichtung bereitzustellen.
Die Aufgabe wird durch ein computerimplementiertes Verfahren mit den Merkmalen des Anspruchs 1 gelöst. Vorteilhafte Weiterbildungen ergeben sich aus den Unteransprüchen.
Entsprechend wird ein computerimplementiertes Verfahren zum selektiven Bereitstellen von Benutzerdaten vorgeschlagen, umfassend die Schritte:
Authentifizieren eines Benutzers;
Autorisieren einer Bereitstellung von mittels einer zentralen Einheit angeforderten Benutzerdaten des Benutzers; und
Bereitstellen der angeforderten Benutzerdaten zum Übertragen an die zentrale Einheit.
Erfindungsgemäß erfolgt das Autorisieren und das Bereitstellen der angeforderten Benutzerdaten mittels einer dezentralen Vorrichtung, wobei das Bereitstellen der angeforderten Benutzerdaten das Verschlüsseln von auf der dezentralen Vorrichtung gespeicherten Benutzerdaten umfasst.
Durch die Verschlüsselung von Benutzerdaten können diese nur von einer Instanz entschlüsselt werden, welcher der entsprechende Schlüssel bekannt ist, sodass diese nicht für unberechtigte Dritte einsehbar sind. Beispielsweise kann ein Dienst oder Client Anmeldedaten bzw. Kenndaten eines bestimmten Benutzers für einen Login erfordern und die entsprechenden Benutzerdaten bei einer zentralen Einheit wie einem Authentifizierungsserver anfordern. Auf der dezentralen oder lokalen Vorrichtung können die entsprechenden Benutzerdaten dann beim Erhalt einer entsprechenden Anfrage zumindest teilweise verschlüsselt und zum Übertragen an die zentrale Einheit bereitgestellt werden. Dadurch, dass die zentrale Einheit, welche übertragene Benutzerdaten anschließend an den Dienst bzw. Client weiterleitet, im Gegensatz zum Dienst bzw. Client nicht über den Schlüssel zum Entschlüsseln der verschlüsselten Benutzerdaten verfügt, können diese Benutzerdaten nicht von der zentralen Einheit eingesehen und/oder verwertet werden.
Auf diese Weise kann eine sichere, verschlüsselte Übertragung der angeforderten Benutzerdaten bereitgestellt werden, sodass beispielsweise das Abfangen einer Identität oder eine Datenprofilierung oder Datamining durch unberechtigte Dritte weitestgehend vermieden werden können. Die Bereitstellung der Benutzerdaten erfolgt weiterhin selektiv nach entsprechender Autorisierung seitens des Benutzers und nur für die angeforderten Benutzerdaten, sodass die sichere Verwendung und Bereitstellung der Benutzerdaten weiter verbessert werden kann.
Weiterhin Ist eine solche Bereitstellung von Benutzerdaten vollständig kompatibel mit bestehenden Authentifizierungsprotokollen, welche auf einer zentralen Einheit wie einem Authentifizierungsserver bzw. zentralen Authentifizierungsdienst basiert sind. Beispiele solcher Protokolle sind SAML, O- Auth, OAuth2 und OpenID Connect. Ein Dienst oder Client kann beispielsweise ein Webdienst oder Browserfunktion sein, welche bestimmte Benutzerdaten wie einen eindeutigen Login und ggf. weitere persönliche Benutzerdaten eines Benutzers erfordert. Ein solcher Login oder Benutzername ist in den vorstehenden Protokollen auch bekannt als „subject", während bestimmte Benutzerdaten als „userinfo“ bekannt sind und durch bestimmte Ansprüche und Bereiche, auch bekannt als „Claims“ bzw. „scope“, definiert werden. Bei einem standardgemäßen Protokoll wie OpenID Connect können der Benutzername und eine optionale Anzahl von Benutzerdaten mittels eines Identifizierungstokens und ggf. weitere bzw. bestimmte Benutzerdaten oder „userinfo“ mittels eines Zugriffstokens bei entsprechender Autorisierung zentral bereitgestellt werden, wobei diese Tokens entsprechend in einem zentralen Authentifizierungsdienst bzw. Authentifizierungsserver zwischengespeichert sind.
Mit anderen Worten können für den Client erforderliche (wichtige) Benutzerdaten, ggf. alle erforderliche Benutzerdaten, bereits im Identifizierungstoken vorhanden sein und es können ggf. weitere Benutzerdaten mittels eines Zugriffstokens übermittelt bzw. abgeholt werden, sodass ggf. genauer definierte Benutzerdaten als „userinfo“ von einem Client empfangen werden können. Solche Identifizierungstokens und userinfo können gemäß der Erfindung jedoch auf der dezentralen Vorrichtung generiert und bereitgestellt werden, wobei diese als Teil der Bereitstellung verschlüsselt werden. Die entsprechenden - verschlüsselten - Benutzerdaten bzw. Tokens können dabei zudem verschlüsselt übertragen, beispielsweise mittels SSL, und sogar auf der zentralen Einheit zwischengespeichert werden. Die Tokens können somit protokollgemäß an den Dienst übermittelt werden, der die Benutzerdaten angefordert hat, ohne dass die Daten für die zentrale Einheit einsehbar sind. Denn der zur Entschlüsselung erforderliche Schlüssel liegt der zentralen Einheit nicht vor, sodass die Benutzerdaten nur durch den Dienst entschlüsselt und eingesehen werden können, der die Benutzerdaten angefordert hat und den entsprechenden Schlüssel enthält. Durch das Zwischenspeichern der (verschlüsselten) Benutzerdaten bzw. Tokens und die entsprechenden Übertragungen kann die zentrale Einheit jedoch derart funktionieren und nach Außen interagieren, wie dies protokollgemäß vorgesehen sein kann, sodass die Verschlüsselung und dezentrale Bereitstellung der Benutzerdaten mit einem entsprechenden Protokoll kompatibel ist.
Die angeforderten Benutzerdaten können weiterhin unterschiedliche Benutzerdaten enthalten, welche für den Benutzer mehr oder weniger relevant sind. Beispielsweise können die Benutzerdaten personengebundene Daten oder auch von einer zentralen Instanz ausgegebene Daten enthalten, welche entsprechend sensibel sind und wobei Missbrauch dieser Daten schwerwiegendere Folgen für den Benutzer haben kann. Entsprechend kann vorgesehen sein, dass nur bestimmte Benutzerdaten, welche einer vorgegebenen Datenkategorie zugeordnet werden, zur Bereitstellung verschlüsselt werden. So können beispielsweise nur in einem Payload enthaltene sensible Benutzerdaten verschlüsselt werden. Dadurch können nicht verschlüsselte Benutzerdaten schneller verwendet und verschlüsselte Benutzerdaten beispielsweise zu einem späteren Zeitpunkt zur Verwendung entschlüsselt werden.
Bevorzugt werden jedoch alle der bereitgestellten Benutzerdaten verschlüsselt. Somit wird sichergestellt, dass keine der Benutzerdaten abgefangen werden können und/oder versehentlich sensible Benutzerdaten unverschlüsselt hinzugefügt und übertragen werden.
Um die Verschlüsselung und Entschlüsselung zu unterstützen, kann weiterhin vorgesehen sein, dass ein symmetrischer Schlüssel verwendet wird. Ein solcher Schlüssel kann beispielsweise einem die Benutzerdaten anfordernden Dienst oder Client zum Entschlüsseln vorliegen bzw. darin gespeichert sein. Entsprechend kann das Verschlüsseln mittels symmetrischer Schlüssel erfolgen, wobei optional eine Schlüsselrotation in vorgegebenen Zeitabständen vorgesehen sein kann. Ebenfalls können für die Verschlüsselung zuständige Applikationsteile auf der dezentralen Vorrichtung in vorgegebenen Zeitabständen ausgetauscht werden. Somit kann die Wahrscheinlichkeit, dass eventuell durch Dritte abgefangene Schlüssel bei zukünftiger Übertragung von bereitgestellten Benutzerdaten eine Entschlüsselung ermöglichen, verringert werden.
Alternativ kann das Verschlüsseln mittels asymmetrischer Schlüssel erfolgen. Somit kann eine zwischenzeitliche Interpretierung der verschlüsselten Benutzerdaten durch Dritte weitestgehend ausgeschlossen werden. Dabei kann ebenfalls eine vorstehend beschriebene Schlüsselrotation vorgesehen sein, um das Risiko einer Verwendung von eventuell kompromittierten Schlüsseln weiter zu verringern. Unabhängig von der Schlüsselsymmetrie können die bereitgestellten Benutzerdaten durch das Verschlüsseln ebenfalls verschlüsselt an die zentrale Einheit übertragen werden.
Die Größe der angeforderten Benutzerdaten kann weiterhin beim Verschlüsseln nach einem vorgegebenen kryptographischen Standard aufgefüllt werden. Das Auffüllen (im Englischen „padding“) bewirkt, dass die Größe der bereitgestellten Benutzerdaten, beispielsweise der Payload der zu übertragenden Daten, immer gleich ist, sodass Größenschwankungen der angeforderten Benutzerdaten als solche keine Möglichkeit zur Dateninterpretierung oder Datenprofilierung bieten. Das Auffüllen wird bevorzugt nach PKCS#1 ausgeführt, kann jedoch ebenfalls mittels anderen Protokollen oder Standards erfolgen. Grundsätzlich können die Verschlüsselung und/oder das Auffüllen ebenfalls mittels von einem Standard abweichenden Verschlüsselungsmethoden und entsprechenden eigens entwickelten Algorithmen (sogenannte „self-made encryption") erfolgen, solange diese von einem Protokoll, das durch die zentrale Einheit verwendet wird, unterstützt werden.
Eine Authentifizierung der Benutzerdaten und Sicherstellung der Herkunft kann weiterhin zumindest teilweise durch Signieren der bereitgestellten Daten vor dem Verschlüsseln erreicht werden. Dabei kann ein öffentlicher Signierschlüssel der dezentralen Vorrichtung bereitgestellt werden. Beispielsweise können öffentliche Signierschlüssel mehrerer dezentraler Vorrichtungen als Teil von JWKS („JSON Web Key Sets“), welche beispielsweise in Protokollen wie OAuth2 und OpenID Connect implementiert ist, integriert sein. Dazu können die zentrale Einheit bzw. ein Authentifizierungsserver eine Datenbank mit allen öffentlichen Schlüsseln der dezentralen Vorrichtungen erzeugen. Um auch bei einer hohen Anzahl von öffentlichen Schlüsseln ein rasches Abrufen der benötigten öffentlichen Schlüssel zu ermöglichen, können weiterhin Abfrageparameter vorgesehen sein, beispielsweise in einem URI („uniform resource identifier") des JWKS, sodass der zu verwendende Schlüssel spezifiziert werden kann.
Gemäß einer bevorzugten Alternative ist vorgesehen, dass der öffentliche Schlüssel dynamisch bereitgestellt wird, besonders bevorzugt mittels einer von der dezentralen Vorrichtung bereitgestellten Autorisierungsantwort. Der öffentliche Schlüssel kann beispielsweise durch dynamisches Aktualisieren des JWKS bereitgestellt werden. In einer solchen Ausführungsform kann die zentrale Einheit vorsehen, dass der JWKS URI nicht zwischengespeichert wird. Dadurch ist erforderlich, dass ein Dienst oder Client den vollständigen JWKS bei jeder Authentifizierung oder Benutzerdatenanforderung erneut abruft. Dabei kann die dezentrale Vorrichtung einen aktuellen Schlüssel in einer Autorisierungsantwort an die zentrale Einheit übertragen, welche die Autorisierungsantwort an den Dienst oder Client, der die Benutzerdaten anfordert, übermittelt. Wenn der Dienst die Autorisierungsantwort erhält, kann dieser den aktuellen JWKS von dem JWKS URI, welcher nun den entsprechenden Schlüssel enthält, verlangen. Bevorzugt wird der aktuelle Schlüssel zusammen mit Verifizierungsinformationen wie einem Zertifikat, beispielsweise einer Verbindung mit einem Geräteanbindungsdienst oder einem FIDO2-Server, bereitgestellt, um somit die Echtheit und Vertrauenswürdigkeit des aktuellen Schlüssels zu bescheinigen.
In einer bevorzugten Ausgestaltung ist die zentrale Einheit ein zentraler Authentifizierungsserver, welcher das Authentifizieren des Benutzers in Reaktion auf mindestens eine empfangene Authentifizierungsanfrage eines Clients veranlasst und die bereitgestellten Benutzerdaten an den Client übermittelt.
Wie vorstehend beschrieben, können solche Authentifizierungsserver oder Authentifizierungsdienste ein bestimmtes Protokoll wie OpenID Connect vorsehen, wobei ein Client zur Authentifizierung eines Benutzers bestimmte Benutzerdaten erfordert, um beispielsweise ein Login eines Benutzers mittels eines Webbrowsers zu ermöglichen. Es ist jedoch keine direkte Kommunikation bzw. bidirektionale Kommunikation zwischen dem Authentifizierungsserver und einem Client vorgesehen, zumal der Authentifizierungsserver den Client nicht kennt und Anforderungen somit nur vom Client ausgehend in Richtung des Authentifizierungsservers erfolgen.
Mit anderen Worten erfolgt das Authentifizieren des Benutzers und auch das Übermitteln der bereitgestellten Benutzerdaten bevorzugt nur in Reaktion auf die initiierende Authentifizierungsanfrage. Das Übermitteln der bereitgestellten Daten kann dabei durch Umleitung mittels eines in der Authentifizierungsanfrage enthaltenen URI erfolgen.
Alternativ kann die zentrale Einheit bzw. der Authentifizierungsserver jedoch auch eine Authentifizierungsantwort bzw. Autorisierungsantwort mittels sogenannter „Traps“ oder „Callbacks“ bzw. „Webhooks“ übermitteln, wobei in einem solchen Fall eine aktive Kommunikation zumindest vorübergehend vorhanden sein kann. Die zentrale Einheit kann beispielsweise eine direkte Nachricht übersenden, wenn ein bestimmtes Ereignis eingetreten ist. Bevorzugt ist mindestens ein Schlüssel, der zum Verschlüsseln der angeforderten Benutzerdaten erforderlich ist, in einer Authentifizierungsanfrage, welche von der dezentralen Vorrichtung empfangen wird, enthalten. Alternativ könnte dieser Schlüssel auch bereits vorab der dezentralen Vorrichtung außerhalb der Authentifizierungsanfrage übermittelt worden sein oder noch beständig vorliegen, beispielsweise aus einer vorherigen Authentifizierungsanfrage, die demselben Client zugeordnet ist. Der mindestens eine Schlüssel kann entsprechend nicht festgelegt oder zeitlich begrenzt gültig sein und beispielsweise bei weiteren Authentifizierungsanfragen ausgetauscht werden. Bevorzugt werden zum Verschlüsseln und Entschlüsseln mehrere Schlüssel verwendet, welche asymmetrisch sind, sodass die verschlüsselten Benutzerdaten selbst beim Abfangen durch Dritte, beispielsweise die zentrale Einheit, nicht interpretiert werden können. Weiter bevorzugt ist eine Schlüsselrotation vorgesehen.
Gemäß den vorgenannten Protokollen, wobei ein Dienst oder Client eine Authentifizierungsanforderung an eine zentrale Einheit wie einen Authentifizierungsserver übermittelt, kann ein Client die zu verwendenden Schlüssel vorgeben und in der Authentifizierungsanforderung beispielsweise als Teil einer dynamischen Clientregistrierung oder als JWKS oder eines JWKS URI definieren. Alternativ kann der Client den mindestens einen zu verwendenden Schlüssel auch außerhalb der Protokolle („Out-of-Band“) der dezentralen Vorrichtung übermitteln bzw. die dezentrale Vorrichtung den zu verwendenden mindestens einen Schlüssel direkt vom Client empfangen. Somit würde die Profilbildung seitens zentraler Einheit zusätzlich erschwert werden, da die zentrale Einheit keine Kenntnis über den Verschlüsselungsschlüssel des Clients erlangt. Die Schlüssel enthalten bevorzugt einen entsprechenden Header, sodass die dezentrale Vorrichtung, welche die Schlüssel empfängt, die Integrität der bzw. des jeweiligen Schlüssels verifizieren kann. Beispielsweise können die eine oder mehrere Schlüssel beim Übertragen einen x5c oder x5u Header nach einem RFC 7517 Standard umfassen.
Nachdem der mindestens eine Schlüssel übertragen und von der dezentralen Vorrichtung empfangen wurde, kann eine Verifizierung durch die dezentrale Vorrichtung erfolgen. Beispielsweise kann gemäß einem der vorstehend beschriebenen Protokollen vorgesehen sein, dass der JSON Web Key (JWK) gemäß einem RFC Standard ist und ein ggf. mitgeliefertes Zertifikat von einer Instanz signiert wurde, welche vom entsprechenden Client als vertrauenswürdig eingestuft ist. Eine solche Instanz kann beispielsweise extern oder auch in der dezentralen Vorrichtung, bevorzugt als Applikationskomponente oder als selbständige Applikation, hinterlegt sein. Alternativ kann ebenfalls eine zentrale Zertifikatsverwaltung vorgesehen sein, welche beispielsweise betriebssystemgebunden ist und worin Schlüssel vertrauenswürdiger Instanzen hinterlegt werden können. In einer alternativen Ausführungsform kann der mindestens eine Schlüssel ebenfalls in der dezentralen Vorrichtung vorliegen und gespeichert und beispielsweise bei Auslieferung der dezentralen Vorrichtung oder einer Applikation auf der dezentralen Vorrichtung bereitgestellt sein. Optional kann dabei vorgesehen sein, dass der mindestens eine Schlüssel in einer zukünftigen Authentifizierungsanfrage enthalten ist.
In jedem Fall kann die dezentrale Vorrichtung sobald der mindestens eine Schlüssel vorliegt angeforderte Benutzerdaten entsprechend verschlüsseln und protokollgemäß an die zentrale Einheit übertragen.
Um die angeforderten Benutzerdaten zu übermitteln, kann die dezentrale Vorrichtung in Reaktion auf eine Authentifizierungsanfrage eine Autorisierungsantwort bereitstellen, welche die bereitgestellten Benutzerdaten enthält. Mit anderen Worten kann der Benutzer die empfangene Anforderung, beispielsweise von einem Client, bei einer entsprechenden Authentifizierung an der dezentralen Vorrichtung autorisieren, wobei die bereitgestellten Benutzerdaten in einer entsprechenden Antwort enthalten sind. Eine solche Autorisierungsantwort kann protokollgemäß vorgesehen sein, wie beispielsweise in OpenID Connect. Der Begriff „Bereitstellen“ kann generell so zu verstehen sein, dass dies nicht nur die lokale bzw. dezentrale Verschlüsselung von Benutzerdaten, sondern ebenfalls das Übertragen der angeforderten Benutzerdaten beinhalten kann, sodass eine verschlüsselte Übertragung der Autorisierungsantwort als Teil des Verfahrens vorgesehen sein kann.
Die bereitgestellten Benutzerdaten können dabei nicht nur unmittelbar, sondern zumindest teilweise in Form eines Tokens in der Autorisierungsantwort vorhanden sein. In der Autorisierungsantwort kann somit ein Identifizierungstoken vorhanden sein, womit unter anderem ein Benutzername bzw. weitere Benutzerdaten wie eine E-Mailadresse übermittelt werden können. Weiterhin können im Identifizierungstoken (verschlüsselte) Hashwerte für einen Code und/oder für ein Zugriffstoken, welche von der zentralen Einheit bereitgestellt werden, vorhanden sein. Die dezentrale Vorrichtung kann entsprechend sogenannte c hash bzw. at hash Elemente für den Code bzw. das Zugriffstoken generieren und im Identifizierungstoken aufnehmen. Die Tokens können dabei auf der zentralen Einheit zwischengespeichert werden und einem Dienst oder Client, der die Benutzerdaten anfordert, bei Übermittlung des entsprechenden Hashwerts zur Verfügung gestellt werden. Durch die Verschlüsselung der bereitgestellten Benutzerdaten und verschlüsselte Übertragung sind die Benutzerdaten jedoch nicht durch die zentrale Einheit einsehbar. Auf diese Weise können vorgesehene Protokollabläufe eingehalten werden, ohne dass die Sicherheit der bereitgestellten Benutzerdaten dabei beeinträchtigt wird. Die bereitgestellten Benutzerdaten enthalten bevorzugt ein eindeutiges Identifizierungskennzeichen, bevorzugt in Form einer dezentral oder zentral erzeugten Kennung. Ein Identifizierungskennzeichen wie ein Loginname oder subject sollte dabei eindeutig sein, sodass eine Doppelbelegung vermieden wird. Beispielsweise kann ein Identifizierungskennzeichen in Form eines dezentralen Identifikators (DID), welcher mittels Blockchaintechnologie generiert wurde, vorliegen oder kann bei hinreichender Entropie eines dezentralen Algorithmus auch als Hashfunktion bereitgestellt sein.
Das Identifizierungskennzeichen kann auch von einer zentralen Instanz ausgegeben oder validiert sein. So kann eine Hoheitsinstanz einer Person bzw. einem Benutzer beispielsweise eine eindeutige bzw. einmal vergebene Personalausweisnummer zugeordnet haben, sodass eine Person mit dieser Nummer als Identifizierungskennzeichen eindeutig identifiziert werden kann. Eine zentrale Freigabe und Zuordnung eines Identifizierungskennzeichens kann auch durch eine Instanz erfolgen, welche die Eindeutigkeit eines selbstbestimmten Identifizierungskennzeichens überprüft. So kann beispielsweise eine selbstgewählte E-Mailadresse während einer Registrierung bei einem Provider dahingehend überprüft werden, ob diese noch nicht vergeben und entsprechend keinem anderen Benutzer zugeordnet wurde.
Die sensiblen Benutzerdaten können dabei an die zentrale Einheit übermittelt werden, wobei die Verschlüsselung der Benutzerdaten und eine bevorzugte, zusätzliche verschlüsselte Übertragung sicherstellen, dass zumindest das Identifizierungskennzeichen nicht durch Dritte einsehbar ist.
Weiterhin können die auf der dezentralen Vorrichtung gespeicherten Benutzerdaten, alternativ oder zusätzlich, zumindest teilweise an der dezentralen Vorrichtung gebunden sein. Um sicherzustellen, dass die Benutzerdaten nicht manipuliert wurden, können die Echtheit und die Zugehörigkeit dieser auf der dezentralen Vorrichtung vorliegenden Benutzerdaten bei einer von der dezentralen Vorrichtung ausgehenden Authentifizierung überprüft werden.
So kann die dezentrale Vorrichtung bei einer zentralen Instanz registriert werden, wobei beispielsweise eine Seriennummer oder Fertigungsnummer hinterlegt werden. In einem solchen Fall kann es bereits ausreichen, dass dies für die Echtheit und Zugehörigkeit der Benutzerdaten erfolgt ist, zumal einfache Benutzerdatenkopien keine entsprechenden Registrierungsdaten umfassen. Zusätzlich können Gerätemanagementfunktionen vorgesehen sein, wobei die Registrierung mit einem Identifikator erfolgt oder einer bestimmten Person zugeordnet wird.
Um die Plausibilität der Echtheit und Zugehörigkeit der Benutzerdaten weiter zu erhöhen, können zusätzlich oder alternativ ebenfalls weitere Funktionen überprüft und implementiert werden. So kann eine Funktion vorgesehen sein, welche einen Manipulationsschutz bereitstellt und/oder Jailbreakversuche detektiert bzw. feststellt. Somit können eventuelle Software- und Datenmanipulationen weitestgehend ausgeschlossen werden. Ebenfalls können weitere personengebundene Funktionen wie Fingerabdruckbestätigung für die Authentifizierung vorgesehen sein, sodass die Authentifizierung grundsätzlich eine physische Anwesenheit des Benutzers erfordert.
Weiterhin können Funktionen vorgesehen sein, welche eine Gerätebindung und/oder mehrinstanzli- che Überprüfung der Echtheit erfordern, beispielsweise mittels Blockchaintechnologie. Auf diese Weise kann sichergestellt werden, dass nur vertrauenswürdige Geräte den Benutzerdaten bzw. einer bestimmten Identität zugeordnet werden können.
Um das Authentifizieren des Benutzers und das Bereitstellen bzw. Übertragen der Benutzerdaten zu vereinfachen, kann das Authentifizieren des Benutzers das Erfassen eines von der zentralen Einheit ausgegebenen eindeutigen Kennzeichens, bevorzugt eines optischen oder akustischen Kennzeichens, durch die dezentrale Vorrichtung umfassen, wobei die dezentrale Vorrichtung durch das Erfassen Informationen erhält, welche zum Bereitstellen der angeforderten Benutzerdaten erforderlich sind.
Das Kennzeichen kann beispielsweise ein optisches Element wie ein Barcode oder QR-Code sein, der bei einer empfangenen Authentifizierungsanfrage eines Diensts oder Clients auf einem Display oder Monitor dargestellt werden kann. Wenn ein Benutzer beispielsweise am Rechner einen Web- dlenst öffnet und dieser entsprechend Benutzerdaten anfordert, kann die zentrale Einheit das optische Element darstellen, welches anschließend mittels von einer Ausleseeinheit der dezentralen Vorrichtung ausgelesen werden kann. Das optische Element kann auch eine numerische Wiedergabe eines PINs sein, wobei durch die Eingabe des PINs beispielsweise ein URL errechnet, um die weiteren Informationen abzurufen.
Bevorzugt ist das optische Kennzeichen ein QR-Code, sodass eine höhere Datenkomplexität bereitgestellt und entsprechend mehr und/oder komplexere Daten ausgelesen bzw. abgerufen werden können. Der QR-Code kann weiterhin ein Link zu einer bestimmten Quelle sein, wo die weiteren Informationen abgerufen werden können, wobei der QR-Code einen entsprechenden Zufallswert enthalten kann, welcher von der zentralen Einheit (zum Zwecke der Integritätsprüfung seitens dezentraler Vorrichtung) signiert wurde.
Das eindeutige Kennzeichen Ist nicht auf ein optisches Kennzeichen beschränkt und kann zusätzlich oder alternativ ein akustisches Signal sein, beispielsweise im nicht-hörbaren Bereich wie ein Ultraschallbereich, welches von der dezentralen Vorrichtung erfasst wird. Während ein nicht-hörbares Signal somit im Hintergrund den Benutzer nicht beeinträchtigt, kann ein Signal im hörbaren bevorzugt sein, sodass der Benutzer auf diese Weise darüber informiert wird, dass Informationen abgerufen werden (sollen). Auch in diesem Fall können Informationen im Signal vorhanden sein, beispielsweise mittels Modulation, und/oder kann ein Link im Signal enthalten sein, um die erforderlichen Informationen zu erfassen. Eine Modulation kann ebenfalls in einem Lichtsignal, welche beispielsweise durch ein Display in Form eines optischen Kennzeichens ausgegeben wird, vorhanden sein, um entsprechende Informationen bereitzustellen.
Alternativ können die erforderlichen Informationen auch mittels Gerätekoppelung übertragen werden, wenn die zentrale Einheit die Informationen beispielsweise an eine Rechnereinheit wie ein Notebook übermittelt, welche mit der dezentralen Vorrichtung wie einem mobilen Endgerät des Benutzers gekoppelt ist. Eine vom Benutzer freigegebene oder initiierte Gerätekoppelung kann beispielsweise mittels NFC oder BLE erfolgen.
Für den Fall, dass sich der Client auf demselben Gerät befindet wie die dezentrale Vorrichtung bzw. der Client auf der dezentralen Vorrichtung vorhanden ist, kann das Kennzeichen alternativ auch über einen Deep-Link oder Universal-Link an die dezentrale Vorrichtung übermittelt werden. So kann ein Benutzer beispielsweise am Endgerät wie einem Smartphone einen mobilen Dienst öffnen und dieser Dienst entsprechende Benutzerdaten bei der zentralen Einheit anfordern, wobei das Kennzeichen als Teil eines Deep-Link/Universal-Links an die dezentrale Vorrichtung bzw. das Smartphone zurückgeben wird. Der Link kann dann anschließend von der dezentralen Vorrichtung geöffnet werden, wonach die für das Bereitstellen der Benutzerdaten erforderlichen Informationen abgerufen und das Bereitstellen der Benutzerdaten auf der dezentralen Vorrichtung erfolgen können. Wenn die dezentrale Vorrichtung und der Dienst nicht auf demselben Gerät des Nutzers installiert sind, kann wie zuvor beschrieben ein QR-Code oder Barcode angezeigt werden, beispielsweise in einem Webdienst.
Sowohl die optische und akustische Übertragung als auch die Übertragung über Gerätekoppelung erfordern eine direkte, physische Anwesenheit des Benutzers, sodass die Sicherheit der Authentifizierung und der Bereitstellung der Benutzerdaten weiter erhöht werden kann. Dies kann auch bei Verwendung eines Deep-Llnks vorgesehen sein, wenn zum Abrufen des Links beispielsweise eine physische Tastenkombination oder auch ein Klicken durch einen Benutzer am Endgerät erforderlich Ist. In dieser Hinsicht können das Bereitstellen eines optischen oder akustischen Kennzeichens be- sonders bevorzugt sein, zumal das Auslesen in diesen Fällen eine unmittelbare Nähe der dezentralen Vorrichtung erfordert. Alternativ kann jedoch auch vorgesehen sein, dass die Informationen bei einer Gerätekoppelung erst dann bereitgestellt werden, wenn eine vorgegebene oder minimale Signalstärke der dezentralen Vorrichtung erfasst wird. Es kann somit ebenfalls eine mittelbare Authentifizierung des Benutzers erfolgen. Weiterhin kann vorgesehen sein, dass das eindeutige Kennzeichen nur von einer bestimmten dezentralen Vorrichtung ausgelesen bzw. die Informationen nur von einer bestimmten dezentralen Vorrichtung abgerufen werden können, wobei das jeweilige Kennzeichen für die jeweilige dezentrale Vorrichtung generiert wird.
Die Informationen, welche zum Bereitstellen der angeforderten Benutzerdaten erforderlich sind, können beispielsweise den mindestens einen Schlüssel zur Verschlüsselung der Benutzerdaten und/oder Verfahrensvorgaben enthalten, welche für die Authentifizierung und das Bereitstellen der angeforderten Benutzerdaten erforderlich sind. So können beispielsweise Protokollvorgaben und bereitzustellende Attribute, welche zur Übertragung der Benutzerdaten protokollgemäß erforderlich sind, in den Informationen enthalten sein. In einem OpenID Connect Protokoll können die Informationen beispielsweise Attribute wie “nonce", “iss", “aud“, „scope", “claims", und/oder “acr_values” enthalten. Es ist zu verstehen, dass die Informationen jedoch nicht auf diese Attribute beschränkt sind und entsprechend weitere und/oder alternative Attribute, je nach Protokoll und erforderlichen Benutzerdaten, enthalten können.
Zusätzlich zu den Informationen, welche die zuvor genannten Attribute enthalten können, können weitere Daten mit Hashwerten zur Übermittlung an die dezentrale Vorrichtung vorgesehen sein. Diese Daten können kurz vor der Erstellung des Identifizierungstokens oder der „userinfo“ seitens dezentraler Vorrichtung von der zentralen Einheit abgefragt werden und ermöglichen es dem Client während der Authentifizierung eine Verbindung zwischen den zur Abfrage der Benutzerdaten ggf. benötigten Zugriffstoken und Autorisierungscode herzustellen.
Diese Zweiteilung der zur Erstellung des Identifizierungstokens und der „userinfo“ ggf. benötigten Daten ist aus dem Grund vorgesehen, dass asynchrone Prozesse während der Erstellung stattfinden können, die über die Gültigkeitsdauer eine zuvor seitens zentraler Einheit generierten Zugriffstokens und Autorisierungscode hinaus geht. Deshalb können diese nachläufig erstellt und die dazugehörigen Hashwerte erst kurz vor der Erstellung an die dezentrale Vorrichtung übermittelt werden.
Das Erfassen des eindeutigen Kennzeichens kann weiterhin eine Authentifizierung auf der dezentralen Vorrichtung veranlassen. Wie vorstehend beschrieben kann die dezentrale Vorrichtung bei- spielsweise eine erfolgte Vorrichtungsregistrierung und/oder Funktionen auf der dezentralen Vorrichtung wie Jailbreakdetektion und Fingerabdruckbestätigung und/oder Gesichtserkennung überprüfen. Weiterhin kann eine Gerätebindung überprüft oder eine mehrinstanzliche Geräteüberprüfung erfolgen. Die eine oder mehrere Überprüfungen werden bevorzugt beim Starten der dezentralen Vorrichtung, beispielsweise beim Starten einer implementierten Applikation, bzw. während der Erfassung der Informationen ausgeführt, können aber auch zu einem anderen Zeitpunkt, spätestens jedoch vor oder während einer Übertragung der angeforderten Benutzerdaten erfolgen.
Die bereitgestellten Benutzerdaten können zumindest ein Identifizierungstoken enthalten, wie dies protokollgemäß vorgesehen sein kann, beispielsweise bei einer Authentifizierungsanfrage eines Clients über einen zentralen Authentifizierungsserver. Auf diese Weise können Kennungsdaten wie ein eindeutiger Benutzername („subject) angefordert und bei entsprechender Authentifizierung und Autorisierung eingegeben werden. Weiterhin können Hashwerte für einen Kode und/oder ein Zugriffstoken sowie ggf. weitere Benutzerdaten im Identifizierungstoken enthalten sein, sodass weitere benutzerspezifische Informationen erfasst und verarbeitet werden können, um den Benutzer zu verifizieren und die Benutzerdaten ggf. zu verwalten.
Grundsätzlich ist die Bereitstellung der Benutzerdaten jedoch nicht auf einen bestimmten Typ von Daten beschränkt. So können beispielsweise Benutzerdaten wie eine E-Mailadresse oder Geburtsdatum, aber auch spezifischere Daten wie Bankdaten, medizinische Daten, Krankenversicherungsdaten und/oder Versicherungsdaten angefordert werden. Zur Feststellung der Identität des Benutzers kann weiterhin vorgesehen sein, dass beispielsweise Telefondaten, Kontaktlisten und/oder webbasierte soziale Verknüpfungen angefordert werden.
Die Benutzerdaten im Identifizierungstoken können weiterhin mit Hashwerten ergänzt werden, wie vorstehend beschrieben. Diese Hashwerte können von der dezentralen Vorrichtung mittels der eindeutigen Kennung bei der zentralen Einheit kurz vor der Erstellung des Identifizierungstokens oder der „userinfo“ abgefragt werden. Mittels dieser Hashwerte kann sichergestellt werden, dass es sich um einen einmaligen Zugriff auf die angeforderten Benutzerdaten handelt und eine Datenkopie weitestgehend ausgeschlossen wird. Bevorzugt wird ein „at_hash“, welche für ein von der zentralen Einheit bereitgestelltes Zugriffstoken bereitgestellt wird, und/oder „c_hash“, welche für einen Autorisierungskode zum Anfordern des Zugriffstokens und des Identifizierungstokens in der Autorisierungsantwort bereitgestellt wird, für das Identifizierungstoken bereitgestellt, welche somit das Identifizierungstoken mit dem entsprechenden Kode und/oder dem Zugriffstoken koppeln. Das Identifizierungstoken inklusiver der Hashwerte ist dabei bevorzugt signiert und verschlüsselt, sodass diese nicht von der zentralen Einheit eingesehen oder geändert werden können. Das Identifizierungstoken kann nur von einem Dienst oder Client entschlüsselt werden, welcher über den Schlüssel verfügt, der zum Entschlüsseln vorgesehen ist. Dieser kann anschließend die Signatur das Tokens sowie Hashwerte überprüfen und somit die Integrität des Tokens sowie die Kopplung zum Kode und/oder Zugriffstoken überprüfen.
Das Authentifizieren des Benutzers kann weiterhin das Erzeugen von mindestens einem Datenpaket zusätzlich zu den angeforderten Benutzerdaten auf der dezentralen Vorrichtung umfassen, wobei das Datenpaket bei Erzeugung der angeforderten Benutzerdaten von der dezentralen Vorrichtung signiert wird und im Identifizierungstoken enthalten ist.
Das Datenpaket wird somit gleichzeitig mit oder unmittelbar nach der Erzeugung der Benutzerdaten bzw. einem bestimmten Satz von Benutzerdaten mit der zu der Zeit vorhandenen Signatur der dezentralen Vorrichtung signiert. Zusätzlich zum Datenpaket und der entsprechenden Signatur wird bei der Bereitstellung der angeforderten Benutzerdaten ebenfalls das Identifizierungstoken mit einer Signatur der dezentralen Vorrichtung versehen.
Der Dienst oder Client, der die Benutzerdaten angefordert hat, kann die übermittelten Benutzerdaten nun anhand der Signaturen dahingehend überprüfen, ob das Identifizierungstoken eine gültige Signatur aufweist und die Benutzerdaten eine gültige Signatur aufweisen. Durch die Signatur des Datenpakets, welche beim Erzeugen bzw. Generieren der entsprechenden Benutzerdaten erfolgt, kann zusätzlich überprüft werden, ob die Signatur des Datenpakets der Signatur des Identifizierungstokens, worin das signierte Datenpaket enthalten ist, entspricht. Stimmen diese Signaturen nicht überein, so kann dies auf eine unerlaubte Kopie und/oder Übertragung der Benutzerdaten auf eine andere dezentrale Vorrichtung deuten. Entsprechend kann das Identifizierungstoken auf dessen Richtigkeit überprüft und das Vorhandensein von eventuellen Tokenmanipulationen weitestgehend ausgeschlossen werden.
In einem solchen Fall kann die Authentifizierung fehlschlagen und/oder kann der Benutzer aufgefordert werden, die Benutzerdaten erneut zu erzeugen bzw. zu bestätigen, dass die Signatur der dezentralen Vorrichtung sich geändert hat.
Bevorzugt ist das Datenpaket ein Krypto-Token, das im Payload des Identifizierungstokens oder der „userinfo“ enthalten ist. Das Datenpaket kann zusätzlich zu einem vorrichtungsspezifischen Indikator Zufallsdaten enthalten, sodass das Datenpaket beispielsweise eine vorgegebene Größe und einmalige Daten aufweisen kann. Um den Zugriff auf die Benutzerdaten während einer aktuellen und aktiven Sitzung zeitlich zu limitieren, kann die Gültigkeit des Identifizierungstokens auf eine vorgegebene Zeit beschränkt sein, wobei die dezentrale Vorrichtung vor, nach oder beim Ablauf der vorgegebenen Zeit mindestens ein weiteres Identifizierungstoken bereitstellt. Das mindestens eine weitere Identifizierungstoken kann dabei periodisch von der dezentralen Vorrichtung, in Abhängigkeit einer Push-Benachrichtigung, und/oder in Abhängigkeit einer zumindest teilweise erneuten Authentifizierung des Benutzers bereitgestellt werden.
Auf diese Weise kann verhindert werden, dass Dritte, welche sich bei einer längeren Sitzung, wobei der Benutzer sich versehentlich nicht abgemeldet hat oder zwischenzeitlich nicht anwesend ist, über die Benutzerdaten verfügen können bzw. diese einsehen können. Weiterhin kann eine ansonsten ablaufende aktive Sitzung entsprechend verlängert werden, wenn dies vom Benutzer erwünscht ist. Dadurch, dass für jedes weitere Token eine erneute Bereitstellung und Verschlüsselung von Benutzerdaten erforderlich ist, kann eine verbesserte Datensicherheit ermöglicht werden, wobei der Benutzer die aktuellen Vorgänge oder Prozesse auf der dezentralen Vorrichtung verwalten und entscheiden kann, welcher Prozess fortgeführt oder aktiv gestoppt werden sollte.
Die periodische Bereitstellung eines weiteren Identifizierungstokens kann im Hintergrund einer auf der dezentralen Vorrichtung vorhandenen Applikation vorgesehen sein. Die dezentrale Vorrichtung kann dabei beispielsweise in regelmäßigen und vorgegebenen Zeitabständen ein Zugriffstoken für die nächste at hash Funktion anfordern, wobei ein neues Identifikationstoken generiert und an die zentrale Einheit übertragen wird.
Es können ebenfalls Push-Benachrichtigungen vorgesehen sein. Dabei kann ein Client oder Dienst sich vorübergehend für Push-Benachrichtigungen für eine aktuelle Sitzung registrieren. Wenn ein neues Identifikationstoken erforderlich ist, kann entsprechend eine Push-Nachricht an die dezentrale Vorrichtung gesendet werden, welche die Anforderung verarbeitet und das Identifikationstoken bereitstellt.
Alternativ, oder als zusätzlicher Back-up, kann eine erneute Authentifizierung des Benutzers vorgesehen sein, welche ggf. vereinfacht durchgeführt werden kann. Entsprechend kann vorgesehen sein, dass eine erneute Authentifizierung immer erforderlich ist oder dies kann beispielsweise veranlasst werden, wenn eine entsprechende Anforderung innerhalb eines Hintergrundintervalls empfangen wird. Bevorzugt stellt die dezentrale Vorrichtung beim Bereitstellen der angeforderten Benutzerdaten eine vorgegebene Anzahl von Identifizierungstokens mit einer unterschiedlichen zeitlichen Gültigkeit bereit. Mit anderen Worten kann ein Cache vorhanden sein, wobei Tokens wie Identifikationstokens in einem Bündel bereitgestellt und signiert werden, beispielsweise zwischen 2 und 10, bevorzugt zwischen 3 und 7 oder 5, und eine unterschiedliche zeitliche Gültigkeit haben. Diese zeitliche Gültigkeit, auch bekannt als nbf (auf Englisch: „not before“), dient dazu, dass Tokens nicht zu einer beliebigen Zeit verwendet und ggf. missbraucht werden können und andererseits Tokens durch die Anzahl der Tokens und die entsprechende Gültigkeit für eine vorgegebene Zeit bereitgestellt werden. Dadurch können Tokens auch bei verspäteten Push-Benachrichtigungen rechtzeitig bereitgestellt und ggf. ungewünschte erneute Authentifizierungen weitestgehend vermieden werden. Gleichzeitig können dadurch den Energieverbrauch und die Lebensdauer einer Batterie einer dezentralen Vorrichtung verbessert werden.
Eine direkte Abmeldung einer aktuellen Sitzung kann weiterhin nicht von der zentralen Einheit veranlasst werden, zumal diese durch die Verschlüsselung der Benutzerdaten kein Wissen über den jeweiligen Benutzer hat und Abmeldungsanforderungen somit nicht unmittelbar einem Benutzer zuordnen kann. Die dezentrale Vorrichtung kann jedoch ein Sitzungsprotokoll oder einen Sitzungsverlauf Zwischenspeichern und entweder unmittelbar mit Abmeldungskomponenten der zentralen Einheit interagieren oder eine Wiederherstellung von Authentifizierungsdaten vermeiden.
Bevorzugt wählt der Benutzer dabei eine aktuelle Sitzung auf der dezentralen Vorrichtung aus, wobei die dezentrale Vorrichtung eine Authentifizierung erzeugt, um mit einem Logout-Endpunkt der zentralen Einheit zu interagieren. Die dezentrale Vorrichtung kann anschließend bewirken, dass die zentrale Einheit die ausgewählte Sitzung beendet und anschließend auf der dezentralen Vorrichtung ggf. vorhandene Prozesse zur erneuten Verschlüsselung dieser Sitzung beenden.
Die oben gestellte Aufgabe wird weiterhin durch eine Vorrichtung zum selektiven Bereitstellen von Benutzerdaten mit den Merkmalen des Anspruchs 15 gelöst. Vorteilhafte Weiterbildungen des Verfahrens ergeben sich aus den Unteransprüchen sowie der vorliegenden Beschreibung und den Figuren.
Entsprechend wird eine Vorrichtung zum selektiven Bereitstellen von Benutzerdaten vorgeschlagen, wobei die Vorrichtung eine dezentrale Vorrichtung mit darin gespeicherten Benutzerdaten eines Benutzers und dazu eingerichtet ist, mit einer zentralen Einheit zu kommunizieren, wobei die Vorrichtung weiterhin Mittel zur Ausführung des vorstehend beschriebenen, erfindungsgemäßen Verfahrens umfasst. Bevorzugt weist die dezentrale Vorrichtung zumindest einen Prozessor, einen Arbeitsspeicher, ein Speichermedium und ein (drahtloses) Kommunikationsmodul auf, wobei der Prozessor und der Arbeitsspeicher, beim Empfangen einer Authentifizierungsanfrage mittels des Kommunikationsmoduls und nach Autorisierung des Benutzers, im Speichermedium gespeicherte Benutzerdaten abrufen bzw. Zwischenspeichern und Befehle ausgeführt werden, um die Benutzerdaten zumindest teilweise zu verschlüsseln und über das Kommunikationsmodul zur Übertragung an die zentrale Einheit bereitstellen. Das Kommunikationsmodul kann ein WLAN-Modul umfassen und/oder mit alternativen Übertragungstechnologien wie 3G, 4G, 5G oder Bluetooth kompatibel sein. Weiterhin kann die dezentrale Vorrichtung einen optischen und/oder akustischen Sensor aufweisen, welcher besonders bevorzugt zum Initialisieren einer Authentifizierung auf der dezentralen Vorrichtung eingerichtet ist, beispielsweise als optisches Auslesegerät zum Erfassen eines optischen Kennzeichens wie eines QR-Codes. Die dezentrale Vorrichtung kann weiterhin eine Applikation oder Implementierung aufweisen, welche zum Ausführen der vorrichtungsbezogenen Verfahrensschritte des erfindungsgemäßen Verfahrens konfiguriert ist.
Bevorzugt ist die dezentrale Vorrichtung als Rechnereinheit, medizintechnische Vorrichtung, tragbares Gerät oder mobiles Endgerät eines Benutzers ausgebildet. Die Vorrichtung kann somit ein Mobilgerät oder Smartphone des Benutzers oder auch eine körpernahe, tragbare Vorrichtung wie ein Wearable oder Smartwatch. Ebenfalls kann die dezentrale Vorrichtung als patientengebundenes Medizingerät ausgebildet sein, beispielsweise als tragbare Blutdruckmessvorrichtung, EKG-Gerät, oder Blutzuckermessgerät. Weiterhin kann die dezentrale Vorrichtung auch als lokaler, stationärer Computer bzw. Desktop Computer oder Rechnereinheit ausgebildet sein. In einer solchen Ausführungsform kann eine damit gekoppelte Vorrichtung vorgesehen sein, um beispielsweise ein vom Display ausgegebenes optisches Kennzeichen zu erfassen, sodass weiterhin eine physische Anwesenheit des Benutzers erforderlich ist, um die Authentifizierung des Benutzers zu ermöglichen.
Gemäß einem weiteren Aspekt der Erfindung wird ein System zum selektiven Bereitstellen von Benutzerdaten vorgeschlagen, welches eine zentrale Einheit, bevorzugt einen Authentifizierungsserver, und mindestens eine vorstehend beschriebene dezentrale Vorrichtung umfasst. In einem solchen System können Authentifizierungsanfragen über die zentrale Einheit an eine gezielte dezentrale Vorrichtung weitergeleitet und entsprechend angeforderte Benutzerdaten über die zentrale Einheit auf verschlüsseltem Weg bereitgestellt werden, ohne dass die zentrale Einheit die Benutzerdaten einsehen oder auch mit einem Dienst oder Client, welcher die Benutzerdaten erfordert, (bidirektional) kommunizieren kann. Gemäß einem weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt vorgeschlagen, welches Befehle umfasst, welche bei der Ausführung des Programms durch einen Prozessor diesen dazu veranlassen, das vorstehend beschriebene erfindungsgemäße Verfahren auszuführen.
Gemäß einem weiteren Aspekt der Erfindung wird ein computerlesbares Speichermedium vorgeschlagen, welches Befehle umfasst, welche bei der Ausführung durch einen Prozessor diesen dazu veranlassen, das vorstehend beschriebene erfindungsgemäße Verfahren auszuführen.
Kurze Beschreibung der Figuren
Bevorzugte weitere Ausführungsformen der Erfindung werden durch die nachfolgende Beschreibung der Figuren näher erläutert. Dabei zeigen:
Figur 1 ist eine schematische Darstellung eines erfindungsgemäßen Verfahrensablaufs;
Figur 2 ist eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Verfahrens in einem System;
Figur 3 ist eine schematische Darstellung einer Ausführungsform zum Authentifizieren des Benutzers;
Figur 4 zeigt eine detailliertere schematische Darstellung eines erfindungsgemäßen Verfahrensablaufs; und
Figur 5 zeigt eine Ausführungsform eines Identifizierungstokens mit einem zusätzlichen Datenpaket.
Detaillierte Beschreibung bevorzugter Ausführungsbeispiele
Im Folgenden werden bevorzugte Ausführungsbeispiele anhand der Figuren beschrieben. Dabei werden gleiche, ähnliche oder gleichwirkende Elemente in den unterschiedlichen Figuren mit identischen Bezugszeichen versehen, und auf eine wiederholte Beschreibung dieser Elemente wird teilweise verzichtet, um Redundanzen zu vermeiden.
In Figur 1 ist schematisch ein Verfahrensablauf dargestellt, welches bevorzugt auf einer dezentralen Vorrichtung ausgeführt wird. Im Verfahren ist vorgesehen, dass bestimmte Benutzerdaten eines Benutzers bereitgestellt werden, um den Benutzer beispielsweise für einen Dienst oder auf einem Client zu identifizieren bzw. zu authentifizieren. Entsprechend kann durch die dezentrale Vorrichtung eine Authentifizierungsanfrage eines Clients empfangen werden, wobei bestimmte Benutzerdaten, welche auf der dezentralen Vorrichtung vorhanden sind, angefordert werden. Gemäß dem Verfahren ist somit vorgesehen, dass eine Authentifizierung 100 des Benutzers vorgenommen wird. Wenn festgestellt wird, dass es sich bei der dezentralen Vorrichtung um den richtigen Benutzer handelt, ist eine Autorisierung 200 des Benutzers erforderlich, damit die angeforderten Benutzerdaten freigegeben werden und eine Bereitstellung der angeforderten Benutzerdaten 300 erfolgen kann.
Bei der Bereitstellung der Benutzerdaten 300 ist weiterhin eine Verschlüsselung von Benutzerdaten 302 vorgesehen, sodass die angeforderten Benutzerdaten zumindest teilweise verschlüsselt bereitgestellt werden. Bevorzugt werden sämtliche Benutzerdaten, die angefordert wurden, verschlüsselt. Durch die Verschlüsselung wird sichergestellt, dass nur eine dazu berechtigte Instanz über die Benutzerdaten mittels eines entsprechenden Schlüssels verfügen kann und die Benutzerdaten selbst beim Abfangen durch Dritte nicht einsehbar sind. Die Bereitstellung der Benutzerdaten 300 kann somit optional, wie mit den gestrichelten Linien angedeutet, ebenfalls das Übertragen der bereitgestellten Benutzerdaten 400 umfassen, wobei die angeforderten - und zumindest teilweise bereits verschlüsselten - Benutzerdaten ebenfalls verschlüsselt übertragen werden können.
Der Zeitpunkt der Authentifizierung 100 kann weiterhin auch nach oder während der Autorisierung 200 gewählt sein, sodass der Benutzer zunächst die Freigabe der angeforderten Benutzerdaten bestätigt, diese jedoch erst nach einer erfolgten Authentifizierung 100 bereitgestellt werden. Die Authentifizierung 100 kann dabei beispielsweise parallel im Hintergrund ausgeführt werden. Sollte beispielsweise eine Identität des Benutzers oder Rechtmäßigkeit der Verwendung der Benutzerdaten bei der Authentifizierung 100 nicht festgestellt werden können, so kann eine Bereitstellung der angeforderten Benutzerdaten 300 verhindert werden, um einen potenziellen Missbrauch zu vermeiden. Die Authentifizierung 100 des Benutzers ist dabei derart zu verstehen, dass der Benutzer auf der dezentralen Vorrichtung als berechtigte Person identifiziert wird, beispielsweise mittels Geräteoder Anwendungspassworts, Fingerabdrucküberprüfung oder Gesichtserkennung. Eine Authentifizierungsanfrage eines Clients bzw. eines Diensts ist dabei derart zu verstehen, dass bestimmte Benutzerdaten angefordert werden, um eine Authentifizierung am Client bzw. für den Dienst zu ermöglichen oder entsprechende Benutzerdaten dazu bereitzustellen. Die Verschlüsselung der Benutzerdaten 302 erfolgt dabei bevorzugt mit asymmetrischen Schlüsseln, wobei die zu verwendenden Schlüssel in einer Authentifizierungsanfrage enthalten sein können. Die Schlüssel, welche zum Entschlüsseln der verschlüsselten Benutzerdaten erforderlich sind, sind dabei nur beim Dienst bzw. Client vorhanden, sodass eine zentrale Einheit, welche die Anfrage der Benutzerdaten und die bereitgestellten Benutzerdaten übermittelt, die Benutzerdaten nicht einsehen, aber zum Abrufen Zwischenspeichern kann. Auf diese Weise kann das Verfahren einfach in bestehenden Authentifizierungsprotokollen, welche beispielsweise einen zentralen Authentifizierungsserver vorsehen, implementiert werden.
In den Figuren 2 bis 5 sind weitere optionale und/oder bevorzugte Ausführungsformen des erfindungsgemäßen Verfahrens gezeigt, wobei diese zur Erläuterung im Kontext eines Authentifizierungsprotokolls wie OpenID Connect und in einem entsprechenden Authentifizierungssystem beschrieben werden. Die Ausführungsformen sind jedoch nicht dahingehend zu verstehen, dass sie auf ein solches Protokoll beschränkt sind und die optionalen Merkmale können sowohl einzeln als auch in Kombination vorgesehen sein.
Entsprechend ist in Figur 2 eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Verfahrens in einem System gezeigt, wobei eine dezentrale Vorrichtung 12 von einem Benutzer 10 bedient wird und wobei ein Client 16 zum Authentifizieren bestimmte Benutzerdaten über eine zentrale Einheit 14 anfordert. Obwohl alternative Ausgestaltungen vorgesehen sein können, ist die dezentrale Vorrichtung 12 vorliegend als mobiles Endgerät, die zentrale Einheit 14 als zentraler Authentifizierungsserver und der Client 16 als Webbrowser ausgebildet.
Entsprechend kann das Authentifizieren durch das Übersenden einer Authentifizierungsanfrage 102 seitens des Clients 16 über den Webbrowser initiiert werden, wobei die Authentifizierungsanfrage über den zentralen Authentifizierungsserver an das mobile Endgerät übermittelt 104 wird. Die übermittelte Authentifizierungsanfrage 104 stimmt dabei nicht vollständig mit der Authentifizierungsanfrage 102 überein, sondern ist als Authentifizierungsanfrage zu verstehen, worin zur Bereitstellung der angeforderten Benutzerdaten Informationen enthalten sein können, sowohl mittelbar als unmittelbar. Beispielsweise kann die Authentifizierungsanfrage 102 eine Client-ID enthalten, wobei der zentrale Authentifizierungsserver einen dem Client-ID entsprechenden, öffentlichen Schlüssel in der Authentifizierungsfrage aufnimmt, womit die dezentrale Vorrichtung 12 die angeforderten Benutzerdaten verschlüsseln kann. Ebenfalls können weitere Informationen wie Protokollvorgaben übermittelt werden, wie dies beispielsweise im Hinblick auf Figur 2 nachfolgend beschrieben werden wird. Auf dem mobilen Endgerät wird nun eine Authentifizierung 106 veranlasst, welche beispielsweise eine Authentifizierung des Benutzers 10 mittels Fingerabdruckerfassung ausführt und/oder Überprüft, ob das mobile Endgerät nicht manipuliert wurde, beispielsweise durch Jailbreakversuche. Die Reihenfolge ist jedoch beliebig, sodass dies ebenfalls beim Starten einer Applikation oder im Hintergrund, jedoch spätestens vor der Bereitstellung der angeforderten Benutzerdaten 300 bzw. vor dem Übertragen 400 der Benutzerdaten erfolgen kann.
Der Benutzer 200 kann die Authentifizierungsanfrage anschließend auf dem mobilen Endgerät autorisieren 200, sodass die angeforderten Benutzerdaten bereitgestellt und verschlüsselt werden 300, 302. Der zu verwendende Schlüssel kann dabei vom Client 16 vorgegeben und entsprechend in der Authentifizierungsanfrage 104 definiert sein, wie vorstehend beschrieben, beispielsweise als JWKSJJRI. Gemäß der Ausführungsform werden die Benutzerdaten weiterhin vor der Verschlüsselung 302 signiert, sodass die Herkunft der Benutzerdaten verifiziert werden kann.
Die bereitgestellten Benutzerdaten werden verschlüsselt an den Authentifizierungsserver übertragen 400, wobei der Authentifizierungsserver die Daten in Form einer Autorisierungsantwort über eine Autorisierungsschnittstelle 18 an den Client 16 überträgt 402. Dadurch, dass eine bidirektionale Kommunikation zwischen dem Client 16 und dem Authentifizierungsserver bzw. der zentralen Einheit 14 nicht vorhanden ist, kann die Autorisierungsantwort beispielsweise mittels einer URI Umleitung („redirect URF) oder über einen seitens Client zuvor registrierte Deep-Link/Universal-Link (falls der Client sich beispielsweise auf demselben mobilen Endgerät wie die dezentrale Komponente befindet) übermittelt werden.
Die angeforderten Benutzerdaten können Kenndaten des Benutzers 10 sein, welche für ein Login erforderlich sind. Gemäß dem OpenID Connect (OIDC) Protokoll können die Benutzerdaten entsprechend als „subject“ und ggf. als „Claims“ und „scope" definiert werden, wobei die Benutzerdaten mittels eines entsprechenden Identifizierungstokens bereitgestellt werden können.
Gemäß der vorliegenden Ausführungsform ist ein Identifizierungstoken in einer Autorisierungsnachricht in signierter und verschlüsselter Form vorhanden und wird auf dem Authentifizierungsserver zwischengespeichert 400. Nach Übertragung der Authentifizierungsantwort 402 kann der Client 16 das Identifizierungstoken entsprechend bei einer Tokenschnittstelle 20 des Authentifizierungsservers anfordern, wonach das Identifizierungstoken entsprechend an den Client 16 übermittelt wird 406. Das Anfordern des Identifizierungstokens kann dabei anhand eines vom Client 16 empfangenen Autorisierungscodes oder Zugriffstokens erfolgen, welche als Teil der Autorisierungsantwort 402 übermittelt wurden. Der Client 16 kann das Identifizierungstoken entsprechend entschlüsseln und die Signatur überprüfen, um die Echtheit und Herkunft der Benutzerdaten zu verifizieren und einen sicheren Login zu ermöglichen. In anderen Protokollen kann zudem vorgesehen sein, dass zumindest ein Identifizierungstoken bereits in der Authentifizierungsantwort 402 enthalten ist. Dies kann beispielsweise in der Authentifizierungsanfrage 102 vom Client 16 festgelegt sein.
Zusätzlich zu einer Benutzerkennung oder subject oder bestimmte Benutzerdaten können optional weitere Benutzerdaten erforderlich sein, welche nicht im Identifizierungstoken enthalten sind und ebenfalls vom mobilen Endgerät verschlüsselt bereitgestellt und in der Autorisierungsnachricht vorhanden sein können. Solche Daten können protokollgemäß durch „Claims“ und „scope“ definiert sein und als solche bereitgestellt werden. Diese weiteren Benutzerdaten können als „userinfo“ in einer Benutzerdatenschnittstelle 22 auf dem Authentifizierungsserver verschlüsselt hinterlegt werden 408 und mittels eines entsprechenden Zugriffstokens, welches an der Tokenschnittstelle 22 bei entsprechender Autorisierung des Clients 16 verschlüsselt ausgegeben wird, angefordert werden 410. Mittels „Claims“ können dabei detailliertere Angaben bezüglich der angeforderten Benutzerdaten ermöglicht werden, wobei bestimmte Benutzerdaten oder Inhalte in „userinfo“, nicht jedoch im Identifizierungstoken vorzusehen sind. Ebenfalls können dadurch Einschränkungen vorgesehen werden, wobei eine Authentifizierung beispielsweise nur dann erfolgreich ist, wenn bestimmte Werte in den „userinfo“ enthalten sind.
Weiterhin kann optional eine Aktualisierung des Identifizierungstokens 412 erfolgen, beispielsweise um eine aktuelle Sitzung bei zeitlich begrenzten Hashfunktionen, welche mit dem Identifizierungstoken mitgeschickt werden, zu verlängern. Eine solche Aktualisierung kann beispielsweise im Hintergrund auf dem mobilen Endgerät periodisch vorgesehen sein. Bevorzugt wird eine Aktualisierung, zusätzlich oder alternativ, mittels einer Push-Nachrichtregistrierung angefordert, wobei weiterhin eine erneute Authentifizierung vorgesehen sein kann, sollte weder eine Hintergrundaktualisierung noch eine Push-Nachricht rechtzeitig erfolgen. Zur Vereinfachung können weitere Identifizierungstokens in einer Reihe vom mobilen Endgerät bereitgestellt und auf dem Authentifizierungsserver zwischengespeichert werden, wobei die Identifizierungstokens mit einer unterschiedlichen jeweiligen Gültigkeit versehen sind.
In Figur 3 ist eine mögliche Authentifizierung des Benutzers gezeigt, welche eine physische Anwesenheit oder Nähe erfordert. Zunächst kann eine Gerätebindung vorgesehen sein (nicht gezeigt), wobei die dezentrale Vorrichtung 12 eine Geräteidentität erzeugt und diese in einer verifizierbaren, vertraulichen und zentralen Instanz registriert wird. Weiterhin kann für einen bestimmten Client eine Benutzerkennung generiert werden, welche entsprechend sowohl clientgebunden als auch Gerätgebunden ist. Die Benutzerkennung kann ein dezentraler Identifikator (DID) sein, welche beispielsweise auf Blockchaintechnologie basiert.
Die vorliegende Ausführungsform ist basiert auf einer Darstellung eines eindeutigen optischen Kennzeichens in Form eines QR-Codes. Beim Initiieren der Authentifizierung 108, wie dies beispielsweise beim Übersenden einer Authentifizierungsanfrage vorgesehen sein kann, wird dieser QR-Code wird von einem Backend 14A der zentralen Einheit bzw. eines Authentifizierungsservers generiert und entsprechend am Frontend dargestellt 110, beispielsweise auf einem Display eines Computers, welches vom Benutzer für einen Webbrowser und Login verwendet wird. Die dezentrale Vorrichtung 12 des Benutzers erfasst das optische Kennzeichen bzw. den QR-Code, beispielsweise mittels einer in der dezentralen Vorrichtung 12 integrierten Kamera. Die dezentrale Vorrichtung 12 ist dabei bevorzugt als mobiles Endgerät des Benutzers ausgebildet und somit benutzerspezifisch, sodass die Kamerafunktion nur nach Freigabe durch den Benutzer aktiviert werden kann, beispielsweise durch Fingerabdrucküberprüfung.
Nach Erfassung des QR-Codes werden dem QR-Code entsprechende Informationen abgerufen, beispielsweise mittels einer Umleitung bzw. Weiterleitung oder Initiierung eines „redirects“. Die Informationen umfassen Informationen, welche zur Bereitstellung der angeforderten Benutzerdaten erforderlich sind und umfassen somit insbesondere Protokollvorgaben. Gemäß dem OIDC Protokoll können die Informationen entsprechende Attribute wie wks“, „nonce“, „iss“, „aud“, „scope“, „claims“, „acr_values“ , code" und/oder „token“ enthalten, wobei die Informationen nicht auf diese Attribute beschränkt sind und weitere Attribute vorgesehen sein können. Die Informationen sind bevorzugt signiert, wobei der Schlüssel als Teil der dezentralen Vorrichtung oder als JWKS_URI festgelegt sein kann.
Figur 4 zeigt eine detailliertere schematische Darstellung eines erfindungsgemäßen Verfahrensablaufs mit weiteren optionalen und/oder bevorzugten Funktionen.
Auf der dezentralen Vorrichtung 12 wird zunächst der Benutzer authentifiziert 100, beispielsweise mittels Geräte- oder Anwendungspassworts, Fingerabdrucküberprüfung und/oder Gesichtserkennung. Durch Auslesen eines vom Backend 14A einer zentralen Einheit erzeugten optischen Kennzeichens können anschließend, oder alternativ vorangehend an der Authentifizierung 100, erforderliche Protokollinformationen durch die dezentrale Vorrichtung 12 abgerufen und verarbeitet werden 114, 116. Weiterhin findet eine Überprüfung der Gerätebindung 118 statt, wobei die dezentrale Vorrichtung 12 bei einer Vorrichtung oder einem zentralen Dienst zur Gerätebindung 46 eine erfolgte Registrierung überprüft und/oder überprüft, ob das Gerät nicht manipuliert wurde.
Zur Bereitstellung der angeforderten Benutzerdaten ist weiterhin das Signieren vorgesehen, wobei zunächst ein vorübergehender Signierschlüssel erzeugt 304 und dieser anschließend von dem Gerätebindungsdienst 46 signiert 306 und auf einem Datenspeicher 44 der dezentralen Vorrichtung 12 gespeichert 308 wird.
Je nachdem, welche Benutzerdaten angefordert werden, können weitere Benutzerdaten bereitgestellt werden, welche beispielsweise keine Kennungsdaten bzw. keinen Login oder Benutzername umfassen. Entsprechend können solche Benutzerdaten bereitgestellt, mit dem erzeugten Schlüssel signiert und anschließend verschlüsselt werden 310. Ebenfalls wird für den Login des Benutzers ein Identifizierungstoken erzeugt und bereitgestellt, wobei das Identifizierungstoken ebenfalls mit diesem Schlüssel signiert und anschließend verschlüsselt wird 312. Gemäß der Figur wird optional ein unverschlüsseltes Identifizierungstoken gespeichert 314, welches beispielsweise für Aktualisierungsanforderungen verwendet werden kann. Für eine regelmäßige Aktualisierung wird gemäß der Figur bei einem zentralen Push-Benachrichtigungsdienst 48 eine Push-Benachrichtigung registriert 316. Ein entsprechendes Gerätetoken kann entsprechend an das Backend 14A der zentralen Einheit übermittelt werden, beispielsweise eingebettet In einer Autorisierungsnachricht oder Autorisierungsantwort.
Die bereitgestellten und verschlüsselten Benutzerdaten werden anschließend übertragen und In Form einer Autorisierungsantwort über das Backend 14A der zentralen Einheit an den entsprechenden Client übermittelt, 400, 402. Die Autorisierungsantwort enthält dabei das signierte und verschlüsselte Identifizierungstoken sowie die signierten und verschlüsselten weiteren Benutzerdaten, welche auch als „userinfo“ bekannt sind. Zusätzlich wird ein vorübergehender Signierschlüssel mitgeschickt, sodass die Herkunft der Benutzerdaten überprüft werden kann. Das Backend 14A der zentralen Einheit kann dazu eine Aktualisierung eines JWKS ausführen 414, sodass der Client, welcher die Benutzerdaten angefordert hat, den entsprechenden Signierschlüssel abrufen kann.
Ein Beispiel eines Identifizierungstokens 24, welches eine weitere Überprüfung der Authentizität ermöglicht, Ist In Figur 5 dargestellt. Das Identifizierungstoken 24 weist sowohl Identitätsdaten 26 wie ein Benutzername oder „subject1 als auch weitere, dem Benutzer zugeordnete Daten 28 wie Versi- cherungsdaten oder bestimmte „userinfo“ auf. Sowohl die Identitätsdaten 26 als auch die zugeordneten Daten 28 sind dabei mit einem entsprechenden Schlüssel 30 bzw. 32 signiert, sodass die Echtheit und Herkunft der entsprechenden Benutzerdaten verifiziert werden können.
Weiterhin enthält das Identifizierungstoken 24 als solches eine Signatur 42 der dezentralen Vorrichtung, welche mit dem aktuellen Schlüssel bereitgestellt wurde. Mit anderen Worten entspricht die Signatur 42 der Signatur, welche dem Zeitpunkt einer Authentifizierungsanforderung für die dezentrale Vorrichtung vorliegt und gültig ist. Somit kann zusätzlich zur Echtheits- und Herkunftsüberprüfung der Benutzerdaten ebenfalls überprüft werden, von welcher dezentralen Vorrichtung die Benutzerdaten bereitgestellt wurden.
Um ein Kopieren des Identifizierungstokens 24 und/oder der entsprechenden Benutzerdaten zu überprüfen, ist sowohl für die Identitätsdaten 26 als auch für die zugeordneten Daten 28 ein jeweiliges Datenpaket in Form eines Krypto-Tokens 34 bzw. 36 im Payload vorgesehen. Das jeweilige Krypto-Token 34, 36 enthält dabei einen vorrichtungsspezifischen Indikator sowie Zufallsdaten, sodass das Datenpaket beispielsweise eine vorgegebene Größe und einmalige Daten, d. h. nicht fälschbare oder wiederverwendbare Daten, aufweisen kann. Weiterhin enthält jedes Krypto-Token 34, 36 eine Signatur der dezentralen Vorrichtung, und zwar eine Signatur mit dem Schlüssel, der zum Zeitpunkt der Benutzerdatenerzeugung gültig war. Mit anderen Worten wurde das jeweilige Krypto-Token 34, 36 gleichzeitig mit oder unmittelbar nach der Erzeugung der jeweiligen Benutzerdaten bzw. einem bestimmten Satz von Benutzerdaten erzeugt und mit der zu der Zeit vorhandenen Signatur der dezentralen Vorrichtung signiert.
Der Dienst oder Client, der die Benutzerdaten angefordert hat, kann die übermittelten Benutzerdaten nun anhand der Signaturen dahingehend überprüfen, ob das Identifizierungstoken 24 eine gültige Signatur 42 aufweist und die Benutzerdaten eine gültige Signatur 30, 32 aufweisen. Durch die Signatur 38, 40 des Krypto-Tokens 34, 36, welche beim Erzeugen bzw. Generieren der entsprechenden Benutzerdaten erfolgt, kann zusätzlich überprüft werden, ob die Signatur des Krypto-Tokens 34, 36 der Signatur 42 des Identifizierungstokens 24, worin die signierten Krypto-Tokens 34, 36 enthalten sind, entspricht. Stimmen diese Signaturen nicht überein, so kann dies auf eine unerlaubte Kopie und/oder Übertragung der Benutzerdaten auf eine andere dezentrale Vorrichtung deuten. Entsprechend kann das Identifizierungstoken 24 auf dessen Richtigkeit überprüft und das Vorhandensein von eventuellen Tokenmanipulationen weitestgehend ausgeschlossen werden. Soweit anwendbar, können alle einzelnen Merkmale, die in den Ausführungsbeispielen dargestellt sind, miteinander kombiniert und/oder ausgetauscht werden, ohne den Bereich der Erfindung zu verlassen.
Figure imgf000031_0001
10 Benutzer
12 Dezentrale Vorrichtung
14 Zentrale Einheit
14A Backend von zentraler Einheit
14B Frontend von zentraler Einheit
16 Client oder Dienst
18 Autorisierungsschnittstelle
20 Tokenschnittstelle
22 Benutzerdatenschnittstelle
24 Identifizierungstoken oder „userinfo“
26 Identitätsdaten
28 Zugeordnete Daten
30 Signatur von einem Identitätsdienst
32 Signatur von einem Identitätsdienst
34 Krypto-Token oder Datenpaket
36 Krypto-Token oder Datenpaket
38 Signatur von der dezentralen Vorrichtung
40 Signatur von der dezentralen Vorrichtung
42 Signatur von der dezentralen Vorrichtung
44 Datenspeicher dezentraler Vorrichtung
46 Vorrichtung zur Gerätebindung
48 Push-Benachrichtigungsdienst
100 Authentifizieren
102 Übersenden von Authentifizierungsanfrage
104 Übermitteln von Authentifizierungsanfrage
106 Authentifizieren
108 Initiieren von Authentifizierung
110 Darstellen von optischem Kennzeichen
112 Erfassen von optischem Kennzeichen
114 Abrufen von Informationen
116 Übermitteln von Informationen
118 Überprüfen Gerätebindung 200 Autorisieren
300 Bereitstellen von Benutzerdaten
302 Verschlüsseln von Benutzerdaten
304 Erzeugen von vorübergehendem Signierschlüssel
306 Signieren von Signierschlüssel
308 Speichern von Signierschlüssel
310 Bereitstellen, Signieren und Verschlüsseln von Benutzerdaten
312 Bereitstellen, Signieren und Verschlüsseln von Identifizierungstoken
314 Speichern von unverschlüsseltem Identifizierungstoken
316 Registrieren für Push-Benachrichtigung
400 Verschlüsseltes Übertragen der bereitgestellten Benutzerdaten
402 Übertragen von Autorisierungsantwort
404 Zwischenspeichern von Identifizierungstoken
406 Anfordern und Übermitteln von Identifizierungstoken
408 Zwischenspeichern von Benutzerdaten
410 Anfordern und Übermitteln von Benutzerdaten
412 Aktualisieren von Identifizierungstoken
414 Aktualisieren von Signierschlüsseln

Claims

Ansprüche
1 . Computerimplementiertes Verfahren zum selektiven Bereitstellen von Benutzerdaten, umfassend die Schritte:
Authentifizieren (100) eines Benutzers (10);
Autorisieren (200) einer Bereitstellung von mittels einer zentralen Einheit (14) angeforderten Benutzerdaten des Benutzers (10); und
Bereitstellen (300) der angeforderten Benutzerdaten zum Übertragen an die zentrale Einheit (14), wobei das Autorisieren (200) und das Bereitstellen (300) der angeforderten Benutzerdaten mittels einer dezentralen Vorrichtung (12) erfolgen und wobei das Bereitstellen (300) der angeforderten Benutzerdaten das Verschlüsseln (302) von auf der dezentralen Vorrichtung (12) gespeicherten Benutzerdaten umfasst.
2. Computerimplementiertes Verfahren nach Anspruch 1 , wobei alle der bereitgestellten Benutzerdaten verschlüsselt werden.
3. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei das Verschlüsseln (302) mittels asymmetrischer Schlüssel oder symmetrischer Schlüssel erfolgt und/oder wobei die bereitgestellten Benutzerdaten verschlüsselt an die zentrale Einheit (14) übertragen (400) werden und/oder wobei die zentrale Einheit (14) nicht über den Schlüssel zum Entschlüsseln der verschlüsselten Benutzerdaten verfügt und/oder wobei das Verschlüsseln (302) derart erfolgt, dass die bereitgestellten Benutzerdaten nur durch einen Client (16) entschlüsselt und eingesehen werden können, welcher die Benutzerdaten mittels der zentralen Einheit (14) angefordert hat und den zum Entschlüsseln erforderlichen entsprechenden Schlüssel enthält.
4. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die Größe der angeforderten Benutzerdaten beim Verschlüsseln (302) nach einem vorgegebenen kryptographischen Standard aufgefüllt wird.
5. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die bereitgestellten Daten vor dem Verschlüsseln (302) signiert und ein öffentlicher Signierschlüssel der dezentralen Vorrichtung dynamisch bereitgestellt werden, bevorzugt mittels einer von der dezentralen Vorrichtung bereitgestellten Autorisierungsantwort. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die zentrale Einheit (14) ein zentraler Authentifizierungsserver ist, welcher das Authentifizieren (100) des Benutzers in Reaktion auf mindestens eine empfangene Authentifizierungsanfrage (102) eines Clients (16) veranlasst und die bereitgestellten Benutzerdaten an den Client (16) übermittelt. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei mindestens ein Schlüssel, der zum Verschlüsseln (302) der angeforderten Benutzerdaten erforderlich ist, in einer Authentifizierungsanfrage (104), welche von der dezentralen Vorrichtung (12) empfangen wird, enthalten ist oder direkt von einem Client (16) durch die dezentrale Vorrichtung (12) empfangen wird. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die dezentrale Vorrichtung (12) in Reaktion auf eine Authentifizierungsanfrage (102, 104) eine Autorisierungsantwort (402) bereitstellt, welche die bereitgestellten Benutzerdaten enthält. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die bereitgestellten Benutzerdaten zumindest ein eindeutiges Identifizierungskennzeichen enthalten, bevorzugt in Form einer dezentral oder zentral erzeugten Kennung, und/oder wobei die auf der dezentralen Vorrichtung (12) gespeicherten Benutzerdaten zumindest teilweise an der dezentralen Vorrichtung (12) gebunden sind. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche,
- wobei das Authentifizieren (100) des Benutzers das Erfassen (112) eines von der zentralen Einheit (14) ausgegebenen (110) eindeutigen Kennzeichens, bevorzugt eines optischen oder akustischen Kennzeichens, durch die dezentrale Vorrichtung (12) umfasst; oder
- wobei ein die Benutzerdaten anfordernde Client (16) auf der dezentralen Vorrichtung (12) vorhanden ist, weicher ein eindeutiges Kennzeichen mittels eines Deep-Links oder Universal- Link an die dezentrale Vorrichtung (12) übermittelt; und wobei die dezentrale Vorrichtung (12) durch das Erfassen (112) oder Übermitteln des Kennzeichens Informationen erhält (114, 116), welche zum Bereitstellen der angeforderten Benutzerdaten erforderlich sind. Computerimplementiertes Verfahren nach einem der vorstehenden Ansprüche, wobei die bereitgestellten Benutzerdaten zumindest ein Identifizierungstoken (24) enthalten. Computerimplementiertes Verfahren nach Anspruch 11 , wobei das Authentifizieren (100) des Benutzers das Erzeugen von mindestens einem Datenpaket (34, 36) zusätzlich zu den angeforderten Benutzerdaten auf der dezentralen Vorrichtung umfasst, wobei das mindestens eine Datenpaket (34, 36) bei Erzeugung der angeforderten Benutzerdaten von der dezentralen Vorrichtung (12) signiert wird und im Identifizierungstoken (24) enthalten ist. Computerimplementiertes Verfahren nach Anspruch 11 oder 12, wobei die Gültigkeit des Identifizierungstokens (24) auf eine vorgegebene Zeit beschränkt ist und wobei die dezentrale Vorrichtung (12) vor, nach oder beim Ablauf der vorgegebenen Zeit mindestens ein weiteres Identifizierungstoken (24) bereitstellt, wobei das mindestens eine weitere Identifizierungstoken (24) periodisch von der dezentralen Vorrichtung (12), in Abhängigkeit einer Push-Benachrichtigung, und/oder in Abhängigkeit einer zumindest teilweise erneuten Authentifizierung (100) des Benutzers (10) bereitgestellt wird. Computerimplementiertes Verfahren nach Anspruch 13, wobei die dezentrale Vorrichtung (12) beim Bereitstellen (300) der angeforderten Benutzerdaten eine vorgegebene Anzahl von Identifizierungstokens (24) mit einer unterschiedlichen zeitlichen Gültigkeit bereitstellt. Vorrichtung zum selektiven Bereitstellen von Benutzerdaten, wobei die Vorrichtung eine dezentrale Vorrichtung (12) mit darin gespeicherten Benutzerdaten eines Benutzers (10) und dazu eingerichtet ist, mit einer zentralen Einheit (14) zu kommunizieren, wobei die Vorrichtung weiterhin Mittel zur Ausführung des Verfahrens nach einem der vorstehenden Ansprüche umfasst. Vorrichtung nach Anspruch 15, welche als Rechnereinheit, medizintechnische Vorrichtung, tragbares Gerät oder mobiles Endgerät eines Benutzers (10) ausgebildet ist. System zum selektiven Bereitstellen von Benutzerdaten, umfassend eine zentrale Einheit (14), bevorzugt einen Authentifizierungsserver, und mindestens eine Vorrichtung nach einem der vorstehenden Ansprüche. Computerprogrammprodukt, umfassend Befehle, welche bei der Ausführung des Programms durch einen Prozessor diesen dazu veranlassen, das Verfahren nach einem der vorstehenden Ansprüche auszuführen. Computerlesbares Speichermedium, umfassend Befehle, welche bei der Ausführung durch einen Prozessor diesen dazu veranlassen, das Verfahren nach einem der vorstehenden Ansprüche auszuführen.
PCT/EP2021/082369 2020-11-20 2021-11-19 Dezentrale bereitstellung von benutzerdaten WO2022106653A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21819361.3A EP4248348A1 (de) 2020-11-20 2021-11-19 Dezentrale bereitstellung von benutzerdaten

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102020130815.9 2020-11-20
DE102020130815.9A DE102020130815B3 (de) 2020-11-20 2020-11-20 Dezentrale Bereitstellung von Benutzerdaten

Publications (1)

Publication Number Publication Date
WO2022106653A1 true WO2022106653A1 (de) 2022-05-27

Family

ID=78821445

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/082369 WO2022106653A1 (de) 2020-11-20 2021-11-19 Dezentrale bereitstellung von benutzerdaten

Country Status (3)

Country Link
EP (1) EP4248348A1 (de)
DE (1) DE102020130815B3 (de)
WO (1) WO2022106653A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021214948A1 (de) 2021-12-22 2023-06-22 Robert Bosch Gesellschaft mit beschränkter Haftung System und Verfahren zum Steuern eines Zugriffs auf Daten

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190036688A1 (en) * 2017-07-17 2019-01-31 Thirdwayv, Inc. Secure communication for medical devices
EP3579524A1 (de) * 2015-02-13 2019-12-11 Yoti Holding Limited Digitales identitätssystem
WO2020198182A1 (en) * 2019-03-25 2020-10-01 Micron Technology, Inc. Secure medical apparatus communication

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1802155A1 (de) 2005-12-21 2007-06-27 Cronto Limited System und Verfahren zur dynamischen mehrfaktorfähigen Authentifizierung
DE102011110898A1 (de) 2011-08-17 2013-02-21 Advanced Information Processing Systems Sp. z o.o. Verfahren zur Authentifizierung eines Benutzers zum Gewähren eines Zugangs zu Diensten eines Computersystems, sowie zugehöriges Computersystem, Authentifizierungsserver und Kommunikationsgerät mit Authentifizierungsapplikation
US20200279270A1 (en) * 2019-02-28 2020-09-03 Dan Lieberman Identity-backed authentication and authorization system
US10664451B1 (en) * 2019-08-29 2020-05-26 Blockstack Pbc Systems and methods for encrypting data in backend storage caches shared by multiple decentralized applications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3579524A1 (de) * 2015-02-13 2019-12-11 Yoti Holding Limited Digitales identitätssystem
US20190036688A1 (en) * 2017-07-17 2019-01-31 Thirdwayv, Inc. Secure communication for medical devices
WO2020198182A1 (en) * 2019-03-25 2020-10-01 Micron Technology, Inc. Secure medical apparatus communication

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"OpenID Connect Core 1.0 incorporating errata set 1", vol. 3/20, 22 January 2018 (2018-01-22), pages 1 - 137, XP044240175, Retrieved from the Internet <URL:https://www.itu.int/ifa/t/2017/sg20/exchange/wp1/q3/2018_01_Geneva/A.5/49-OIDF CC.rtf> [retrieved on 20180122] *

Also Published As

Publication number Publication date
DE102020130815B3 (de) 2022-03-31
EP4248348A1 (de) 2023-09-27

Similar Documents

Publication Publication Date Title
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
CN108064440B (zh) 基于区块链的fido认证方法、装置及系统
US10587606B2 (en) Digital certificate with software enabling indicator
AT513016B1 (de) Verfahren und Vorrichtung zur Steuerung eines Schließmechanismus mit einem mobilen Endgerät
EP3220597B1 (de) Verfahren und vorrichtung zum bereitstellen eines einmalpasswortes
EP2962439B1 (de) Lesen eines attributs aus einem id-token
DE60212577T2 (de) Verfahren und vorrichtung zur beglaubigung von daten
KR102177848B1 (ko) 액세스 요청을 검증하기 위한 방법 및 시스템
WO2021047012A1 (zh) 基于token令牌的身份校验方法及相关设备
CN109787988A (zh) 一种身份加强认证和鉴权方法及装置
WO2011131715A1 (de) Verfahren zum lesen eines attributs aus einem id-token
DE102011051498A1 (de) Gesicherter Zugriff auf Daten in einem Gerät
EP3246839B1 (de) Zugangskontrolle mit einem mobilfunkgerät
CN106713279A (zh) 一种视频终端身份认证系统
EP3114600B1 (de) Sicherheitssystem mit zugriffskontrolle
WO2009140953A1 (de) Verfahren, authentikationsserver und diensteserver zum authentifizieren eines client
EP4128695B1 (de) Personalisierter, serverindividueller authentifizierungsmechanismus
CN109698746A (zh) 基于主密钥协商生成绑定设备的子密钥的方法和系统
DE102020130815B3 (de) Dezentrale Bereitstellung von Benutzerdaten
DE102017121648B3 (de) Verfahren zum anmelden eines benutzers an einem endgerät
EP2631837B1 (de) Verfahren zur Erzeugung eines Pseudonyms mit Hilfe eines ID-Tokens
CN106453259A (zh) 一种基于块链接加密技术的互联网金融安全链路实现方法
CN114141345A (zh) 医疗信息处理方法、运营商节点、医院节点和系统
EP3882796A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
EP2933769B1 (de) Transaktionsverfahren

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

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
ENP Entry into the national phase

Ref document number: 2021819361

Country of ref document: EP

Effective date: 20230620