Computer-implemented method for providing secure interaction between users in a network

Abstract

A computer-implemented method for securing interactions between users of a computer network is proposed, wherein a first digital identity of a first user among the users is created based on input provided by the first user through a user interface of a first network node, wherein the user input includes a first consent to the creation of the first digital identity and includes first secret information provided by the first user, wherein the first consent and the first secret information are combined to form a first root string, and wherein the first digital identity is created and stored in encrypted form in the network based on the first root string, and wherein the first user uses the first digital identity to interact with other users in the network.

Description

[0001] A computer-implemented method for securing the interaction between at least two users in a network and protecting their privacy is proposed. A corresponding computer program is also proposed. Existing technology

[0002] An overview of the selected proposed identity management systems and the remaining technical challenges can be found in “A First Look at Identity Management Schemes on the Blockchain” by Paul Dunphy and Fabien AP Petitcolas, IEEE Security & Privacy (Volume: 16, Issue: 4, July / August 2018).

[0003] Hyperledger projects provide tools, libraries, and reusable components for providing digital identities rooted in blockchains or other distributed ledgers, making them interoperable across administrative domains, applications, and any other silos. Examples include Indy, Ursa, Aries, and Transact, the latter of which enables smart contracts. Summary of the Invention

[0004] A computer-implemented method for securing interactions between users of a computer network is proposed. A first digital identity is created for a first user among the users based on input provided by the first user via a user interface of a first network node. The first node can be implemented as a smart personal device, such as a smartphone, personal computer, tablet, or similar device. The user input includes a first consent to create the first digital identity and includes first secret information provided by the first user. The first consent and the first secret information are combined to form a first root string. The first digital identity is created based on the first root string and is stored in an encrypted form in the network. The first user uses the first digital identity to interact with other users in the network, in particular for authentication in the network. The users interact via the network, for example, using network nodes.

[0005] This approach enables the decentralized and secure creation of digital identities, and ensures that digital identities are well-characterized and include the essential information required to allow the secure use of a user’s digital identity information: the user’s consent for its creation.

[0006] In a preferred embodiment, the first secret information comprises first biometric information, in particular at least one of an iris sample, a fingerprint sample, a palm vein sample, a specific gesture or a voice sample of the first user. This allows for a particularly secure implementation.

[0007] In a preferred embodiment, the first digital identity is stored in an identity management system in a network. A computer-implemented identity management system is a system comprising at least one processor unit, at least one memory unit, and at least one network interface connecting the system to a network, and is adapted to write digital data representing the digital identity to the memory unit and read digital data from the memory unit. In a preferred embodiment, it is also adapted to write, read, and modify information stored with the digital identity.

[0008] In a preferred embodiment, at least two network nodes are connected via a network. A first user connects to the network via a first of the two network nodes. The first user creates a first identity corresponding to the first user in the network via a software application running on the first network node, wherein the creation includes the first user providing first biometric information characterizing the first user, particularly to the software application running on the first network node. The first biometric information is stored in encrypted form by a computer-implemented identity management system.

[0009] The second user accesses the network via the second network node and requests, via the network, the first user's consent to:

[0010] ○ The second user accesses the first user's secret information, or

[0011] ○ The second user sends a message to the first user, or

[0012] ○ A first identity corresponding to a first user is connected to a second identity corresponding to a second user, or

[0013] ○ The second user is granted access to control the software application assigned to the first identity,

[0014] The request is sent via the identity management system.

[0015] The first user, via the software application, denies or approves the second user's request.

[0016] This embodiment enables the management of personal identities for human users that are strictly limited to that user and protected by personal identity characteristics. Access via software applications running on personal smart devices allows the system to create and manage digital identities in a user-friendly manner while still keeping the creation and management secure and trustworthy.

[0017] In a preferred embodiment, such digital identity management includes a method in which a first user authenticates with an identity management system by providing first biometric information via a software application. Following authentication, the first user modifies the first identity, or information stored with the first identity corresponding to the first user, via the software application running on a first network node. The modification includes adding or removing further biometric information corresponding to the first user, adding or removing secret information, or adding or removing credentials. Additionally or alternatively, to deny or approve the request, the first user authenticates with the identity management system again by providing the first biometric information, further biometric information, or secret information via the software application.

[0018] These embodiments allow for efficient and reliable digital identity management by users, in particular for software applications on the first node.

[0019] In a preferred embodiment of the present invention, the first user's rejection or approval of the second user's request is stored by the software application as one of the recorded consents. The software application can provide the first user with an overview of at least one of the recorded and still pending consent requests, allowing the first user to reject, grant, or revoke any corresponding consent.

[0020] This allows for a particularly user-friendly management of digital identities.

[0021] In a further preferred embodiment, efficient and trustworthy access control is achieved, comprising the following steps:

[0022] - A first identity corresponding to the first user is created and stored in an encrypted form in the identity management system.

[0023] - A second identity corresponding to the second user is created and stored in encrypted form in the identity management system.

[0024] - A first right to access first information or access a first software function or access a first product is assigned to the first identity.

[0025] - The second user requests access to said information or software functionality or product from the first user by sending a request to the identity management system.

[0026] - The identity management system checks the authentication of the second user based on the second identity.

[0027] - the identity management system sends the request to the first user,

[0028] - The first user denies or approves the request by responding to the identity management system.

[0029] - The identity management system checks the authentication of the first user based on the first identity.

[0030] - sharing secret information stored in encrypted form with a second user, dependent on said checking, said secret information allowing the second user to access said information, software functionality or product.

[0031] - A second user accesses the first information or the first software function or product.

[0032] In the following, embodiments of the present invention are explained in detail. The corresponding drawings show:

[0033] Figure 1 An exemplary system for creating, storing, and managing digital identities in a network is shown.

[0034] Figure 2 A schematic flow chart illustrating an exemplary method for creating and managing digital identities in a network is shown.

[0035] Figure 3 An example of users interacting in a network using their digital identities is shown. DETAILED DESCRIPTION

[0036] Managing digital identities in networks is a significant technical challenge. The term "identity" (or ID for short) refers to a set of attributes associated with an entity (ISO 29115). A digital ID is a binary representation of an identity. A human identity is a set of human attributes associated with a human (e.g., the human body). Biometrics are physical measurements and calculations (e.g., binary representations of body parts) and can be an effective way to digitally identify a unique person. Biometrics are data and, therefore, can be stored and stolen. Maintaining the security of stored biometric information is crucial to protecting the privacy of individuals.

[0037] Distributed ledger technology can be used to manage data, and when combined with security measures, it can be used to manage data in a secure manner. For example, a blockchain system can use information packets carried within digital blocks, which contain a cryptographic hash of the previous block and a timestamp, verified through decentralized consensus. Distributed ledger or blockchain technology can be used to create, store, and manage digital IDs.

[0038] Figure 1 An exemplary system for creating, storing, and managing digital identities in a network is shown in FIG. A user 11 interacts with a device 12 connected to a network (e.g., connected to the Internet). In a preferred embodiment, device 12 may be a computing device such as a mobile computing device (smartphone, etc.) having a user interface and a network interface.

[0039] To create a digital identity, user 11 uses a software application running on device 12 to provide first biometric information to the software application on device 12. In a preferred embodiment, the first biometric information is provided to the software application by using sensors of device 12 to measure or record biometric properties (such as images of a human iris, fingerprints, facial features, gestures, voice samples, etc.).

[0040] The software application used by device 12 interacts with software application 13. Software 13 is software running on, for example, a server infrastructure. Information can be securely routed from device 12 to other software applications via software 13. Software application 13 interacts with software application 14 running on an identity management platform. An identity management platform is a platform in which digital identities and corresponding locally stored content are managed using software applications running on the platform's hardware. The first biometric information provided by user 11 to device 12 is securely transmitted via software application 13 running on the server infrastructure to software application 14 running on the identity management platform.

[0041] The identity management platform's software application 14 stores the digital representation of the first biometric information on the identity management platform's storage device. Software application 14 interacts with the distributed ledger system's software application 15. Software application 15 stores the first biometric information locally and stores a hash of the information in the distributed ledger. This hash is stored in encrypted form and forms the seed for user 11's newly created digital identity.

[0042] If user 11 wants to manage his digital identity (for example, add or remove personal secrets, add or remove further biometric information, approve or reject another user's request for consent, request another user's consent, etc.), he can do this in the following way: authenticate based on the first biometric information (or further biometric information or personal secrets added subsequently) and send corresponding information or requests to software application 14 running on the identity management platform via the software application running on device 12 and software application 13.

[0043] This request for consent by another user may, for example, refer to: the other user accessing user 11's confidential information, the other user sending information to user 11, the identity corresponding to user 11 being connected to a second identity corresponding to the other user, or the other user being granted access to control a software application assigned to the identity corresponding to user 11. Generally speaking, consent occurs when a person voluntarily agrees to something. Digital consent is a digital representation of consent in binary form.

[0044] Digital identities can now be formed by merging digital consent and biometrics into a single distributed ledger or blockchain identity. This means that biometrics and digital consent form the core of a digital identity. A distributed ledger or blockchain can store digital identity numbers against hashed digital representations of the biometrics and consent. Each digital identity can contain only the necessary biometric details and be used only for the purpose for which it was consented. Biometrics can be stored on a chip (integrated circuit, packaged coprocessor) along with a timestamp.

[0045] Consents for specific purposes or requests can be packaged with a "yes" (eg, digitally "1") or a "no" (eg, digitally "0") so they can be granted, denied, and revoked.

[0046] This digital identity system enables the implementation of identity tokens—special digital identities that can replace accounts (e.g., email and password) and allow users to manage access. Using these identity tokens, the network can function as a cross-consent identity network. Two consents are required to establish any connection between identities. Therefore, the connection between digital identities is established via human digital consent and remains valid only as long as that human digital consent is not revoked on one end.

[0047] Products or things can have corresponding identities. However, it is proposed that these digital identities rely on and need to be assigned to at least one digital identity corresponding to an actual human being as a base identity. Similarly, a corporate identity can be created that relies on and is assigned to the digital identity of an official representative (e.g., via authorized consent).

[0048] Figure 2 A schematic flow chart illustrating an exemplary method for creating and managing digital identities in a network is shown.

[0049] In the first step 21, a root string representing a digital identity is created. This step begins with input from the user to a software application running on the user's device. The software application requests first biometric information from the user and first consent from the user. This information is used as attributes to create a digital identity, such as a number or block in a distributed ledger or blockchain, i.e., a distributed identifier. The software application can request a name for this first identity. In a preferred embodiment, this name is private (i.e., not shared and only on the device). Only the owner of the identity can decide with whom to share which secret. The software application sends this distributed identifier to an identity management platform using distributed ledger technology. The software application also stores the biometric information on the device using local hardware.

[0050] The requested consent may refer to consent to the creation of a digital identity for the user, and the biometric information may be selected from a selection of different options such as measuring or recording an iris sample, a fingerprint or palm vein sample, a specific gesture, a voice sample, etc.

[0051] Creating a root string representing a digital identity based on the first consent and the first biometric information in this way is secure and meets privacy and data protection requirements. To this end, the first consent is digitized by reducing it to a digital string. The first biometric information is then processed, for example, according to ISO / IEC JTC 1 / SC 37, and added to the digital string representing the first consent. This results in a root string for the digital identity, for example, in compliance with ISO 29115. To ensure security, the hash string representing the digital identity is encrypted. In a preferred embodiment, the digital identity is encrypted using two algorithms, one classical (e.g., elliptic curve) and one that generates post-quantum keys, thereby preventing future attacks. The encrypted string is stored as the digital identity in a distributed ledger (e.g., blockchain) on the hardware storage of the identity management platform.

[0052] Using this approach for creating and managing digital identities provides a technical system that meets data protection requirements for consent, such as:

[0053] - Distinctive and separate (easy to understand, simple / clear language)

[0054] - Active opt-in (no pre-checked box, no default on)

[0055] - Specific and different consents for different data

[0056] - Include reason (why) and purpose (what)

[0057] - Storing information (how, when / timestamp, exact words)

[0058] - Opt-out as easy as opt-in.

[0059] Once the digital identity has been created using the root string, it can be supplemented in a second step 22 by providing further information such as further biometric information or personal secrets, such as a password, or authority-dependent information such as a university diploma, driver's license, personal ID, social security number, medical records, etc. This information can be used as further attributes to be stored as the digital identity and thereby make the digital identity more robust.

[0060] Then, in step 23, the information stored with or as part of the digital identity can be used as proof of legitimacy. It can be used, for example, to verify the information to other users in the network, or to authenticate to other users or network nodes, or to access other network nodes, or to log into applications or services in the network.

[0061] To use information or secrets stored with or as part of the digital identity, a software application running on a user device receives input representing a request, such as:

[0062] - User requests for access to online services,

[0063] - requests for login authorization from online services,

[0064] - Requests from online services for proof of legality (for example, a certain qualifying age, or possession of a document such as a driver's license)

[0065] - Requests to federated identity services (e.g., OpenID),

[0066] - Requests for user-managed access to services (e.g., oAUTH).

[0067] The software application accesses the digital identity to check for consent for the action and whether the necessary information is stored with or as part of the digital identity. If consent and information are stored and valid, the software application creates a token containing only the required and agreed-upon secrets for the specific action. Thus, the token represents a bundle of information that the user wishes or agrees to share with the specific requester. If no consent information is stored for the action, the software application can request user consent. If the requested or necessary information is not stored, the software application may ask the user to create and store it. Finally, the software application shares the token with the requester.

[0068] Thus, a secret and a consent are bundled into a token to serve as a package of information that can satisfy a request for legal proof or authorization information. The token is used to share the minimum required information.

[0069] In an alternative or subsequent step 24, the user can use the digital identity they created to manage consent. To this end, a software application on the user's device receives and stores the user's response to each specific consent request: yes or no (e.g., stored as a 1 or a 0). The software application can create a backlog of requests and enable its user to respond at any time.

[0070] For example, such a request could be the following question: "Do you agree that User A / Service B / Company C would like to send you a newsletter with conditions...?" This question can be triggered by the user himself or by the party seeking consent (i.e., user A, service B, or company C).

[0071] In a preferred embodiment, the software application checks whether the consent questions / conditions comply with predetermined data protection or privacy requirements, such as expiration dates or revocation options.

[0072] In a preferred embodiment, the software application automatically suggests questions related to the requested category to expand a given consent setting. It can also utilize reminders to support revocation, revalidation, and re-consent to enable secret sharing. This functionality can be extended with existing machine learning algorithms to form an assistant to ask questions and keep the support manageable (reminding about expired consents, time limits on existing consents, etc.).

[0073] In a preferred embodiment, the software application can show the user a summary or overview of all or selected consents. The core functionality of such an overview or consent dashboard is to keep the consent management practical for the user, for example by using the following rules:

[0074] - All consents are created with yes or no answers to questions,

[0075] - Consent is therefore visualized as yes or no,

[0076] - All consents can be granted, denied, revoked, re-granted, revoked again, etc. with a single action.

[0077] In an alternative or subsequent step 25, the digital identities can be connected, for example, a newly created digital identity based on the newly created root string. To this end, the software application on the user's device requests consent to establish a one-to-one connection between the first identities. To this end, the software application creates distributed identifiers, such as those for objects or smart products owned by the user. This creation of distributed identifiers occurs only after the user has provided the software application with their corresponding consent. In a preferred embodiment, all distributed identifiers are listed (copied) as attributes in the user's digital identity.

[0078] To concatenate existing root strings, for example, two existing root strings can be hashed to generate a third root string. This third root string can be copied as a secret to the two original root strings in each consent dashboard. These two root strings can reject the existing third root string on both sides. Any number of auxiliary strings can be created through the consent of a single root string. All of these auxiliary strings are concatenated to the single root string through this consent.

[0079] All one-to-one connections (including the identity of the object or smart product) are valid only if the underlying digital identity consent at both ends remains valid.

[0080] The one-to-one connection can be used to share secrets or create smart contracts, for example by using two base identities corresponding to human users to generate a distributed identifier for the smart contract and confirm the agreement between the two identities.

[0081] exist Figure 3 , illustrates an example of users interacting in a network using their digital identities. A first digital identity 311 is created based on a root string created by combining information received from a first user 31, including a first consent and a first secret, such as biometric information. A second digital identity 321 is created based on a root string created by combining information received from a second user 32, including a first consent and a first secret, such as biometric information. A third digital identity 312 is created, for example, for a product, in this example, a car belonging to user 31. Digital identity 312 is connected to and dependent on first digital identity 311. Creation of the third digital identity is only possible with user 32's consent, provided via first digital identity 311. A fourth digital identity 322 is created, for example, for a product, in this example, a garage belonging to user 32. Digital identity 322 is connected to and dependent on second digital identity 321. Creation of the fourth digital identity is only possible with user 32's consent, provided via second digital identity 321.

[0082] The third digital identity corresponding to the car belonging to user 31 and the fourth digital identity corresponding to the garage belonging to user 32 may include consent to actions provided by the respective owners of the products. This consent may include agreement to certain conditions of a smart contract automatically negotiated between the products. For example, user 31 may agree that the car negotiates a smart contract with the garage at a maximum per-parking fee and a negotiated policy or format, and user 32 may agree that the garage negotiates a smart contract with the car at a minimum per-parking fee and a negotiated policy or format. Within these agreed-upon conditions, the products can now negotiate the smart contract themselves, for example, allowing the car to park in the garage (including opening the garage door) for the negotiated parking fee. In alternative embodiments, consent to the negotiated conditions, or consent to negotiate at all, may not be provided in advance, but rather requested from the user through their product via the corresponding digital identity in the digital identity management system.

Claims

1. A computer-implemented method for protecting interactions between users of a computer network, wherein a first digital identity of a first user (11) is created based on input provided by the first user (11) through a user interface of a first network node (12), wherein the user input includes a first consent to the creation of the first digital identity and includes first secret information provided by the first user (11), wherein the first consent and the first secret information are combined to form a first root string by representing the first consent as a binary number and adding the processed first secret information to a digital string representing the first consent, and wherein the first digital identity is created and stored in an encrypted form in the network depending on the first root string, wherein the first user (11) uses the first digital identity to interact with other users in the network by managing digital consent for each consent request, wherein the digital consent is encapsulated with a binary parameter and all digital consents are granted, denied, revoked, re-granted, and revoked again using a single action; wherein at least one distributed identifier of an object or smart product owned by the first user is created via the corresponding consent of the first root string, and the at least one distributed identifier is connected to the first root string via the corresponding consent.

2. The method according to claim 1, characterized in that A first user (11) performs authentication using a first digital identity.

3. The method according to claim 1, wherein Users interact through the network via network nodes.

4. The method according to claim 1 , wherein: The first secret information includes first biometric information, which is at least one of an iris sample, a fingerprint sample, a palm vein sample, a specific gesture, or a voice sample of the first user (11).

5. The method according to claim 4, characterized in that - a first user (11) is connected to the network via a first network node (12), - a first user (11) creates a first identity corresponding to the first user in the network via a software application running on a first network node (12), - a second user accesses the network via a second network node, - The second user requests the first user (11) via the network to agree to the following o The second user accesses the first user's (11) secret information, or ○ The second user sends a message to the first user (11), or o A first identity corresponding to a first user (11) is connected to a second identity corresponding to a second user, or o The second user is granted access to control the software application assigned to the first identity, The request is sent via the identity management system (15), - The first user (11) rejects or approves the second user's request via the software application.

6. The method according to claim 5, characterized in that A first user (11) authenticates to an identity management system (15) by providing first biometric information via a software application, and after said authentication, the first user (11) modifies a first identity, or information stored with the first identity corresponding to the first user (11), via a software application running on a first network node (12), wherein said modification comprises: o add or remove further biometric information corresponding to the first user (11), or ○ Add or remove secret information, or ○Add or remove credentials.

7. The method according to claim 5, wherein: In order to deny or approve the request, the first user (11) authenticates to the identity management system (15) by again providing the first biometric information via the software application, or by providing further biometric information, or by providing secret information.

8. The method according to claim 5, wherein: The rejection or approval of the second user's request by the first user (11) is stored by the software application as one of the recorded consents.

9. The method according to claim 5 , wherein: A first user (11) is provided with an overview of at least one of the recorded and still pending consent requests, one of which is accessible by the first user (11) to deny, grant or revoke the corresponding consent.

10. The method according to claim 1 , wherein: - a first identity corresponding to the first user (11) is created and stored in an encrypted form in the identity management system (15), - a second identity corresponding to the second user is created and stored in encrypted form in the identity management system (15), - a first right to access first information or to access a first software function or to access a first product is assigned to the first identity, - the second user requests access to said information or software function or product from the first user (11) by sending a request to the identity management system (15), - the identity management system (15) checks the authentication of the second user based on the second identity, - the identity management system sends said request to the first user (11), - the first user (11) denies or approves the request by responding to the identity management system (15), - the identity management system (15) checks the authentication of the first user (11) based on the first identity, - depending on said checking, sharing secret information stored in encrypted form with a second user, said secret information allowing the second user to access said information, software function or product, - A second user accesses the first information or the first software function or product.

11. A computer program product having computer instructions stored thereon which, when executed, cause a computer to carry out the method according to one of the preceding claims.

12. A storage device storing the computer program product according to claim 11.

Images