Authentication and encryption schemes in data storage

Abstract

Embodiments of the present invention implement a distributed ledger system, the distributed ledger system comprising a network of entities maintaining an electronic ledger that can track information about events performed by various entities in the network. An operating entity can manage access to the distributed ledger system and can allow certain organizations and users to log into the distributed ledger system. A user device can generate a request to include data in the electronic ledger. The user device can generate a password and send the password along with the request to a reader device, which can initiate a verification process to verify the password. If the password is verified, then data from the user device can be sent to one or more organizations so that the data can be included in the electronic ledger.

Description

[0001] Cross-reference to related applications

[0002] none. Technical Field Background Art

[0003] Performing a personal authentication process can present several problems. For example, the personal authentication process is cumbersome for the entities involved. For users who need to be authenticated, it is cumbersome to have to carry authentication information (e.g., identity card, passport, etc.) and provide the authentication information during the authentication process. Similarly, such a personal authentication process is also cumbersome for the entity requesting the authentication (e.g., resource provider). For example, the personal authentication process may involve a representative having to visually check the user's authentication information, such as comparing the received authentication information with previously stored registration information, which is inefficient. A further problem is that not all users can present the same type of authentication information, and therefore the representative must be able to manage different types of authentication information.

[0004] The above problems are apparent for situations where a large number of sequential individual authentication processes are performed. For example, some event organizers require attendees to provide authentication information in order to gain access to the event. Typically, attendees may carry multiple pieces of information, such as an ID card and a proof-of-payment ticket. However, due to the problems described above, there is a delay during each individual authentication process that is performed. As a result, the rate at which an entity is able to complete the individual authentication process is low.

[0005] Some systems replace processes such as those described above with electronic systems to improve efficiency. For example, some systems utilize electronic ledgers to track information so that most of the processing can be performed digitally, which reduces the time and effort spent by the user. However, such systems often compromise security because they operate based on the anonymity of the end user and therefore do not provide adequate authentication processes. Therefore, the electronic ledger cannot be managed in a sufficiently secure manner.

[0006] Embodiments of the invention individually and collectively address this and other problems. Summary of the invention

[0007] One embodiment of the present invention is directed to a method executable by a user device. The method may include determining data including an electronic identifier associated with a user, determining a key stored in a secure element of the user device, digitally signing the data using the key, determining a cryptogram, and providing the signed data and the cryptogram to a reader device, wherein the reader device may send a request to include the signed data in an electronic ledger upon verifying the cryptogram.

[0008] In some embodiments, the step of determining the password in the method performed by the user device may include some steps. For example, the user device may determine a session key based at least on the intermediate key and the counter value. The user device may then use the session key to encrypt data. In some embodiments, the intermediate key may be a limited use key. In other embodiments, the intermediate key may be a static key.

[0009] In some embodiments, the step of providing the signed data and password to the reader device in the method performed by the user device may include steps. For example, the user device may detect that the reader device is approaching. The user device then sends the signed data and password to the reader device via a short-range wireless connection.

[0010] Another embodiment of the present invention relates to a method that can be performed by a reader device. The method may include: receiving signed data and a password from a user device, wherein the signed data is determined by digitally signing data including an electronic identifier associated with a user using a key stored in a security element of the user device. The method may also include: determining whether the password can be verified, and immediately after verifying the password, sending a request to a remote server computer to include the signed data in an electronic ledger. In some embodiments, the password can be determined using a session key determined based on at least an intermediate key and a counter value. In some cases, the reader device can receive one or more dynamic values ​​from the user device to generate a session key.

[0011] In some embodiments, the step of verifying the password in the method performed by the reader device may include steps. For example, the reader device may determine a session key and decrypt the password using the session to determine a first value. The reader device may also decrypt the signed data to determine a second value. The reader device may then determine that the first value matches the second value.

[0012] In some embodiments, the step of receiving the signed data and the password from the user device in the method performed by the reader device may include some steps. For example, the reader device may detect the user device approaching. The reader device may then receive the signed data and the password from the user device via a short-range wireless connection.

[0013] Embodiments of the present invention are further directed to a user device including a processor and a memory element. The memory element may include code executable by the processor for implementing a method. The method may include determining data including an electronic identifier associated with a user, determining a key stored in a security element of the user device, digitally signing the data using the key, determining a password, and providing the signed data and the password to a reader device, wherein the reader device may send a request to include the signed data in an electronic ledger upon verifying the password.

[0014] Another embodiment of the present invention is directed to a reader device, comprising a processor and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method. The method may include receiving signed data and a password from a user device, wherein the signed data is determined by digitally signing data including an electronic identifier associated with a user using a key stored in a secure element of the user device. The method may also include determining whether the password can be verified, and upon verifying the password, sending a request to a remote server computer to include the signed data in an electronic ledger.

[0015] These and other embodiments of the invention are described in further detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 A block diagram illustrating various elements of an exemplary system according to an embodiment of the invention is shown.

[0017] Figure 2 A block diagram illustrating various elements of an exemplary system according to an embodiment of the invention is shown.

[0018] Figure 3 A block diagram showing various elements of a user device according to an embodiment of the present invention is shown.

[0019] Figure 4 A flow chart showing an exemplary process according to an embodiment of the present invention is shown.

[0020] Figure 5 A flow chart showing an exemplary process according to an embodiment of the present invention is shown.

[0021] Figure 6 A block diagram illustrating an exemplary data structure according to an embodiment of the present invention. DETAILED DESCRIPTION

[0022] Embodiments of the present invention implement a distributed ledger system that includes a network of entities that maintain electronic ledgers, which can track information related to events performed by various entities in the network (e.g., conducting transactions, transmitting messages, etc.). An operating entity can manage access to the distributed ledger system. For example, an operating entity can allow certain entities to log into the distributed ledger system and grant these entities authorization to update information in the ledger of the distributed ledger system. In some cases, these entities can be referred to as institutions, which can include resource providers, authorization entities, processing entities, or other entities trusted by the operating entity. In some embodiments, other users can also utilize the distributed ledger system. For example, a user device operated by a user can perform an action, such as conducting a transaction, where information related to the action can be sent to one or more institutions and verified by the institutions, and then included in the electronic ledger.

[0023] Digital tracking of data is often used in lieu of personal information exchange, such as a personal authentication process. However, these alternative systems often present problems. For example, conventional use of electronic ledgers is often risky because entities that may participate in managing the information in the ledger may not be properly authenticated. In some cases, this may result in malicious entities attempting to manipulate the information stored in the electronic ledger, which could affect all users in the system. In light of these issues, embodiments of the present invention provide an improved system.

[0024] Embodiments of the present invention are directed to a system that makes the management of digital information more secure. For example, even though embodiments of the present invention enable the authentication process to be performed digitally, the system implements a process in which each update in the ledger of a distributed ledger system can be verified by one or more institutions that are explicitly allowed to update the ledger based on a series of cryptographic techniques. However, embodiments of the present invention also provide an efficient authentication process so that users and institutions can utilize the distributed ledger system in an intuitive manner.

[0025] Before discussing specific embodiments and examples, some description of the terms used herein is provided below.

[0026] "Ledger" can refer to a compilation of data. A ledger can include entries with information related to an event, message, or transaction. The ledger can be a database or other comparable data structure that can be configured to store data from all previous entries. In some cases, each entry can include a timestamp of the corresponding event (e.g., a transaction is conducted, an authentication process is performed, a message is transmitted, etc.), as well as information about the entities involved (e.g., a sender and a receiver). In some embodiments, the ledger can be in the form of an electronic ledger. For example, the ledger can be in the form of a blockchain, where data already stored in the electronic ledger is immutable. In some embodiments, some or all entities within the system can store a copy of their own ledger. Figure 6 An exemplary entry in an electronic ledger is shown in FIG.

[0027] "Digital signature" may refer to an electronic signature. In some embodiments, a digital signature may be used to verify the authenticity of information (e.g., a message) sent within a system. A digital signature may be a unique value generated based on the information and a private key using an encryption algorithm. In some embodiments, a digital signature may be verified using a verification algorithm that employs a public key. A digital signature may be a numeric value, an alphanumeric value, or any other type of data including a graphical representation.

[0028] A "key" may refer to a piece of data or information used in an algorithm. A key may be a unique piece of data. In some cases, a key may be an asymmetric key, typically part of a key pair, where a first key may be used to encrypt data and a second key may be used to decrypt the encrypted data. In other cases, a key may be symmetric, which may be used to encrypt data and may be used to decrypt the encrypted data. A key may be a numeric or alphanumeric value and may be generated using an algorithm.

[0029] "Electronic identifier" may refer to a unique string of characters or symbols used to identify an individual. In a preferred embodiment, the electronic identifier may be derived from information associated with the user. For example, in some embodiments, the electronic identifier may be a value calculated by hashing one or more input values ​​(customer name, country code, etc.) that may be used for multiple entities. In this way, the electronic identifier may be independently generated by any entity with the prerequisite information. The electronic identifier may be information associated with the user that has been altered (e.g., hashed and / or encrypted). For example, in some embodiments, the electronic identifier may be derived from a combination of the last four digits of the country code, customer name, date of birth, and social security number, such as SHA256 (USA*JOHN SMITH*19700101*1234). Hashing this value may result in a seemingly random string, such as 754WD2E2513BF546050C2D079FF5D65AB6E318E, and this may be an electronic identifier. In some embodiments, the electronic identifier is associated with a password that must be provided in order to access any interaction record associated with the electronic identifier. An electronic identifier may sometimes be referred to as an “eID,” an electronic identity, or electronic identification data.

[0030] "Transaction data" (which may also be referred to as transaction information) may refer to any data or information surrounding or related to a transaction. For example, transaction data may include transaction details and any data associated with a transaction that may be utilized by entities involved in the transaction process. For example, transaction data may include information that may be used to process and / or verify a transaction. Transaction data may also include any data or information surrounding or related to any participant involved in or associated with a transaction. Example transaction data may include transaction amount, transaction location, received resources (e.g., products, documents, etc.), information about received resources (e.g., size, quantity, type, etc.), resource providing entity data (e.g., merchant data, document owner data, etc.), user data, date and time of the transaction, payment method, and other relevant information.

[0031] A "resource providing entity" may be an entity that can make resources available to users. A resource providing entity may also be referred to as a resource provider. Examples of resource providing entities include merchants, suppliers, vendors, owners, traders, wallet providers, service providers, and the like. In some embodiments, such entities may be a single individual, a group of individuals, or a larger group of individuals (e.g., a company). A resource providing entity may be associated with one or more physical locations (e.g., supermarkets, shopping malls, stores, etc.) and online platforms (e.g., e-commerce websites, online companies, etc.). In some embodiments, a resource providing entity may make resources as physical objects (e.g., goods, products, etc.) available to users. In other embodiments, a resource providing entity may make digital resources (e.g., electronic documents, electronic files, etc.) or services (e.g., digital wallet services) available to users. In some embodiments, a resource providing entity may manage user access to certain resources.

[0032] An "authorization computer" may include any system that implements an authorization process. An authorization computer may determine whether a transaction may be authorized, and may generate an authorization response message including an authorization status (also referred to as an authorization decision). In some embodiments, an authorization computer may be an issuer computer that issues an account (e.g., a payment account) and corresponding account information to a user. In some cases, an authorization computer may store contact information for one or more users.

[0033] A "server computer" may be a powerful computer or a cluster of computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server coupled to a network server.

[0034] Figure 1 An exemplary system 100 having at least some of the components for implementing embodiments of the present invention is shown. System 100 can enable entities to perform a registration process, where various information can be transferred between entities to enable user 101 to log into a distributed ledger system according to embodiments of the present invention.

[0035] Figure 1 The system includes a user 101 operating a user device 110, which can communicate with a service provider computer 120 and a processor server computer 130. The processor server computer 130 can communicate with a profile verification service provider computer 140 and an authorization computer 150. In some embodiments, the user 101 can also operate a wearable device 105. Figure 1The computing devices (e.g., user device 110, wearable device 105, service provider computer 120, processor server computer 130, profile verification service provider computer 140, authorization computer 150) in the embodiment of the present invention can communicate with each other via any suitable communication network. In addition, any of the computing devices (e.g., user device 110, wearable device 105, service provider computer 120, processor server computer 130, profile verification service provider computer 140, authorization computer 150) can include a processor and a computer-readable medium including code, which can be executed by the processor for performing the functionality described herein.

[0036] User 101 may be an entity operating user device 110. User 101 may be an individual or an entity represented by a group of individuals (e.g., a company, etc.). User 101 may be able to input information into user device 110, for example, through a user interface provided by mobile application 114.

[0037] The user device 110 can be any suitable computing device. The user device 110 can include a memory 112, which can store a mobile application 114 and various software development kits (SDKs), such as an electronic identifier SDK 116 and a profile verification SDK 118. The user device 110 can include a network interface and can communicate with one or more entities including a service provider computer 120 and a processor server computer 130 on a communication network. The user device 110 can communicate remotely with a remote entity. In some embodiments, the user device 110 can also communicate short-range by contact or contactless methods (e.g., NFC, Wi-Fi, Bluetooth, etc.). Some non-limiting examples of the user device 110 can include a mobile device (e.g., a cellular phone, a key chain device, a personal digital assistant (PDA), a pager, a notebook computer, a laptop, a notepad, a smart watch, a fitness wristband, jewelry, etc.), a car with a remote communication function, a personal computer, a card (e.g., a smart card, a magnetic stripe card, etc.), etc.

[0038] Wearable device 105 may be any suitable computing device. Wearable device 105 may include a memory that can store information. Wearable device 105 may be portable and wearable by user 101. Typically, wearable device 105 may be capable of short-range communication with an access device through contact or contactless methods (e.g., NFC, Wi-Fi, Bluetooth, etc.). In some embodiments, wearable device 105 may communicate with another device, such as user device 110, over a wireless network. Thus, wearable device 105 may be capable of operating online (e.g., connected to a wireless network) or offline (e.g., not connected to a wireless network).

[0039] The mobile application 114 may provide services accessible by the user device 110. The mobile application 114 may be operated by the processor server computer 130. The mobile application 114 may be capable of receiving information input into the user device 110 by the user 101 and transmitting the information to other entities, such as the service provider computer 120 or the processor server computer 130. In some embodiments, the mobile application 114 may be developed using the electronic identifier SDK 116 and the profile verification SDK 118.

[0040] The electronic identifier SDK 116 may include software tools, libraries, and documentation that enable the generation and use of electronic identifiers. The electronic identifier SDK 116 may be capable of issuing a different electronic identifier for each user. For example, the electronic identifier SDK may be used by the mobile application 114 to request the issuance of an electronic identifier that is unique to the user 101. The electronic identifier SDK may be combined with the electronic identifier service API 133 hosted by the processor server computer 130 to implement this functionality.

[0041] The electronic identifier may be information that is unique to the user. The electronic identifier may be generated based on multiple pieces of information associated with the user (e.g., phone number, social security number, date of birth, nationality, email address, biometric information, etc.) and may be in an obfuscated form (e.g., encrypted) so that the electronic identifier itself does not reveal any sensitive information about the user. Typically, the electronic identifier may be a string consisting of a combination of numbers, alphanumerics, or other characters.

[0042] The profile verification SDK 118 may include software tools, libraries, and documentation that implement verification of profile information associated with a user. For example, the profile verification SDK may implement a request for identification and verification of a user's identity. In some cases, in order to verify a user, the profile verification SDK may request to check various information associated with the user, such as their identity documents, historical behavior information, background checks, risk analysis, and other relevant information. The profile verification SDK 118 may implement this functionality in conjunction with a profile verification service module 134 hosted by the processor server computer 130, which may communicate with a profile verification service provider computer 140. In some embodiments, the profile verification SDK 118 may implement a "know your customer" or "KYC" process.

[0043] The service provider computer 120 may be a server computer that may send and receive information between the user device 110 and the processor server computer 130. The service provider computer 120 may include a proxy service 122 for routing information between the user device 110 and the processor server computer 130. For example, the proxy service 122 may route messages between the electronic identifier SDK and the electronic identifier service API 133 and between the profile verification SDK 118 and the profile verification service module 134. The proxy service 122 may also handle messages from the authorization service API 135.

[0044] Processor server computer 130 may include data processing subsystems, networks, and operations. Processor server computer 130 may route information between entities such as service provider computer 120, profile verification service provider computer 140, and authorization computer 150. In some cases, processor server computer 130 may be used to support and deliver authorization services, as well as clearing and settlement services. In some embodiments, processor server computer 130 may communicate with a payment processing network (e.g., a payment processor computer 120 provided by a provider of a profile verification service provider computer 140). Operational ) is associated with the payment processing network, which may include a wired or wireless network, including the Internet.

[0045] The processor server computer 130 may include various modules and APIs. These modules and APIs may be stored in a memory 131 of the processor server computer 130. The memory 131 may store an application platform module 132, an electronic identifier service API 133, a profile verification service module 134, an authorization service API 135, a provisioning service API 136, a ledger management module 137, and a profile verification and authorization agent 138. Each module may include one or more functions implemented by code that is executable by a data processor of the processor server computer 130. The application platform module 132 may provide software tools and services for the development, assembly, testing, deployment, and management of mobile applications 114.

[0046] exist Figure 1Other modules and sub-modules not shown in the figure may also reside on the memory 131. Examples of additional modules may include modules for processing and routing messages, clearing and settlement modules for processing and routing clearing messages and performing settlements between parties, and data extraction modules (e.g., for retrieving data from external data sources such as databases), storage modules, and message modification modules. Each module resident on the memory 131 may be combined with any additional modules as appropriate. Any module may include one or more sub-modules, wherein each sub-module may include one or more functions implemented by code, which may be executed by a data processor of the processor server computer 130.

[0047] In some embodiments, the processor server computer 130 may also communicate with several databases. The databases may include contact information associated with the user, historical transaction or behavior information associated with the user, or any other information that may be collected over time by the processor server computer 130. Each database may be a conventional, fault-tolerant, relational, scalable, secure database, such as available from Oracle TM or Sybase TM In some embodiments, any database may be combined into a single database, or may be separated into multiple databases.

[0048] The electronic identifier service API 133 can be combined with the data processor of the processor server computer 130 to implement the generation and utilization of electronic identifiers. The electronic identifier service API 133 can be implemented by the data processor to issue different electronic identifiers for users in response to requests to generate electronic identifiers. For example, the electronic identifier service API 133 uses the data processor to issue an electronic identifier that is unique to the user 101 upon a request from the mobile application 114 to generate an electronic identifier.

[0049] The profile verification service module 134 may implement verification of profile information associated with a user in conjunction with the data processor of the processor server computer 130. The profile verification service module 134 may implement identification and verification of the identity of a user via the data processor upon request for verification or profile information. For example, the profile verification service module 134 may perform a verification process in response to a request from the mobile application 114 using the data processor. In some cases, in order to verify the profile information of a user, the profile verification service module 134 may perform a check of various information associated with the user via the data processor, such as the user's identity documents, historical behavioral information, background checks, risk analysis, and other relevant information. The profile verification service module 134 may implement this functionality by communicating with a profile verification service provider computer 140, which may store some or all of the information associated with the user to be verified. In some embodiments, the profile verification service module 134 may forward the received verification request to the profile verification service provider computer 140 using the data processor along with information about how the verification process should be conducted.

[0050] The authorization service API 135 can implement the authorization process in conjunction with the data processor of the processor server computer 130. In some embodiments, the authorization service API 135 can implement the transmission of requests to the authorization computer 150 through the data processor to perform certain authorization processes. For example, the authorization service API 135 can implement the transmission of requests to the authorization computer 150 through the data processor to authorize the activation of an account and the issuance of account information associated with certain users.

[0051] The profile verification and authorization agent 138 may route information between the processor server computer 130 and other entities. For example, the profile verification and authorization agent 138 may route messages between the profile verification service module 134 and the profile verification service provider computer 140 and between the authorization service API 135 and the authorization computer 150. The profile verification and authorization agent 138 may also handle messages from the provisioning service API 136.

[0052] The ledger management module 137 can be combined with the data processor of the processor server computer 130 to implement the management of the distributed ledger system. The ledger management module 137 can manage the information stored in the electronic ledger that can be accessed through the ledger management network through the data processor. The ledger management module 137 can only allow institutions to access the ledger management network through the data processor. For example, the ledger management module 137 can perform a login process for the institution through the data processor so that the institution can be allowed to connect to the network and request to update the information in the ledger. In some cases, the ledger management module 137 can perform the login process through the data processor in the following manner: enable the institution to exchange its account address (e.g., a hash of a public key) on the network for updating the ledger and other information (e.g., a contract) to ensure its authorized status. In some embodiments, each institution can store its own copy of the ledger.

[0053] The ledger management module 137 may also perform, through the data processor, a registration process (e.g., an electronic identifier generation and verification process, a user profile information verification process, etc.) for a user who wants to connect to the ledger management network to store information related to actions they perform with their user devices (e.g., access requests, message transmissions, transactions, etc.). Thus, the ledger management module 137 may manage, through the data processor, communications received through the ledger management network to which various entities in the system may send requests regarding electronic ledgers. The ledger management module 137 may also enable, through the data processor, interfacing with various agents and APIs to communicate with various entities in the distributed ledger system.

[0054] The profile verification service provider computer 140 may be a server computer that implements verification of profile information associated with a user. In some embodiments, the profile verification service provider computer 140 may receive a request from the profile verification and authorization agent 138 to verify the profile information. In some cases, the profile verification service provider computer 140 may also receive information about how the verification process should be conducted. The profile verification service provider computer 140 may perform checks of various information associated with the user, such as their identity documents, historical behavioral information, background checks, risk analysis, and other relevant information. The profile verification service provider computer 140 may store some or all of the information to be verified.

[0055] The authorization computer 150 is typically a computer run by an entity (e.g., a bank) that can provide authorization services. The authorization computer 150 can communicate with the processor server computer 130 to implement the authorization service, for example, through function calls of the authorization service API 135. In some embodiments, the authorization computer 150 may be capable of issuing the user's account information (e.g., an account identifier, etc.) based on the verification of the user's profile information performed by the profile verification service provider computer 140. In some embodiments, the authorization computer 150 may also be referred to as an issuer computer.

[0056] The registration process is described with respect to the components of the system 100. Initially, the user 101 may initiate the authentication process by entering information into the user device 110. For example, the user 101 may enter a request to conduct the registration process into a user interface provided by the mobile application 114. Upon being prompted that user information is required for the registration process, the user 101 may enter his user information into the mobile application 114. The user information may include any suitable information associated with the user 101 that may identify the user 101 (e.g., name, address, telephone number, social security number, date of birth, citizenship, biometric information, etc.). In some embodiments, some or all of the user information may be used by the electronic identifier SDK 116 or the profile verification SDK 118.

[0057] After the request to enter the registration process is made, the electronic identifier SDK 116 can instantly generate and send a request for the electronic identifier of the user 101. The request can be received by the proxy service 122, which can then forward the request to the electronic identifier service API 133. The request can be sent together with the user information for generating the electronic identifier. The electronic identifier service API 133 can then generate the electronic identifier. As described above, the electronic identifier can be information that is unique to the user. The electronic identifier can be generated based on some of all the user information entered by the user 101. In some cases, the electronic identifier can be in an obfuscated form (e.g., encrypted) so that the electronic identifier itself does not reveal any sensitive information about the user. Typically, the electronic identifier can be a string consisting of a combination of numbers, alphanumerics, or other characters.

[0058] After generating the electronic identifier, the electronic identifier service API 133 may send information indicating that the electronic identifier associated with the user 101 has been generated to the ledger management module 137. The information may include the electronic identifier and other information related to the electronic identifier, such as the date and time of generation of the electronic identifier. The ledger management module 137 may update the ledger to include information indicating that the electronic identifier has been issued to the user 101. In some cases, the ledger management module 137 may associate this information with the account address (e.g., public key) of the user 101. Thus, a record may be created in the ledger that the electronic identifier has been issued to the user 101. A confirmation that the electronic identifier has been generated may be sent back to the mobile application 114 along with the electronic identifier. The mobile application 114 may store the received electronic identifier.

[0059] In addition, upon inputting a request to proceed with the registration process, the profile verification SDK 118 may generate and send a request to verify the profile information associated with the user 101. The request may be received by the proxy service 122, which may then forward the request to the profile verification service module 134. The profile verification service module 134 may then process the request and forward the request (e.g., along with additional information specifying conditions for the verification process) to the profile verification and authorization agent 138, which may then transmit the request to the profile verification service provider computer 140 to verify the profile information associated with the user 101. As described above, in some cases, verifying the user's profile information may include checking various information associated with the user, such as their identity documents, historical behavior information, background checks, risk analysis, and other relevant information. The profile verification service provider computer 140 may determine the verification result and send the verification result to the profile verification and authorization agent 138, which may then forward the verification result to the profile verification service module 134.

[0060] If the verification result indicates that the profile information of user 101 has been verified, the profile verification service module 134 may generate a certificate indicating a positive verification result. In some embodiments, the certificate may be a digital certificate, which may include a digital signature of the processor server computer 130 or the profile verification service provider computer 140. A confirmation that the profile information of user 101 has been generated may be sent back to the mobile application 114 along with the certificate. The mobile application 114 may store the received certificate.

[0061] In addition, profile verification service module 134 may send information to ledger management module 137 indicating that the profile information associated with user 101 has been verified. The information may include the generated certificate and other information related to the certificate, such as the date and time of generation of the certificate. Ledger management module 137 may update the ledger to include information indicating verification of the profile information of user 101. In some cases, ledger management module 137 may associate this information with an account address (e.g., a public key) of user 101. Thus, a record may be created in the ledger that the certificate has been issued to user 101.

[0062] In some embodiments, an account may be issued to user 101 during a registration process. Authorization computer 150 may be requested to issue an account. In some cases, information indicating that user 101 has been authenticated may be sent to authorization computer 150 before the account is issued. For example, authorization service API 135 may send some or all of the user information entered by user 101 into mobile application 114 to authorization computer 150 via profile verification and authorization agent 138 along with information indicating that user 101's profile information has been verified (e.g., a generated certificate). Authorization computer 150 may then issue an account for user 101 and generate corresponding account information (e.g., an account identifier, etc.). Authorization computer 150 may send the account information to authorization service API 135 via profile verification and authorization agent 138. The account information may be sent to mobile application 114, which may then store the account information.

[0063] In some embodiments, user 101 may also operate wearable device 105. In this case, provisioning service API 136 may provision information to wearable device 105. For example, profile verification and authorization agent 138 may send information to be provisioned, such as an electronic identifier and an account identifier, to provisioning service API 136, which may then provision the received information to wearable device 105. This may activate wearable device 105 for use in a distributed ledger system according to embodiments of the present invention.

[0064] Figure 2 An exemplary system 200 having at least some of the components for implementing embodiments of the present invention is shown. System 200 may enable an entity to utilize a distributed ledger system according to embodiments of the present invention in a manner such as Figure 1 Information issued during the registration process described. Figure 2 The multiple components shown are Figure 1 , and therefore are not described in detail for the sake of brevity.

[0065] Figure 2 The user 101 is included to operate the user device 110, which can communicate with the resource provider device 210, the service provider computer 120 and the processor server computer 130. The user 101 can download the resource provider SDK 214 in the memory 112. In some embodiments, the user 101 can also operate the wearable device 105. Figure 2 The computing devices (e.g., user device 110, wearable device 105, service provider computer 120, processor server computer 130, resource provider device 210) in the embodiment of the present invention can communicate with each other via any suitable communication network. In addition, any of the computing devices (e.g., user device 110, wearable device 105, service provider computer 120, processor server computer 130, resource provider device 210) may include a processor and a computer-readable medium including code, which may be executed by the processor for performing the functionality described herein.

[0066] Resource provider device 210 can be a computing device associated with a resource provider. Resource provider device 210 can include a memory 212 that can store resource provider SDK 214. Resource provider device 210 can be configured to process data associated with a request to access a resource. Resource provider device 210 can participate in a transaction or provide access to resources (e.g., goods, services, etc.) to consumers (e.g., user 101). In some embodiments, resource provider device 106 can accept a request to access a resource via a website or application. In some embodiments, resource provider device 210 can be associated with a physical storage device that utilizes an access device to accept a personal request to access a resource. In addition, in some embodiments, resource provider device 210 can be an access device (e.g., a terminal device, a mobile point of sale device, etc.) associated with a resource provider and can communicate with a resource provider computer.

[0067] The resource provider SDK 214 may include software tools, libraries, and documentation that enable the user device 110 and the resource provider device 210 to communicate information so that the user 101 can request access to resources from the resource provider. For example, the resource provider SDK 214 may enable information stored by the mobile application 114 (e.g., electronic identifiers, credentials, etc.) to be transmitted to the resource provider device 210. In addition, the resource provider SDK may enable the resource provider device 210 to request verification of information received from the user device 110.

[0068] The components of system 200 are described with respect to the process for utilizing the information issued during the registration process. Initially, user 101 may present user device 110 or wearable device 105 to resource provider device 210. In an exemplary case, resource provider device 210 may be an access device (e.g., a mobile device) associated with a resource provider that may be used for a personal authentication process. In some cases, user 101 may utilize the authentication process to request access to an event at a physical location. User 101 may bring user device 110 or wearable device 105 close to resource provider device 210. Resource provider device 210 may detect the proximity of user device 110 or wearable device 105, and may then receive information from user device 110 via short-range wireless communication (e.g., NFC, Wi-Fi, Bluetooth, etc.).

[0069] Resource provider device 210 may then generate and send a request to verify the received information. In some cases, the received information may include an electronic identifier associated with user 101 and a certificate indicating verification of the profile information of user 101 received during the registration process. The request may be sent to electronic identifier service API 133 via proxy service 122 along with the electronic identifier. Additionally, the request may be sent to profile verification service module 134 via proxy service 122 along with the certificate.

[0070] The electronic identifier service API 133 may communicate with the ledger management module 137 to determine whether the received electronic identifier can be verified. For example, the electronic identifier service API 133 may request the ledger management module 137 to determine whether the electronic ledger includes a record of information indicating that the electronic identifier has been issued to the user 101. In some cases, the request may indicate a public account address of the user 101 (e.g., a hashed public key) associated with a record stored in the electronic ledger corresponding to the user 101. In response, the ledger management module 137 may perform a search (e.g., a lookup function) to determine the records associated with the user 101 based on the public account address of the user 101, and then determine whether any retrieved records indicate that the electronic identifier received from the user device 110 has been issued to the user 101. For example, the ledger management module 137 may determine that the electronic identifier is valid by verifying one or more digital signatures stored in the record indicating the issuance of the electronic identifier. One or more authorized entities (e.g., a processor server computer, an authorization computer, etc.) that handle the issuance of the electronic identifier may include the one or more digital signatures. If it is determined that the electronic identifier has been issued to the user 101 , a confirmation response may be sent to the electronic identifier service API 133 , which may then send a confirmation to the resource provider device 210 via the proxy service 122 .

[0071] In addition, the profile verification service module 134 may communicate with the ledger management module 137 to determine whether the received certificate can be verified. For example, the profile verification service module 134 may request the ledger management module 137 to determine whether the ledger includes a record of information indicating that the certificate has been issued to the user 101. In some cases, the request may indicate a public account address of the user 101 (e.g., a hashed public key) associated with a record stored in the electronic ledger corresponding to the user 101. In response, the ledger management module 137 may perform a search (e.g., a lookup function) to determine the records associated with the user 101 based on the public account address of the user 101, and then determine whether any retrieved records indicate that the certificate received from the user device 110 has been issued to the user 101. For example, the ledger management module 137 may determine that the certificate is valid by verifying one or more digital signatures stored in the record indicating the issuance of the certificate. One or more authorized entities (e.g., a processor server computer, an authorized computer, etc.) handling the profile verification process may include the one or more digital signatures. If it is determined that credentials have been issued to user 101 , a confirmation response may be sent to profile verification service module 134 , which may then send a confirmation to resource provider device 210 via proxy service 122 .

[0072] The resource provider apparatus 210 may then recognize that the user 101 has been authenticated. The resource provider apparatus 210 may then allow the user to access a resource, which in this case may be an event at a physical location.

[0073] Although Figure 1 and Figure 2 An exemplary system is shown, but it should be understood that the embodiments are not so limited. Figure 1 and Figure 2 A single user device 110 , a single resource provider device 210 , and a single authorization computer 150 are shown, but the system may actually include multiple user devices, resource provider devices, and authorization computers in communication with each other and with the service provider computer 120 and the processor server computer 130 .

[0074] exist Figure 1 and Figure 2The communication network in which any computing device in can communicate with each other may include multiple networks for the secure transmission of data and information between entities. In some embodiments, the communication network may follow a suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channel may include a "secure communication channel" that can be established in any known manner, including using mutual authentication and session keys and establishing an SSL session. However, any method for creating a secure channel may be used. By establishing a secure channel, sensitive information related to user 101 can be safely transmitted.

[0075] Any suitable communication protocol may be used to generate the communication channel. Suitable communication networks may be any one and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an operating mission as a node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., using protocols such as, but not limited to, wireless application protocol (WAP), I-mode, and / or the like); and / or the like.

[0076] Messages between the computers, networks, and devices described herein may be transmitted using secure communications protocols, such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Sockets Layer (SSL), ISO (e.g., ISO 8583), and the like.

[0077] Figure 3 A block diagram of an exemplary user device 302 is depicted. Figure 3 Several components are shown, and user device 302 according to embodiments of the invention may include any suitable combination or subset of such components.

[0078] The user device 302 may include a processor 302D (e.g., a microprocessor) for processing functions of the user device 302. One exemplary function supported by the processor 302D includes processing functions of the display 302G to allow the user to see information (e.g., interfaces, contact information, messages, etc.). The processor 302D may include hardware within the user device 302 that can execute instructions implemented as code in a computer-readable medium.

[0079] An exemplary processor may be a central processing unit (CPU). As used herein, a processor may include a single-core processor, multiple single-core processors, a multi-core processor, multiple multi-core processors, or any other suitable hardware combination configured to perform arithmetic operations, logical operations, and / or input / output operations of a computing device.

[0080] User device 302 may include security element 302A. Security element 302A may be a secure memory on user device 302, so that the data contained on security element 302A cannot be easily attacked, cracked or obtained by unauthorized entities. Security element 302A may be used for hosting and storing data and applications that may require a higher degree of security for user device 302. Security element 302A may be provided to user device 302 by security element issuer. Security element 302A may be embedded in the handset of user device 302 or in a subscriber identity module (SIM) card that may be loaded and unloaded from user device 302. Security element 302A may also be included in an additional device, such as a micro-secure digital (micro-SD) card or other mobile storage devices.

[0081] The security element 302A may store any suitable sensitive information. For example, the security element 302A may store access data associated with a user (e.g., account information, token information, etc.). Other information that may be stored in the security element 302A may include user information or user data (e.g., name, date of birth, contact information, etc.). In other embodiments, some, none, or all of the above information may be stored in the memory element 302C or may be stored at a remote server computer (e.g., in the cloud).

[0082] The user device 302 may include a memory element 302C (e.g., a computer-readable medium). The memory element 302C may be present within the body of the user device 302, or may be detachable from the body of the user device 302. The body of the user device 302 may be in the form of a plastic substrate, a housing, or other structure. The memory element 302C may store data (e.g., an application, etc.) and may be in any suitable form (e.g., a magnetic strip, a memory chip, etc.).

[0083] Memory element 302C may include mobile application 302B. Mobile application 302B may be computer code or other data stored on a computer-readable medium (e.g., memory element 302C or secure element 302A) that may be executed by processor 302D to complete a task (e.g., provide a service). Mobile application 302B may be an application that operates on user device 302 and may provide a user interface for user interaction (e.g., to input and view information).

[0084] In some embodiments, the mobile application 302B may be a service provider application. The mobile application 302B may communicate with a service provider computer to retrieve and return information during processing of any of a number of services provided to the user via the user device 302 (eg, providing access to resources).

[0085] The user device 302 may also include a contactless element 302E, which may be generally implemented in the form of a semiconductor chip (or other data storage element) having an associated wireless transmission (e.g., data transmission) element such as an antenna 302F. The contactless element 302E may be associated with the user device 302 (e.g., embedded in the user device). The data or control instructions transmitted by the cellular network may be applied to the contactless element 302E by means of a contactless element interface (not shown). In some cases, the contactless element interface may be used to allow data and / or control instructions to be exchanged between the user device circuit system (therefore, the cellular network) and the optional contactless element 302E.

[0086] The contactless element 302E may be capable of transmitting and receiving data using near field communication (NFC) capabilities (or NFC medium) that typically conform to a standardized protocol or data transfer mechanism (e.g., ISO 14443 / NFC). The user device 302 may support contactless transactions using the EMV contactless communication protocol (EMV-CCP) based on ISO 14443 to interact with the access device. This capability may typically be met by implementing NFC. The NFC capability of the user device 302 may be enabled by an embedded NFC chip, or by adding an external memory card or accessory containing an NFC chip. NFC capability is a short-range communication capability, such as RFID, Infrared or other data transfer capabilities may be used to exchange data between the user device 302 and the interrogation device. Thus, the user device 302 may be able to communicate and transfer data and / or control instructions via both the cellular network and the near field communication capabilities.

[0087] The user device 302 may also include an antenna 302F for wireless data transmission (e.g., data transmission). The antenna 302F may be used by the user device 302 to send and receive wireless communications. The antenna 302F may help connect to the Internet or other communication networks and implement data transmission functions. The antenna 302F may support SMS, USSD, and other types of cellular communications, such as voice calls and data communications.

[0088] The user device 302 may include a display 302G that can show information to the user. The display 302G may be any suitable screen that supports touch functionality. In some embodiments, the display 302G of the user device 302 may display a user interface (e.g., a user interface of a mobile application or website) that allows the user to select and interact with objects presented on the display 302G. Objects may include, but are not limited to, menus, text boxes, icons, and keys / inputs on a virtual keyboard.

[0089] The user device 302 may include a speaker 302H, which may be any suitable device that can produce sound in response to an electrical audio signal. The speaker 302H may play recorded sounds and pre-recorded messages to communicate with the user. In some cases, the user may receive instructions via voice communications played by the speaker 302H, to which the user may respond (e.g., by returning a voice command, activating an input element, etc.).

[0090] The user device 302 may include a microphone 302I, which may be any suitable device that can convert sound into electrical signals. The microphone 302I may be used to capture one or more voice clips from the user. For example, the microphone 302I may allow the user to transmit his or her voice to the user device 302. In some embodiments, the user may provide instructions to the user device 302 using voice commands detected by the microphone 302I. In some cases, the user may provide voice commands detected by the microphone 302I to navigate between mobile applications 302B.

[0091] The user device 302 may also include input elements 302J to allow the user to input information into the device. Example input elements 302J include hardware and software buttons, audio detection devices (e.g., microphones), biometric readers, touch screens, etc. The user may activate one or more of the input elements 302J to pass user information to the user device 302. In some cases, one or more of the input elements 302J may be used to navigate between various screens of the mobile application 302B.

[0092] In some embodiments, if user device 302 is a phone or other similar computing device, user device 302 may include a browser stored in memory element 302C and may be configured to retrieve, present, and send data via a communication network (e.g., the Internet). In such embodiments, user device 302 may be configured to send data as part of a transaction. In some embodiments, user device 302 may provide data immediately upon receiving a request from another entity (e.g., an access device).

[0093] Figure 4 An exemplary flow chart 400 is depicted in accordance with an embodiment of the present invention. Figure 4 The overall flow from registration to utilizing information issued during registration is shown involving a single user device 410 .

[0094] Figure 4A ledger management network 470 is included, which can be a network that can be used to manage information in a distributed ledger system. In some embodiments, various entities including users (e.g., user 401), organizations (e.g., resource providers associated with resource provider devices 450, authorized entities associated with authorized computers 440, etc.), and operational entities 480 can connect to the ledger management network 470 to manage information associated with electronic ledgers hosted by the ledger management network 470. In some embodiments, each organization can store its own copy of the electronic ledger. Any entity can communicate with the ledger management network 470 through a proxy service. In some embodiments, the proxy service can be operated by one or more intermediate computing devices (not shown) that can route information between entities.

[0095] It should be appreciated that entities in the system can perform a login process so that they can communicate with the ledger management network 470. For example, each entity can have its own public and private key pair that they can use to generate digital signatures or decrypt information. In addition, the ledger management network 470 can issue a different public and private key pair to each entity for use with the electronic ledger. For example, the public key of a key pair issued by the ledger management network 470 for an entity can be used to generate a public account address (e.g., a hashed public key) for the entity. The public account address can be used by the ledger management network 470 to associate any information entered into the electronic ledger by the entity with the entity.

[0096] In some embodiments, operations entity 480 may manage communications received by ledger management network 470. Operations entity 480 may also handle the registration of authorized entities that may update electronic ledgers, management of key distribution and utilization by entities in the system, and trust management between entities utilizing ledger management network 470. In some embodiments, operations entity 480 may be a provider of information and communication services related to the ledger management network 470. Figure 1 and Figure 2 Thus, in the exemplary case, the operation entity 480 may be a processor server computer 460. Communications with the operation entity 480 may be transmitted through the operation entity agent 478.

[0097] Figure 4 Some of the components shown may have Figure 1-3 The functionality of those described above is similar to that of the components described above, and therefore, detailed descriptions of these components are not repeated for the sake of brevity. For example, user 401 may include Figure 1-2 The user device 410 may include features similar to those of the user 101. Figure 1-2 The user device 110 and Figure 3 The mobile application 414 may include features similar to those of the user device 302 in Figure 1-2 Mobile applications 114 and Figure 3 The profile verification computer 420 may include features similar to those of the mobile application 302B. Figure 1 The configuration file of the authentication service provider computer 140 has similar characteristics, and the authorization computer 440 includes Figure 1 The resource provider device 450 may include features similar to those of the authorized computer 150 of Figure 2 The resource provider device 210 of the processor server computer 460 may have features similar to those of the resource provider device 210 of the processor server computer 460, and the processor server computer 460 may include features similar to those of the resource provider device 210 of the processor server computer 460. Figure 1-2 The processor of server computer 130 has similar characteristics to those of the processor of server computer 130.

[0098] In addition, it should be understood Figure 4 Some components of the system are not explicitly shown in the Figure 4 The transmission of the described information may be transmitted via one or more entities (e.g., proxy services, computers, APIs, etc.), some of which may not be in the Figure 4 As shown in Figure 1 and Figure 2 Described in.

[0099] In step 1, the registration server 402 may redirect the mobile application 414 to a registration page to initiate a registration process for the user 401 operating the user device 410. The registration page may request the user 401 to enter user information to perform the registration process. In some cases, the registration server 402 may be part of the processor server computer 460, so that the registration server 402 may implement the registration service in conjunction with an application platform module of the processor server computer 460, such as Figure 1-2 The application platform module 132.

[0100] In step 2, user 401 may input user information into mobile application 414, which may then process the received user information. In some cases, the user information may include authentication information (e.g., biometric information) so that user device 410 may determine that a real user is performing the registration process based on the authentication information before proceeding. Mobile application 414 may then call user API 416 (e.g., Figure 1 The electronic identifier service API 133 of the present invention is used to request the generation of an electronic identifier associated with the user 401 ( Figure 4 The generated electronic identifier can then be returned to the mobile application 414. Figure 1 Additional details regarding the generation of electronic identifiers are described.

[0101] At step 3, mobile application 414 may send a request to verify profile information associated with user 401 to profile verification computer 420. Profile verification computer 420 may perform a verification process to determine whether user 401 can be verified. Profile verification computer 420 may send a verification result to mobile application 414, which may indicate that user 401 has been verified. This verification process may indicate that user 401 can be trusted to connect to ledger management network 470. Figure 1 Additional details regarding authenticating user 401 based on profile information are described.

[0102] In some embodiments, the electronic ledger may be updated with information based on the completion of steps 2 and 3. For example, information indicating the generation of an electronic identifier associated with user 401 and the verification result provided by profile verification computer 420 may be sent to user agent 418, which may then send a request to ledger management network 470 to update the electronic ledger with this information. In some cases, the request may indicate a public account address associated with user 401 (e.g., a hashed public key) so that this information indicating the issuance of the electronic identifier may be stored in a record associated with user 401 in the electronic ledger. In some cases, a user agent may have participated in a transaction such as Figure 1 The operational entity 480 that describes the process of generating and verifying an electronic identifier and verifying a user's profile information may digitally sign the information and update the ledger with the information.

[0103] At step 4, mobile application 414 may send a request to authorization computer 440 to activate an account associated with user 401. In some cases, mobile application 414 may send user information entered by user 401, profile verification information (e.g., verification results), an electronic identifier associated with user 401, and other information to indicate to authorization computer 440 that user 401 has been verified. In some embodiments, authorization computer 440 may call authorization entity API 426 (e.g., Figure 1 401) to check whether the verification result determined by profile verification computer 420 indicates that user 401 has been verified, and if so, to authenticate the electronic identifier associated with user 401. In some embodiments, authorization computer 440 may authenticate the electronic identifier by digitally signing the electronic identifier using its own private key.

[0104] In some embodiments, the electronic ledger may be updated based on the completion of step 4. For example, the electronic identifier digitally signed by the authorization computer 440 may be sent to the authorization entity agent 428. The authorization entity agent 428 may then send a request to the ledger management network 470 to update the electronic ledger to indicate that the authorization computer 440 has authenticated the electronic identifier associated with the user 401.

[0105] Subsequently, authorization computer 440 may activate an account associated with user 401. Authorization computer 440 may issue an account hosted by authorization computer 440. In some embodiments, authorization computer 440 may be an issuer computer that may activate an account of user 401 by issuing a payment account of user 401 and generating payment account information associated with the account, such as an account identifier (e.g., a primary account number). Authorization computer 440 may then associate the account information of the issued account with a public account address (e.g., a hashed public key) associated with user 401, wherein the public account address may be used to indicate all information associated with user 401 stored in an electronic ledger. In some embodiments, user 401 may register when performing the registration process in step 2 or 3 and as described with respect to Figure 1 The assigned public-private key pair is described in more detail.

[0106] At step 5, user 401 may utilize the information issued during the registration process. In some cases, user 401 may request access to a resource from a resource provider, such as access to an event at a physical location. User 401 may present user device 410 to resource provider device 450 associated with the resource provider. User device 410 and resource provider device 450 may establish a wireless connection (e.g., NFC, Wi-Fi, Bluetooth, etc.) over which user device 410 may send an electronic identifier and password associated with user 401 to resource provider device 450. Figure 5 The generation of the password is discussed in further detail. The resource provider device 450 may verify the password received from the user device 410 and then call the resource provider API 436 (e.g., Figure 2 The electronic identifier service API 133 of the resource provider can also verify the received electronic identifier. The resource provider API 436 can send a request to the resource provider agent 438 to determine whether the electronic identifier can be verified based on the information stored in the ledger.

[0107] Resource provider agent 438 may forward the request to ledger management network 470. Operational entity 480 may then determine whether there is a record that the electronic identifier is authenticated. In this case, operational entity 480 may determine, based on information indicated by ledger management network 470, that the ledger indicates that the electronic identifier has been authenticated (e.g., digitally signed) by authorization computer 440, as described in step 4. Ledger management network 470 may verify the digital signature of authorization computer 440 using the public key of authorization computer 440, and therefore determine that the electronic identifier received from user device 410 is valid. Subsequently, the resource provider may allow user 401 to access the resource, such as allowing user 401 to enter a physical location.

[0108] Figure 5 An exemplary flow chart 500 according to an embodiment of the present invention is depicted. Flow chart 500 illustrates how data associated with a user device may be processed before being included in an electronic ledger. It should be appreciated that user device 510 may include data associated with Figure 1-2 The user device 110, Figure 3 The user device 302 and Figure 4 In addition, it should be understood that reader device 530 may also be referred to as a resource provider device and may include features similar to those of user device 410. Figure 2 The resource provider device 210 and Figure 4 Features similar to those of resource provider device 450.

[0109] The user device 510 may be operated by a user requesting access to a resource (e.g., to enter a physical location) from a resource provider. The user device 510 may communicate with a reader device 530 associated with the resource provider. The user device 510 may run a mobile application that may be hosted by a remote server computer, such as a processor server computer that the user used to perform a previous registration process, as described in connection with FIG. Figure 1 and Figure 4 To receive access, a user may utilize a mobile application to request to be authenticated based on information in an electronic ledger of a distributed ledger system. For example, the user may perform one or more of the following: navigate to a page on the mobile application to send an access request, enter information related to the request into the mobile application, and enter an indication to initiate transmission of the request (e.g., by activating a button).

[0110] At step S51, data 502 may be determined. Data 502 may include any suitable information related to the user's access request. In some embodiments, data 502 may include the date and time of the request, identification information associated with the user and the resource provider, authentication information of the user, a device identifier associated with the user device 510, an account identifier of an account associated with the user, information indicating that a resource is being requested, or other information. Some of the information included in data 502 may be information input by the user into the user device 510 or gathered from a remote server computer hosting a mobile application utilized by the user.

[0111] At step S52, the data 502 may be hashed. The hashing may be performed using a hash function that implements a one-way encryption function. The data 502 may be hashed using any suitable hash function (e.g., a SHA-2 hash function). Hashing the data 502 may output data 506 to be signed. In an exemplary case, the data 502 may be hashed using a secure hash algorithm SHA-256 so that the resulting data 506 to be signed may be a 256-bit digest.

[0112] In step S53, the data to be signed 506 may be provided to the user device 510. It should be appreciated that steps S51 to S53 may be performed by the user device 510 in communication with a remote server computer hosting a mobile application running on the user device 510. For example, in some cases, the user device 510 may export the data to be signed 506. In other cases, the remote server computer may determine the data to be signed 506 based on the data 502 and the hash function, and provide the data to be signed 506 to the user device 510 via the mobile application.

[0113] At step S54, the user device 510 may digitally sign the data to be signed 506 to determine the signed data 526. In some cases, the user device 510 may digitally sign the data to be signed 506 using a secret key 514 stored in a secure element 512 of the user device 510. In some embodiments, the secret key 514 may be a private key of a public key-private key pair associated with a user operating the user device 510. The public key-private key pair may be issued to the user (e.g., distributed to the user device 510) during a previous registration process performed with a remote server computer.

[0114] At step S55, the user device 510 may generate a password 528. The password 528 may be a dynamically generated value unique to the request processed in the process 500. The password 528 may be generated by encrypting the data to be signed 506 with the session key 520, which may be a dynamic value. It should be appreciated that any suitable algorithm may be used to generate the password. Figure 5518 and session key 520. For example, additional parameters not explicitly shown may be utilized to derive intermediate key 518 and session key 520. Some exemplary additional parameters that may be utilized include temporary flags, random values, counter values, or other unique values. In some embodiments, the derivation method for password 528 may be unique to user device 510 or a group of user devices.

[0115] Session key 520 may be generated based on intermediate key 518 and counter value 524. Counter value 524 may be a number that is updated (e.g., increased by one) for each iteration so that a different counter value is used for each password generation. In some embodiments, intermediate key 518 may be a static key generated based on identity key 516 and electronic identifier 522. In other embodiments, intermediate key 518 may be a limited-use key that is valid for a limited number of uses (e.g., one or more uses). Limited-use keys may be generated in any suitable manner using one or more dynamic values. For example, limited-use keys may be generated using a temporary flag in addition to identity key 516 and electronic identifier 522. In other cases, dynamic values ​​may be used instead of Figure 5 In some cases, identity key 516 may be a shared secret provided to user device 510 at an earlier time by an authorized entity that can verify the password, and electronic identifier 522 may be stored by user device 510 during a previous registration process.

[0116] At step S56, the user device 510 may send the signed data 526 and the password 528 to the reader device 530, which may initiate a verification process for the password 258. In some embodiments, the reader device 530 may verify the password 528, and in some cases, the reader device 530 may verify the password while communicating with a remote server computer, which may send information over a wireless network to the reader device 530. In some cases, the remote server computer may be a resource provider computer associated with a resource provider operating the reader device 530.

[0117] To verify the password 528, the reader device 530 can determine the key used to decrypt the password 528, and then use the key to decrypt the password 528. In some cases, this key can be a session key 520 that can be derived based on an algorithm. In some cases, the reader device 530 can know the algorithm used to generate the session key 520 or can receive information indicating the algorithm from a remote server computer. In some cases, the reader device 530 can receive some information used to generate the session key 520 from the user device 510. For example, the user device 510 can provide the reader device 530 with some dynamic values ​​that can be used to generate the session key 520, such as the counter value 524, so that the reader device 530 has all the parameters for completing the generation of the session key 520. After the session key 520 is generated, the reader device 530 can immediately use the session key 520 to decrypt the password 528 to obtain the first value (e.g., the data to be signed 506). The reader device 530 may then decrypt the signed data 526 using the public key associated with the user device 510 to obtain a second value (e.g., the data to be signed 506). The reader device 530 may then compare the first value with the second value. If the comparison shows that the two values ​​match, this may indicate that the password 528 is verified. Therefore, the reader device 530 may determine that the password 528 is valid and may proceed to perform step S57.

[0118] The use of passwords as shown in process 500 increases the security of the computer system as a whole. For example, verification of the password can ensure that the request to include information in the electronic ledger received from the user device is authentic. This is because it would be difficult for a malicious entity to guess the algorithm and parameters used to generate the exact password, especially because it is a dynamic value. Since the malicious entity cannot impersonate the real user without the exact password, the chance of a fraudulent request to update the electronic ledger being successful can be reduced. In addition, for a fraudulent entity to perform fraudulent activities, the fraudulent entity must have an identity key 516 specific to the user device 510, as well as an electronic identifier 522 specific to the user operating the user device 510. Therefore, embodiments of the present invention improve the data security of conventional systems.

[0119] At step S57, the reader device 530 may send a request to include the signed data 526 to the ledger 550. It should be appreciated that one or more authorized entities may further process the signed data 526 before the signed data 526 may be added to the ledger 550. For example, the signed data 526 may be formatted so that it is in a format compatible with the ledger 550. Figure 6 An exemplary entry in the ledger is shown in FIG.

[0120] Figure 6Depict several exemplary entries in an electronic ledger according to an embodiment of the present invention. In some embodiments, the electronic ledger may be in the form of a blockchain. Data originating from a user device may be stored in a data block entry of the electronic ledger. Each entry may include a data header including information that makes the new entry unchangeable without detection. For example, the data header may include a hash of the previous entry and a root value calculated based on all past data block entries. Since each entry in the ledger may be generated in a similar manner by including a data header storing information referencing its previous entry and all previous entries, the entry cannot be modified without affecting all subsequent entries. This ensures that any tampering of the information will not go unnoticed.

[0121] In some embodiments, each data block entry may include data associated with one or more events (e.g., transactions). In some embodiments, an event may include a sender providing a resource to a recipient. In these cases, the data may include date and time, recipient identification data (e.g., recipient identifier, electronic identifier, etc.), sender identification data (e.g., sender identifier), one or more device identifiers associated with devices operated by the sender and recipient, and resource details related to each event (e.g., resource type, serial number, price, amount, etc.). In some embodiments, a data block entry may include a digital signature included by a user device or other authorized entity. Figure 6 The exemplary entries shown are not intended to be limiting. For example, the data included in a data block entry may be different from Figure 6 In some cases, the order of the included data fields may be different. In addition, any data field shown may be omitted or split into multiple data fields. In some cases, additional data fields related to the recorded event may be included in the data entry block.

[0122] Conventional systems can utilize electronic ledgers to improve efficiency, but they are often not sufficiently secure. For example, they typically do not enable a verification process to ensure the authenticity of a particular end user or a particular device. This problem is exacerbated when these systems operate based on the anonymity of the end user, which increases the risk that a malicious entity can successfully impersonate a real user and attempt to add false data to the electronic ledger.

[0123] In contrast, embodiments of the present invention provide systems that utilize electronic ledgers to track information without compromising security. Embodiments of the present invention include several mechanisms that increase security compared to conventional systems. For example, end users of the electronic ledger are authenticated through a thorough authentication process before being able to connect to the electronic ledger network. For example, embodiments of the present invention implement a profile verification service that can verify profile information of a user operating a user device so that only user devices associated with trusted users can connect to the electronic ledger network. In addition, embodiments of the present invention enable only authorized entities (e.g., resource provider computers, authorization computers, etc.) to update information in the electronic ledger, which abandons the typical anonymity surrounding entities that can manage information in the electronic ledger.

[0124] In addition, embodiments of the present invention can prevent malicious entities from impersonating real users. For example, a user device cannot simply send a request to include some digitally signed data in an electronic ledger. In fact, embodiments of the present invention provide a prerequisite for the user device to generate and submit a valid password to a reader device during a transaction. Verification of the password by another entity can ensure that the request to include information in the electronic ledger received from the user device is authentic. Since it will be difficult for a malicious entity to determine the algorithm and parameters used to generate the accurate password, especially because it is a dynamic value, the chance of success of a fraudulent request to update the electronic ledger can be reduced. Therefore, embodiments of the present invention provide the benefits of an electronic system based on an electronic ledger while improving certain security issues of conventional systems.

[0125] It should be understood that additional methods and processes may be included within the methods described herein and may be identified by those skilled in the art in view of the following description. In addition, in some embodiments of the present invention, the methods may be combined, mixed, and matched as recognized by those of ordinary skill in the art.

[0126] A computer system can be used to implement any of the entities or components described above. The subsystems of a computer system can be interconnected via a system bus. Additional subsystems may include a printer, a keyboard, a fixed disk (or other memory including a computer readable medium), a monitor coupled to a display adapter, and other devices. Peripheral devices and input / output (I / O) devices coupled to an I / O controller (which may be a processor or any suitable controller) may be connected to a computer system by any number of means known in the art (e.g., serial ports). For example, a serial port or external interface may be used to connect a computer device to a wide area network such as the Internet, a mouse input device, or a scanner. Interconnection through a system bus allows a central processing unit to communicate with each subsystem, and controls the execution of instructions from a system memory or a fixed disk and information exchange between subsystems. System memory and / or a fixed disk may embody a computer readable medium. In some embodiments, the monitor may be a touch-sensitive display screen.

[0127] The above provides specific details about some aspects described above. Without departing from the spirit and scope of embodiments of the present technology, the specific details of specific aspects can be combined in any appropriate manner. For example, in some embodiments of the present technology, back-end processing, data analysis, data collection, and other transactions can all be combined. However, other embodiments of the present technology may relate to specific embodiments related to each individual aspect, or specific combinations of these individual aspects.

[0128] It should be understood that the present technology as described above can be implemented using computer software (stored in a tangible physical medium) in a modular or integrated manner in the form of control logic. Although the present invention has been described using a specific combination of hardware and software in the form of control logic and programming code and instructions, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. Based on the disclosure and teachings provided herein, those of ordinary skill in the art will know and understand other ways and / or methods of implementing the present technology using hardware and combinations of hardware and software.

[0129] Any software components or functions described in this application can be implemented as software code executed by a processor using any suitable computer language (e.g., Java, C++, or Perl), using, for example, conventional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium (e.g., a random access memory (RAM), a read-only memory (ROM), a magnetic medium (e.g., a hard drive or floppy disk), or an optical medium (e.g., a CD-ROM)). Any such computer-readable medium can reside on or within a single computing device, and can exist on or within different computing devices within a system or network.

[0130] The above description is illustrative and non-restrictive. After reading this disclosure, many variations of the technology will become apparent to those skilled in the art. Therefore, the scope of the technology should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

[0131] In some embodiments, any entity described herein may be embodied by a computer that performs any or all of the functions and steps disclosed.

[0132] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the present invention.

[0133] Unless specifically indicated to the contrary, the term "a," "an," or "the" is intended to mean "one or more."

[0134] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A method for encryption, the method comprising: determining, by a user device, first data comprising an electronic identifier associated with a user operating the user device; determining, by the user device, a private key associated with the user device and stored in a secure element of the user device, wherein the private key corresponds to a public key in a public-private key pair of the user device; The user device digitally signs the first data using the private key; determining, by the user device, a cryptogram using first data digitally signed by using a private key stored in the secure element of the user device, The password determination also includes: determining a session key based on an intermediate key and a counter value, the counter value being a value incremented by 1 each time the password is generated, wherein the intermediate key is generated using an identity key specific to the user device, and encrypting the first data using the session key; and The signed first data and the password are provided by the user device to a reader device, wherein the reader device upon verifying the password sends a request to include the signed first data in an electronic ledger. The method of claim 1 , wherein the intermediate key is a limited use key. The method of claim 1 , wherein the intermediate key is a static key.

4. The method of claim 1 , wherein providing the signed first data and the cryptogram to the reader device comprises: detecting, by the user device, proximity of the reader device; as well as The signed first data and the cryptogram are sent by the user device to the reader device over a short-range wireless connection.

5. A method for verification, the method comprising: receiving, by a reader device, signed first data and a cryptogram from a user device operated by a user, wherein the signed data is determined by digitally signing the first data including an electronic identifier associated with the user using a private key associated with the user device and stored in a secure element of the user device, wherein the private key corresponds to a public key of a public-private key pair of the user device; determining, by the reader device, whether the password can be verified; as well as sending, by the reader device, a request to include the signed first data in an electronic ledger to a remote server computer upon verification of the cryptogram, The password is determined in the following way: determining a session key based on the intermediate key and a counter value, the counter value being a value that increases by 1 each time the password is generated; and encrypting the first data using the session key, and The intermediate key is generated using an identity key specific to the user device.

6. The method according to claim 5, further comprising: After determining that the password can be verified, the reader device verifies the password immediately, the verification comprising: determining, by the reader device, the session key; decrypting, by the reader device, the cryptogram using the session key to determine a first value; decrypting, by the reader device, the signed first data to determine a second value; and A determination is made by the reader device that the first value matches the second value.

7. The method according to claim 6, further comprising: One or more dynamic values ​​used to generate the session key are received by the reader device from the user device.

8. The method of claim 5, wherein receiving the signed first data and the password from the user device comprises: detecting, by the reader device, the approach of the user device; as well as The signed first data and the cryptogram are received by the reader device from the user device over a short-range wireless connection.

9. A user device for encryption, the user device comprising: processor; as well as A computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor to perform a method comprising: determining first data including an electronic identifier associated with a user operating the user device; determining a private key associated with the user device and stored in a secure element of the user device, wherein the private key corresponds to a public key in a public-private key pair of the user device; Digitally signing the first data using the private key; Determining a password using first data digitally signed by using a private key stored in the secure element of the user device includes: determining a session key based on an intermediate key and a counter value, the counter value being a value incremented by 1 each time the password is generated, wherein the intermediate key is generated using an identity key specific to the user device, and encrypting the first data using the session key; as well as The signed first data and the cryptogram are provided to a reader device, wherein the reader device upon verification of the cryptogram sends a request to include the signed data in an electronic ledger.

10. The user device of claim 9, wherein the intermediate key is a limited use key. The user device of claim 9 , wherein the intermediate key is a static key.

12. The user device of claim 9, wherein the step of providing the signed first data and the password to the reader device comprises: detecting proximity of the reader device; as well as The signed first data and the cryptogram are sent to the reader device over a short range wireless connection.

13. A reader device for verification, the reader device comprising: processor; as well as A computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor to perform a method comprising: receiving signed first data and a cryptogram from a user device operated by a user, wherein the signed first data is determined by digitally signing first data including an electronic identifier associated with the user using a private key associated with the user device and stored in a secure element of the user device, wherein the private key corresponds to a public key of a public-private key pair of the user device; determining whether the password can be verified; and sending a request to a remote server computer to include the signed first data in an electronic ledger upon verification of the password, The password is determined in the following way: determining a session key based on the intermediate key and a counter value, the counter value being a value that increases by 1 each time the password is generated; and encrypting the first data using the session key, and The intermediate key is generated using an identity key specific to the user device.

14. The reader device of claim 13, wherein the method further comprises: After determining that the password can be verified, the password can be verified, and the verification includes: determining the session key; decrypting the password using the session key to determine a first value; decrypting the signed first data to determine a second value; and It is determined that the first value matches the second value.

15. The reader device of claim 14, wherein the method further comprises: One or more dynamic values ​​used to generate the session key are received from the user device.

16. The reader device of claim 13, wherein the step of receiving the signed first data and the cryptogram from the user device further comprises: detecting that the user device approaches; as well as The signed first data and the password are received from the user device over a short-range wireless connection.

Images