WO2022106653A1 - Fourniture décentralisée de données d'utilisateur - Google Patents

Fourniture décentralisée de données d'utilisateur 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
German (de)
English (en)
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/fr
Publication of WO2022106653A1 publication Critical patent/WO2022106653A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/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

La présente invention concerne un procédé et un dispositif de fourniture sélective de données d'utilisateur, en particulier pour fournir une protection suffisante des données lors de la transmission de données d'utilisateur à un client. L'invention concerne notamment un procédé mis en oeuvre par ordinateur pour la fourniture sélective de données d'utilisateur, comprenant les étapes suivantes : authentification (100) d'un utilisateur (10) ; autorisation (200) d'une fourniture de données d'utilisateur de l'utilisateur (10) demandées à l'aide d'une unité centrale (14) ; et fourniture (300) des données d'utilisateur demandées pour la transmission à l'unité centrale (14). L'autorisation (100) et la fourniture (300) des données d'utilisateur demandées est effectuée au moyen d'un dispositif décentralisé (12), la fourniture (300) des données d'utilisateur demandées comprenant le cryptage (302) de données d'utilisateur mémorisées sur le dispositif décentralisé (12).
PCT/EP2021/082369 2020-11-20 2021-11-19 Fourniture décentralisée de données d'utilisateur WO2022106653A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP21819361.3A EP4248348A1 (fr) 2020-11-20 2021-11-19 Fourniture décentralisée de données d'utilisateur

Applications Claiming Priority (2)

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

Publications (1)

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

Family

ID=78821445

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/082369 WO2022106653A1 (fr) 2020-11-20 2021-11-19 Fourniture décentralisée de données d'utilisateur

Country Status (3)

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

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 (fr) * 2015-02-13 2019-12-11 Yoti Holding Limited Système d'identité numérique
WO2020198182A1 (fr) * 2019-03-25 2020-10-01 Micron Technology, Inc. Communication sécurisée d'appareil médical

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1802155A1 (fr) 2005-12-21 2007-06-27 Cronto Limited Système et procédé pour authentification dynamique basée sur plusieurs facteurs
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

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3579524A1 (fr) * 2015-02-13 2019-12-11 Yoti Holding Limited Système d'identité numérique
US20190036688A1 (en) * 2017-07-17 2019-01-31 Thirdwayv, Inc. Secure communication for medical devices
WO2020198182A1 (fr) * 2019-03-25 2020-10-01 Micron Technology, Inc. Communication sécurisée d'appareil médical

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
EP4248348A1 (fr) 2023-09-27
DE102020130815B3 (de) 2022-03-31

Similar Documents

Publication Publication Date Title
EP3574625B1 (fr) Procédé de réalisation d&#39;une authentification
CN108064440B (zh) 基于区块链的fido认证方法、装置及系统
US20200177580A1 (en) Digital certificate with software enabling indication
AT513016B1 (de) Verfahren und Vorrichtung zur Steuerung eines Schließmechanismus mit einem mobilen Endgerät
EP3220597B1 (fr) Procédé et dispositif destinés à préparer un mot de passe à usage unique
EP2533172B2 (fr) Accès sécurisé aux données d&#39;un appareil
DE60212577T2 (de) Verfahren und vorrichtung zur beglaubigung von daten
CN107124433B (zh) 物联网系统、物联网设备访问方法、访问授权方法及设备
KR102177848B1 (ko) 액세스 요청을 검증하기 위한 방법 및 시스템
EP2962439B1 (fr) Lecture d&#39;un attribut enregistré dans un jeton id
WO2011131715A1 (fr) Procédé de lecture d&#39;un attribut à partir d&#39;un jeton id
WO2021047012A1 (fr) Procédé de vérification d&#39;identité sur la base d&#39;un jeton et dispositif associé
EP3246839B1 (fr) Contrôle d&#39;accès comprenant un appareil radio mobile
EP3114600B1 (fr) Système de sécurité à contrôle d&#39;accès
EP2289222A1 (fr) Procédé, serveur d&#39;authentification et serveur prestataire de services pour l&#39;authentification d&#39;un client
DE102020108828A1 (de) Personalisierter, serverindividueller Authentifizierungsmechanismus
DE102020130815B3 (de) Dezentrale Bereitstellung von Benutzerdaten
DE102017121648B3 (de) Verfahren zum anmelden eines benutzers an einem endgerät
CN106453259A (zh) 一种基于块链接加密技术的互联网金融安全链路实现方法
DE102018102608A1 (de) Verfahren zur Benutzerverwaltung eines Feldgeräts
EP3882796A1 (fr) Authentification de l&#39;utilisateur à l&#39;aide de deux éléments de sécurité indépendants
EP3540623A1 (fr) Procédé de génération d&#39;un pseudonyme à l&#39;aide d&#39;un jeton d&#39;id
EP2933769B1 (fr) Procédé de transaction
DE102017012249A1 (de) Mobiles Endgerät und Verfahren zum Authentifizieren eines Benutzers an einem Endgerät mittels mobilem Endgerät
CN114141345B (zh) 医疗信息处理方法、运营商节点、医院节点和系统

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