Systems and methods for biometric protocol standards

Abstract

Secure communications are provided between a user computing device and a server computing device. A registration request is received and processed from the user computing device configured via a distributed client software application. The registration request is usable to register the user computing device on a network and includes an encrypted partial initial biometric vector associated with the user. A subsequently received authentication request is processed, including an encrypted partial second biometric vector and associated with the user of the user computing device. A comparison is made between the encrypted partial initial biometric vector and the encrypted partial second biometric vector, and a value representative of the comparison is generated and transmitted to the user computing device. If the value is above a minimum threshold, the user computing device is authenticated.

Description

Technical Field

[0001] Cross - Reference to Related Applications This patent application is a continuation - in - part of U.S. Patent Application No. 15 / 800,748, filed on November 1, 2017, with the title "SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS", is based on it, claims its priority, and the said U.S. Patent Application No. 15 / 800,748 is based on and claims the priority of U.S. Patent Application No. 15 / 243,411, filed on August 22, 2016, which is currently Patent No. 9,838,388, and further claims the priority of U.S. Patent Application No. 62 / 208,328, filed on August 21, 2015, with the title "SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS", and also claims the priority of U.S. Patent Application No. 62 / 241,392, filed on October 14, 2015. This application is a continuation - in - part of U.S. Patent Application No. 16 / 378,044, filed on April 8, 2019, which claims the priority of U.S. Patent Application No. 15 / 592,542, filed on May 11, 2017, which is currently Patent No. 10,255,040. These are hereby incorporated by reference in their entireties as if fully set forth herein.

Background Art

[0002] The present invention generally relates to security, and more particularly, to systems and methods for identifying or authenticating users.

[0003] All kinds of information continue to be stored and accessed remotely, for example, on storage devices accessible via data communication networks. For instance, many people and businesses store and access financial information, health and medical information, goods and services information, purchase information, entertainment information, and multimedia information via the internet or other communication networks. In addition to accessing information, users may engage in monetary transfers (e.g., purchase, transfer, sale, etc.) using prohibited identities. In a typical scenario, a user registers to access information, then submits a username and password to "log in" and access that information. Ensuring access to (and from) such information and data stored on data / communication networks remains a major concern.

[0004] Furthermore, most user authentication methods and identity provision systems rely on centralized databases. These information storage systems present a security compromise: if they become compromised, users' digital identities are directly exposed to threats.

[0005] In other words, in this field of technology, there is a need for systems, methods, and computer-based approaches that overcome the inherent security vulnerabilities in such user identity systems. [Overview of the Initiative]

[0006] The systems, methods, and computer products described herein are directed toward user authentication, and there is no compromise regarding user identity. For example, a computer-implemented method is provided for registering an identity using an authentication system. The method includes receiving from a mobile computing device on a data communication network at least one encrypted cryptographic share of an initial biometric vector (IBV) and the public key of a first public / private key pair mathematically generated using a seed, wherein the at least one encrypted cryptographic share is encrypted using the private key of the first public / private key pair. The method also includes the step of generating a first identity data set including at least an authorization system signature, which is a digital signature, the public key of the first public / private key pair, and at least one encrypted cryptographic share, and storing the first identity data set in at least one remote storage location. In one or more further implementations, the method described includes the step of generating an identity reference value which is associated with a first set of identity data, resolves the storage location of the first set of identity data, and is cryptographically associated with the generated first set of identity data. As a further example, the method described also includes distributing a transaction record, which includes at least the identity reference value, among each of a plurality of ledgers stored in individual nodes, and providing at least the identity reference value to a mobile computing device.

[0007] In one or more further implementations of the present application, a system providing a user with access to a resource provider includes a memory-based processor configured by one or more modules to receive at least an identity reference value associated with a first identity data set from a mobile computing device on a data communication network, the identity reference value resolving the storage location of the first identity data set and being cryptographically associated with the first identity data set, the first identity data set including at least a specific data value of an authorization system, the public key of a mathematically generated registered public / private key pair using a seed, and at least one of a remote encrypted cryptographic share of an initial biometric vector of a user requesting access. The processor of the system is further configured to receive a signature value of an authorization system, the signature of which is a digital signature, and the public key of a registered public / private key pair. The system is configured to use the received data to locate a transaction record containing at least the identity reference value among a plurality of ledgers stored in individual nodes, and to determine the storage location of the corresponding first identity data set from the locably located transaction record. In certain implementations, the system also includes a processor configured to access a cryptographically associated first set of identity data and to verify the signature value of the authorization system against the registered public key of the first set of identity data. In further implementations, the system's processor is configured to receive current biometric vectors and local encrypted biometric ciphershares from a mobile computing device and to decrypt the received local encrypted ciphershares and remote encrypted ciphershares using the public key of a registered public / private key pair.Here, the processor of the described system can combine the decrypted local cryptographic share with the decrypted stored cryptographic share to form a combined cryptographic vector, and compare this combined cryptographic vector with the current biometric vector. If this combined cryptographic vector matches the current biometric vector, the processor of the described system can cause the resource provider to provide the user with access to the resource.

[0008] In one or more implementations of the present application, secure communication is provided between a user computing device and a server computing device. A registration request is received and processed from a user computing device configured with a distributed client software application. This registration request is usable to register a user computing device on the network and includes an encrypted partial initial biometric vector associated with the user. An authentication request, received thereafter and including an encrypted partial second biometric vector and associated with the user of the user computing device, is processed. A comparison is made between the encrypted partial initial biometric vector and the encrypted partial second biometric vector, a value representing the comparison is generated and sent to the user computing device. If this value exceeds a minimum threshold, the user computing device is authenticated.

[0009] In one or more implementations, secure communication is provided between the user computing device and the server computing device. Registration requests received from the user computing device, which is configured with a distributed client software application, are processed. The registration request includes a first portion of a first biometric vector that can be used to register the user computing device within the network and is associated with the user. The first portion of the first biometric vector is stored, and then an authentication request received thereafter, which includes a second biometric vector and a second portion of the first biometric vector, is processed. The first and second portions are combined and compared with the second biometric vector. A value representing this comparison is generated and sent to the user computing device. If this value exceeds a minimum threshold, the user computing device is authenticated.

[0010] In one or more implementations, a certificate is provided, which is included in the registration request and the authentication request, and processing the authentication request includes determining whether the certificate is current and has not expired.

[0011] In one or more implementations, an intrusion detection system is provided that provides active monitoring to prevent certificate spoofing, such as replaying a certificate.

[0012] In one or more implementations, processing an authentication request involves performing at least one matching operation in the encrypted space as a function of one-way encryption. One-way encryption can be performed using random one-way pads.

[0013] In one or more implementations, role collection is provided and defined by one or more rules for accessing digital assets, and the server computing device provides or denies access to the digital assets on the user computing device in accordance with said role collection. Access may be provided in accordance with at least one of optional access control and mandatory access control.

[0014] In one or more implementations, a server computing device processes a second registration request received from a user computing device configured with a distributed client software application. The second registration request is available for registering a second user of the user computing device within the network, and the second registration request includes a second encrypted partial initial biometric vector ("IBV") associated with the user of the user computing device. Processing the second registration request includes storing the second encrypted partial IBV on a non-primary, processor-readable medium that is accessible by or part of the server computing device.

[0015] In one or more implementations, the server computing device can disable user registration.

[0016] Other features and advantages of the present invention will become apparent from the following description of the invention with reference to the accompanying drawings. [Brief explanation of the drawing]

[0017] Further aspects of this disclosure will be more readily understood by considering the detailed descriptions of the various embodiments described below, in conjunction with the accompanying drawings:

[0018] [Figure 1] Figure 1 is a block diagram showing multiple devices and components according to one or more implementations of the present application.

[0019] [Figure 2] Figure 2 shows the apparatus and the flow of information therebetween, associated with an example BOPS implementation. [Figure 3] Figure 3 shows the apparatus and the flow of information therebetween, associated with an example BOPS implementation. [Figure 4] Figure 4 shows the apparatus and the flow of information therebetween, associated with an example BOPS implementation. [Figure 5] Figure 5 shows the apparatus and the flow of information therebetween, associated with an example BOPS implementation. [Figure 6] Figure 6 shows the apparatus and the flow of information therebetween, associated with an example BOPS implementation.

[0020] [Figure 7A] Figure 7A shows the apparatus and steps associated with an Enrollment process that adds a specific emphasis on data confidentiality according to one or more implementations.

[0021] [Figure 7B] Figure 7B shows an example management console provided in a user interface according to the present application.

[0022] [Figure 8] Figure 8 shows an overview including data access and exchange associated with the Enrollment process.

[0023] [Figure 9] Figure 9 shows the components of a security architecture according to one or more implementations of the present application.

[0024] [Figure 10A] Figures 10A and 10B show the apparatus and steps associated with two respective alternative Enrollment processes according to one or more implementations of the present application. [Figure 10B] The same as above.

[0025] [Figure 11] Figure 11 is a block diagram showing possible requirements and examples associated with various levels of Genesis processes according to the present application.

[0026] [Figure 12] Figure 12 shows an example flow of initial biometric vectors and associated information during the registration and authentication process.

[0027] [Figure 13] Figure 13 shows an example of visual cryptography (VC) implemented in connection with the present invention.

[0028] [Figure 14] Figure 14 shows an example of the superposition of two shares (2,2) in visual cryptography (VCS), where each bit is encrypted into a share, as is relevant to an example BOPS implementation.

[0029] [Figure 15] Figure 15 shows an example of a role hierarchy according to the present invention.

[0030] [Figure 16] Figure 16 is a block diagram showing the replay prevention and related devices and transmission flow according to an example implementation.

[0031] [Figure 17] Figure 17 is an advanced flow illustrating the token and related steps, following an example implementation.

[0032] [Figure 18] Figure 18 shows an example of a Genesis process and its associated equipment and features in a many-to-many relationship.

[0033] [Figure 19A] Figure 19A illustrates multiple users initiating an example registration process on a single client device. [Figure 19B] Figure 19B shows an example of a user initiating an authentication session from a client device that stores information about multiple user accounts.

[0034] [Figure 19C] Figure 19C shows an example of the steps involved in revoking a user account.

[0035] [Figure 20A] Figure 20A is a simplified diagram illustrating the steps involved in the initialization, verification, and confirmation of client certificates between the client device and the BOPS server.

[0036] [Figure 20B] Figure 20B shows an example of registering client certificates associated with a third-party server and BOPS server.

[0037] [Figure 21] Figure 21 shows an example QR code authentication flow according to an example implementation of the present invention.

[0038] [Figure 22] Figure 22 shows exemplary devices and features related to an authentication process using a distributed ledger and identity hub.

[0039] [Figure 23] Figure 23 is a block diagram illustrating the devices and connections between the user and the authentication provider in the registration and resource access process.

[0040] [Figure 24] Figure 24 is a flowchart illustrating an example of a user initiating an authentication session from a client device that stores information for authentication purposes.

[0041] [Figure 25]Figure 25 is a simplified diagram illustrating the user registration process with an identity provider and the associated steps.

[0042] [Figure 26] Figure 26 is a flowchart illustrating an example of a user gaining access to a resource using the authentication verification unit.

[0043] [Figure 27A] Figure 27A is a simplified diagram illustrating the steps involved in verifying user identity in the identity verification unit.

[0044] [Figure 27B] Figure 27B is a simplified variation of Figure 27A, illustrating the steps involved in verifying user identity in the identity verification unit.

[0045] [Figure 28] Figure 28 is an alternative, simplified diagram illustrating the steps involved in verifying user identity in the identity verification unit.

[0046] [Figure 29] Figure 29 is a flowchart illustrating one implementation and related steps for verifying user identity using the identity verification system described herein. [Modes for carrying out the invention]

[0047] As an overview and introduction, the systems, methods, processes, and computer products described herein are directed toward and utilize a distributed ledger (e.g., blockchain) for a distributed biometric credential storage device for the digital representation of identity. Currently, in the field of user identification technology, users are forced to relinquish personal information such as credit history, credentials such as birth certificates, or biometric data such as fingerprint templates to third parties through centralized databases. This is a novel decentralized ecosystem for private and secure identity management being implemented by several projects as an alternative to conventional identity verification systems. To overcome this problem inherent in the use of identification information across various networks (e.g., the internet), this specification describes various approaches that enable end users to establish control over their user identity data when establishing or participating in exchanges over networks, rather than in a conventional centralized configuration.

[0048] One or more implementations of this patent application provide a novel set of standards, collectively referred to herein as Biometric Open Protocol Standards ("BOPS"), which, when combined with a user-controlled authentication system, enables a framework for authenticating users, wherein the user's identity information is protected by the user rather than by centralized authority. One or more BOPS implementations may provide one or more modules for identity assertion, role collection, multi-level access control, assurance, and auditing.

[0049] Figure 1 shows an example hardware configuration 100, illustrating one or more BOPS implementations and associated data communications. Configuration 100 may include one or more software applications that support and enable the functionalities shown and described herein, comprising multiple computing devices such as a client device (e.g., a smartphone or mobile device) 104, a server computing device (generally referred to herein as the “BOPS server”) 102, a third-party server 106, and an intrusion detection system (“IDS”) which may include multiple computing devices 112. The BOPS server 102 may also be in communication with or connected to a health monitoring device 108 and an analysis engine device 110. Both devices 108 and 110 may be configured as part of the BOPS server 102 or may be independent devices.

[0050] The following is a non-restrictive list of abbreviations and acronyms used herein: admin = administrator; AOP = aspect-oriented programming; API = application programming interface; AWS = Amazon Web Services; app a = client application; BOPS = biometric open protocol standard; CPU = central processing unit; CBV = current biometric identifier; CSRF = cross-site request forgery; HSM = hardware security module, ID = identifier; IDS = intrusion detection system; IBV = initial biometric vector; IP = Internet protocol; JSON = JavaScript object notation; LDAP = lightweight directory access protocol; MAC = mandatory access control; MCA = mobile client application; NSA = National Security Agency Agency (US); QR code = High-speed reading code; RDBMS = Relational Database Management System; REST = Representative State Transfer; SSL = Secure Sockets Layer; TCSEC = Trust Computer System Evaluation Criteria; TEE = Trust Execution Environment; TPM = Trust Platform Module; TLS = Transport Layer Security; URL = Uniform Resource Identifier; XNTP = Extended Network Time Protocol; XOR = Exclusive OR binary operation; 1:M = One to many; 4F = Four Fingers, proprietary biometric technology; 5-tuple = Five-tuple data parameter.

[0051] The advantage of this invention is that one or more individual BOPS implementations may include functional components that can work with or replace existing components within a company, thereby enabling integration with the current operating environment in a relatively short time interval. Furthermore, one or more individual BOPS implementations may provide a continuous form of protection, such as determining access to confidential and non-public resources. In a BOPS implementation, it is possible to provide a service level of security that meets or exceeds acceptable purposes, at least in part, as a function of one or more application programming interfaces (APIs) that support implementation in the form of a "point-and-cut" mechanism, adding appropriate security not only to production systems but also to development systems.

[0052] One or more BOPS implementations may include a BOPS server 102 that can receive a biometric vector, generally referred to herein as an initial biometric vector ("IBV"), from a client device 104a via one or more data communication networks, and the vector is divided into multiple parts associated with identification information according to an algorithm. Regardless of the number of parts, the IBV can be encrypted, for example, in a keyless manner, and a subsequent biometric matching process may be performed on the client device 104 or server 102, as optional, for example, indicated by a control parameter.

[0053] One or more BOPS implementations can be carried out in various online environments, such as on a public cloud (e.g., Amazon Web Services) or in a private cloud.

[0054] According to the organizational structure and functionality of the devices shown and described herein, user authentication may be provided in a manner that, instead of authorization, maintains a sufficient amount of information so that one client can be recognized from another client, rather than the server holding client information. Security considerations for one or more BOPS implementations may include identity assertion, role collection, access control, auditing, and assurance. In other words, in one or more BOPS implementations, the server-side components are primarily considered in the end-to-end biometric solution.

[0055] With regard to identity assertion, one or more BOPS implementations provide continuous protection of resources and ensure the establishment and feasibility of determination and other important features. One or more BOPS implementations can further assist in identity assertion to help verify that a designated user is the person they claim to be, without relying directly on the person's biometrics. The standards shown and described herein include interoperable standards that can virtually incorporate any identity asserter or several different asserters associated with the same designated user. The application of IDS (e.g., via client device 112) can provide active monitoring that helps prevent the spoofing of a set of credentials and / or blacklists subjects or devices that have been determined to have made or are attempting to make one or more malicious attempts.

[0056] Furthermore, role collection is supported as a data confidentiality and privileged access function based on rules defined and / or enhanced by, for example, a known system. For example, it is possible to compare specific privileges associated with individual roles with group classifications in order to determine whether a particular mode of access is permitted. The structure of objects may be defined by access control, and role collection may be performed at the system level or via client / server calls. For example, a BOPS server 102 may store role collection information to associate a unique user with a unique device 104. Access control includes implementing one or more modules that run on a computing device to determine whether a given subject (e.g., a person, device, or service (e.g., a software program)) is authorized to access a given object and / or perform actions on the given object such as reading, writing, executing, or deleting.

[0057] Generally, access control can be arbitrary, and may also include or alternatively include mandatory access control, which may be of a finer granularity. Arbitrary access control relates to controlling access to one or more objects, for example, depending on a specified user and a specified object (e.g., files and programs). The determination mechanism can be, for example, role-based, and may allow users and administrators to identify and control which objects are shared by specified individuals and / or defined groups of individuals. In one or more implementations, the mechanism of arbitrary access control provides protection for objects from unauthorized access at the group or individual level across a single object or group of objects. That is, the granularity associated with arbitrary access can range from individuals to groups.

[0058] One or more BOPS implementations can, under the control of their individual implementations, strengthen enforcement access control policies for all subject and storage objects (e.g., processes, files, segments, devices). These subjects and objects can be assigned confidentiality labels, which can be a combination of hierarchical classification levels and non-hierarchical classification categories. These labels can be used as criteria for determining whether to enforce access control. For example, software running on client device 104 may compel the device to maintain labels or store data on BOPS server 102 in order to enforce compliance with subject and object labeling. BOPS server 102 can maintain a trust store as a component of the BOPS implementation. As used herein, a trust store generally refers to a secure method of storing data such that access control (DAC or MAC) ensures that a subject receives the correct object and further guarantees non-repudiation and confidentiality.

[0059] The following identifies access control rules and options supported in BOPS implementations as one or more examples. A subject may be granted access to read an object only if its hierarchical classification at security level is equal to or greater than the hierarchical classification at security level of an object. One or more non-hierarchical categories at security level of a subject may include all non-hierarchical categories at security level of an object. A subject may write to and / or execute an object only if its hierarchical classification at security level is less than or equal to the hierarchical classification at security level of an object, and all non-hierarchical categories at security level of the subject are included in the non-hierarchical categories at security level of the object. Identification and authentication data is available to the BOPS server device 102 to authenticate a user's identity and to ensure that the security level and authorization of subjects outside the BOPS implementation that may be created to act on behalf of that individual user are governed by the user's security clearance and authorization.

[0060] This application operates to increase accountability, for example, by providing the functionality of one or more modules that audit and verify that a security model is operable, which is generally referred to herein as assurance. In unlikely events, such as the compromise of computing devices within the scope of a BOPS implementation, such modules prevent undetected computation of the compromised system. For example, in a BOPS implementation, auditing requests can be supported at the subject / object level or group level, for example, as a feature of aspect-oriented programming, as is known in the art. This increases the likelihood that calls are securely written to an audit trail. Furthermore, RESTful web services and JavaScript object notation (JSON) interfaces may provide mechanisms for reading audit trails. Auditing may be performed at the subject level for each action, at the object level for each action, or at the group level for each action. For example, a group of users can be designated by a specific name (e.g., "Accounting"), and all writes to the general ledger can be audited. Furthermore, it is possible to provide audit information to individuals, such as the head of finance, for the purpose of reading income statements.

[0061] In one or more BOPS implementations, boundary conditions can be tested and monitored using one or more of a set of JUnit tests, which may include testing boundary components and boundary conditions within the system. In one or more BOPS implementations, security requirements can be satisfied at least partially as part of the API functionality. The use of the API eliminates the need to identify and / or customize the BOPS implementation to conform to an underlying system such as a relational database management system, a search engine, or other virtual architecture. The functionality provided by individual BOPS implementations provides a "point-and-cut" mechanism, making it possible to add appropriate security to systems under development as well as systems under production. Furthermore, the architecture of one or more BOPS implementations is language-neutral, providing communication interfaces that support, for example, REST, JSON, and SSL. In one or more implementations, the architecture is built on servlet specifications, OpenSSL, Java, JSON, REST, and persistent stores. The tools can adhere to open standards, which enables maximum interoperability with devices, as shown, for example, in Figure 1.

[0062] In one or more BOPS implementations, identity assertion, role collection, multi-level access control, auditing, and assurance are provided. These may be implemented as functions of a combination of at least one specially configured client device 104 (e.g., a smartphone or mobile device), a BOPS server 102, and a device 112 equipped with an intrusion detection system (IDS). In one or more implementations, the client device 104 runs an application and loads a two-way secure socket layer ("SSL") / transport layer security ("TLS") one-time key to establish a secure initial communication session with the BOPS server 102. This one-time key is at least functionally replaced by a subject two-way SSL / TLS key generated and / or provided during the identity stage (generally referred to herein as "Genesis"). Genesis generally involves the first or early step in the process of fusing a set of biometrics with a given subject. Another stage, which is generally referred to herein as Enrollment, includes steps associated with registering users and / or devices in the BOPS implementation, and may also include issuing certificates to client devices 104, protecting client certificates, and protecting sensitive data stored on said client.

[0063] In one or more BOPS implementations, a foundation is provided for handling data encryption and secure client / server communication. This BOPS foundation can help decouple the Genesis and Enrollment processes and coordinate them with various Enrollment elements. These dependencies may identify the BOPS server 102 foundation and may include BOPS DNS; BOPS TrustStore; BOPS KeyStore; and BOPS Key negotiation protocol. Regarding certificate management, the DNS entry for the hostname of the BOPS server 102 may be configured to have a key in the keystore for one-way SSL. In one or more BOPS configurations, the TrustStore is a two-way SSL mechanism that defines the certification authority for signing all corresponding certificates. At the transport level, BOPS identity may be generated via two-way certificates and the truststore by performing a handshake. The key store assists with transport-level security through the keys within the key store, and the keys within the key store can be used to identify hosts for encryption over SSL / TLS, such as a clearly defined and recognized certification authority, e.g., Verisign, Godaddy, or other authority. As described herein, one or more BOPS implementations request a password to unlock the two-way SSL certificate from the client device 104 using a one-time password (OTP) process. This can be configured so that the client device 104 and server 102, having synchronized the OTPs, return the key to unlock the certificate after the two-way SSL session has started.

[0064] In one or more implementations, when a request is sent from the client device 104 to the BOPS server 102, several key enrollment elements assist in the authentication of the client certificate. For example, a token may be configured as an identifier that associates a profile on the server with an identity, such as the function of a data element, which is, for example, "Common Name". The OTP process includes one or more mechanisms for requesting a password from the server to unlock a two-way SSL (x.509) certificate. This password may be changed with each use by a predefined algorithm coordinated between the server computing device 102 and the client computing device 104, and the channel used for OTP is preferably different from the channel used for the personal certificate. For example, the password used to unlock the personal certificate may be sent by push notification. The password to unlock the personal certificate can be obtained using a different certificate. In any event, the mechanism for unlocking this certificate does not have to be involved in storing its password on the client device 104.

[0065] In one example, the application uses a default certificate (e.g., a pre-installed one) for Genesis and Enrollment. Subsequent processing can use this default certificate, including the current OTP. The result (e.g., an HTTP response) may include a password to unlock the certificate. The OTP is then rolled forward on the client and server. In one or more BOPS implementations, a 5-tuple is a high-entropy value used to prevent replay attacks. These values ​​occur during Enrollment and can become part of future communication between client device 104 and server 102.

[0066] The interaction between client and server applications in a BOPS implementation can be considered a three-stage process, with at least two possible variations following the first step. In such cases, the BOPS client / server application architecture is described herein with reference to the following three components: the client application running on the client device 104, the application running on the BOPS server 102, and the server-side application (referred to as the "application server" in the diagrams). In the examples shown in Figures 2-6, the server-side application does not necessarily pass through the BOPS server 102, so the SSL / TLS connection can terminate at the application server. Furthermore, the deployment of individual BOPS implementations does not require the application to trust the BOPS system with unencrypted content. Referring to Figure 2, during the Genesis process, the client device 104 makes a call to the BOPS server 102 to authenticate the user and the client-side application software. Subsequently, the client device 104 receives a certificate assigned by the BOPS server 102 that is specific to the client identity of the particular application.

[0067] During the next step (Figure 3), the client device / application directly calls the application server. An SSL / TLS connection between the client and the application server is initiated and terminated at these points. The content exchange is preferably not visible outside of this application to the BOPS server 102 or other untrusted parts within this application entity. During the client session (Figure 4), the application server 106 calls the BOPS server 102 to obtain identity details and verify that the certificate has not expired previously.

[0068] In the second modification (partially shown in Figure 5), the Genesis step (as described in Figures 2-3) can be the same. Subsequently, the BOPS server 102 communicates with the components of the application server 106 to notify them that a new client 104 has been registered and assigned. The flow of this second modification differs from the flow of the first modification in at least two ways: the identity details are different, and the revocation confirmation is obtained during the client session (Figure 6). In the third step, when the client device 104 directly calls the application server 106, the application server 106 calls the BOPS server 102 to confirm that the certificate has not been revoked previously.

[0069] The features shown and described herein with respect to example BOPS implementations may be used by or in conjunction with the access control modules provided herein, or may be added to identity assertion elements of existing frameworks. In other words, BOPS implementations enable trusted processing by performing minimal operations in the manufacturing environment, thereby often eliminating the need to modify application software.

[0070] Figure 7A shows an example of an Enrollment process and associated data confidentiality and related devices and steps 700, following one or more BOPS implementations. Two-way SSL / TLS, built in this application on top of one-way SSL / TLS, provides communication initiated at client device 104. The initial (e.g., Genesis) communication establishes the identity of client 104 and, along with a session-oriented identity assertion, may pass a BOPS-compliant two-way certificate that client device 104 can use for subsequent communications. In one or more implementations, the client application may have a pre-loaded two-way SSL / TLS key that permits subsequent Genesis operations.

[0071] In one or more implementations, the BOPS server 102 receives one-way SSL / TLS communication with two-way SSL / TLS identity from the client device 104. Communication is conducted via both one-way and two-way SSL / TLS. In one or more implementations, the server 102 uses a data store to retrieve trust identity information and collects roles related to processing on behalf of individual identities. Furthermore, auditing maximizes appropriate artifacts for continuous verification and validation of trust access. Assurance may arise as a function of simplifying and documenting multi-level access control mechanisms. In one or more BOPS implementations, the completion of the subsequent registration process is provided in the administration console (hereinafter, "admin console") within the graphical user interface, which allows for dynamic modification of users, groups, and roles, and is described in more detail herein. An example of the admin console is shown in Figure 7B.

[0072] Referring to Figure 7A, a token request (RESTful) is sent from client device 104 (1) and received and verified by BOPS server 102 (2). The DNS entry for the hostname of BOPS server 102 may be configured to have a key in its keystore (3), and the request is formalized (4A), and an m-token response is sent to client device 104 via two-way SSL / TLS (4B). Subsequently, a c-token (e.g., a 5-tuple and a timestamp) is sent from client device 104 (5), which is verified, for example, as a function of the m-timestamp in the request (6, 7). Then, the missing 5-tuple is determined by comparing it with the truststore (8), and the request is formalized (9), and an SHA512 token is sent to client device 104 (10).

[0073] Continuing to refer to Figure 7A, the client device 104 sends a registration request including a SHA512 token (11), which is received and verified by the BOPS server 102 (12), and the client signature request is processed and the certificate is unlocked (13), which may involve calculating a one-time password and comparing it with the key store to verify the token count (14) and sending the client certificate password to an external notification service (15). Furthermore, the verification step 12 branches off into steps related to analysis, which include determining device information (16), profile information (17), and biometrics (as shown and described herein) (18).

[0074] Furthermore, the certificate password of the client device is sent back to the client device 104 (19), and the formalized request (2) and SHA512 token (21) are also sent back in the same manner. Subsequently, a custom security request, such as a SHA512 token, is sent from the client device 104 (22), which is verified by the BOPS server 102 (23). The request is formalized (24), and the custom security response (such as a SHA512 token) is sent back to the client device 104 (25).

[0075] In one or more BOPS implementations, an active intrusion detection system is provided, for example, via device 112. The active intrusion detection system is effective in preventing brute-force attacks, denial-of-service (e.g., distributed or single-target denial-of-service) attacks, or other attacks. Custom rules can be defined and enforced to identify and track attempts to forge two-way SSL / TLS certificates, session replays, forged packets, or various disabling techniques in efforts to compromise the BOPS server device 102.

[0076] In one or more BOPS implementations, the initial biometric vector (IBV) is encrypted using visual cryptography. This technique provides the advantage of rapid IBV reconstruction by using XOR operations, etc., in the specific device performing the biometric matching. For example, the technique developed by Moni Naor and Adi Shamir, which provides a secret sharing scheme, can be used. In an example operation, a vector is divided into N shares, so all parts of the N shares are needed to reconstruct the initial vector. Each device includes a BOPS server 102 and a mobile client application 104, and the registered vector may be divided into two parts of shares, one of which is stored in a BOPS repository accessible by the BOPS server 102, and the other is stored on the mobile computing device 104.

[0077] In one or more implementations of the present invention, other forms of encryption schemes and / or mechanisms that ensure data confidentiality may be employed. For example, elliptic curve cryptography may be used instead of (or possibly in addition to) visual cryptography.

[0078] During the operation of biometric authentication, for example, both the newly acquired vector and the registered vector share may be available in one location (e.g., mobile computing device application 104 or BOPS server 102) or in multiple locations. In any case, the registered vector share can be used to reconstruct the initial vector in memory, thereby supporting authentication that occurs against that vector. Figure 8 shows an overview of the Enrollment process, including data access and exchange. With respect to BOPS server 102, identification is provided as a subject account and device function. The subject account and device are part of the profile information for a given subject. The profile information is stored in a clustered data store. For matching, the IBV is taken into the share, reconstructed, and decrypted. If the matching algorithm is not capable of Euclidean matching, the matching is performed in plaintext; otherwise, the matching is performed within the cryptographic domain.

[0079] Alternative implementations utilize homomorphic encryption, which allows computations to be performed on the ciphertext to generate the encrypted result. Matching operations are possible within the encrypted space, thereby increasing privacy and security. For example, matching can be performed within the encrypted space using one-way encryption, providing a high level of privacy and effectively eliminating the ability to obtain the IBV of the original plaintext.

[0080] In one or more implementations, one-way encryption is performed by an algorithm in a manner having two parts, one for the client and the other for the server. If the matching uses the Euclidean distance (e.g., the Hamming distance), as is known in the art, the matching process is performed in the cryptographic space. Alternatively, if the matching does not use the Hamming distance, the matching process is performed in the plaintext space, as described herein.

[0081] In one or more implementations, a random one-time pad (ROTP) is used to perform one-way encryption that enables matching in the encrypted space. Alternatively, in the case of matching in plaintext, visual cryptography is used for reversible encryption. For example, if there is no Hamming distance, visual cryptography is used to return to plaintext for matching performed in memory. Preferably, one of the following two encryption algorithms is used for encryption and decryption: 1. Bitmask, or 2. Matrix transformation. Since all matching algorithms will have a Hamming distance, it is ideal that the server does not have the IBV of the plaintext.

[0082] The following is an example of an iris recognition algorithm implemented as a function to calculate the Hamming distance between two binary vectors. In this example algorithm, the matching process can be performed directly on each encrypted half of the biometrics without converting each encrypted half to plaintext, as follows (^ indicates a bitwise XOR operation):

[0083] The server stores the following: Enrol vector^noise

[0084] The phone sent the following: Verify vector^the same noise

[0085] The following comparison is performed on the server: (Enrol vector^noise)^(Verify vector^the same noise)

[0086] Since XOR is commutative and associative, it can be reorganized as follows: (Enrol vector^Verify vector)^(noise^the same noise)

[0087] Since XOR is an inverse of itself, (noise^the same noise) = I, where I is the identity element for XOR, and it is 0.

[0088] Therefore, the equation can be simplified as follows: (Enrol vector^Verify vector)^I = (Enrol vector^Verify vector)).

[0089] The Hamming distance between A and B is the function A^B.

[0090] Therefore, the Hamming distance between noise-generated vectors is the same as the Hamming distance between the original vectors.

[0091] In the example implementation, the following occurs during enrollment:

[0092] a) Registered vector:

[0093] 00110011

[0094] b) Random sequence (first half of the vector): Stored on the server

[0095] 01010101

[0096] c) Second half of the vector (calculated): Stored on the phone

[0097] 01100110

[0098] The following occurred during verification:

[0099] e) Verification vector: (Notify only the last bit that changed between registration and verification. This indicates a good match.)

[0100] 00110010

[0101] Second half of the vector: Stored on the phone

[0102] 01100110

[0103] f) Calculate an approximate value for the first half of the vector (from e to c):

[0104] 01010100

[0105] The following occurs during the matching process:

[0106] g) Send this "first half verification" (f) to the server

[0107] h) Currently, the server has the following:

[0108] First half of the registered vector (b):

[0109] 01010101

[0110] The first half of the validation vector (f):

[0111] 01010100

[0112] Mark all bits that changed between b and f as 1:

[0113] 00000001

[0114] The system can only communicate the last bit that changed between registration and verification, which indicates a good match, but it can tell us how the server handled only encrypted data, that the actual vectors are unknown to the server, and that only the differences between vectors can be calculated.

[0115] In alternative implementations, face recognition is performed by calculating the Euclidean distance between template vectors, but these faces cannot be reverse-engineered from these vectors. For example, when matching two face images using a neural network, each face is first converted into a real-valued vector (float vector) of size 128 bytes. The representation of this real-valued vector is arbitrary, but it cannot be reverse-engineered back to the original face. To compare faces, the Euclidean distance between the two vectors is calculated. Two faces from the same person should have similar vectors, while faces from different people should be further apart in Euclidean space. It is possible to calculate a verification vector on a mobile device, send it to a remote server, and compare it with the stored registration vector. Therefore, the original biometric data (e.g., face) never leaves the user's device, and all matching processes can be computed on the server.

[0116] In yet another implementation, fingerprint recognition is performed by calculating the Euclidean distance between template vectors, but the fingerprint cannot be reverse-engineered from these vectors. Similarly, as described above, it is possible to apply a neural network to the fingerprint matching process. In this case, the fingerprint can be converted into a vector on the device and transmitted, thereby eliminating the possibility of reconstructing the original fingerprint image from the vector output by the network.

[0117] In one or more implementations, an encryption key is randomly generated on the device, which is used to obfuscate the output vector from the neural network. For example, encrypted biometric vector = encryption matrix × plaintext biometric vector. In this case, the encryption matrix transformation has the special property that the Euclidean distance is preserved, i.e., the matrix must be a rigid body transformation. In this case, the biometric vector is not output from the device in an unencrypted form, and the server compares the two encrypted biometrics to calculate the Euclidean distance without knowing the plaintext. If a user wishes to perform verification from a new device, the user can send encrypted data to the new device, for example, via a QR code. This requires that the previous device is available. If the previous device is lost or otherwise unavailable, the user re-registers as shown and described herein.

[0118] Therefore, enhanced privacy is achieved by the function of dividing, storing, encrypting, and traversing biometric vectors between devices. No portion of the biometric vector exists on the server in plaintext form, either on disk or in memory. Furthermore, the present invention enhances analysis by allowing users who wish to perform "what-if" analysis on individual authentications and failed authentications to do so through a management interface that supports faceting, searching, and analysis.

[0119] Figure 9 shows the components of an example security architecture 900 that follows one or more BOPS implementations. As shown in Figure 9, the BOPS security cluster 902 can be configured to run BOPS instances over a virtual private network (VPN). Core attributes of the authentication authority entity, BOPS key store, and BOPS trust store can be located on the BOPS instances, for example. The BOPS instances may also contain DNS, OTP libraries, notification service keys, business adapters, BOPS configuration properties, and related and / or representing data. The load balancer cluster 904 may include one or more devices to ensure the reliability and availability of BOPS services and the distribution of workload. The configured BOPS load balancer 904 may operate to maximize throughput, minimize response time, and avoid overloading any single resource in the BOPS architecture 900.

[0120] Continuing to refer to Figure 9, the persistent cluster 906 can contain one or more database security groups and can be configured to automatically scale the BOPS data cluster. The authentication service can handle large data objects and, when dealing with large data sets, can improve performance by employing one or more horizontal partitions ("shards") of the data, such as NoSQL big data stores, and reading from the shards simultaneously and merging the results. The database security architecture 900 implements a BOPS architecture to prevent centralized storage of sensitive data in a single location. Figure 9 also shows a monitoring cluster 908 which can contain an IDS device 112.

[0121] Figures 10A and 10B show the devices and steps for individual alternative Enrollment processes 1000 and 1010, respectively, following one or more BOPS implementations. The implementations shown in Figures 10A and 10B provide a mechanism for storing encrypted biometric data associated with an account or device, storing information about changes to all biometric data, loading and using authentication services and their corresponding biometric libraries (e.g., FACE, 4F, IRIS), and providing API operations to support new flows (e.g., enrollment and authentication).

[0122] In the implementation shown in Figure 10A, when the authentication flow method is configured to be performed on the client 104 side, a software application ("MCA") running on the mobile computing device 104 provides the acquisition of an initial biometric vector (IBV), the execution of cryptographic partitioning operations during the Enrollment process and the distribution of this process to reduce the CPU load on the server side, the execution of an Enrollment request (registration) by the BOPS server 102, and the execution of cryptographic matching operations. The BOPS server 102 can be configured to store the user's identity data together with the share vector, for example, in the BOPS big data store 1002 during the Enrollment process. Furthermore, the BOPS server 102 can manage the authentication flow and integrate the authentication service communication components (1004). The authentication service (1006) can dynamically load one or more authentication algorithms and biometric engine libraries, assist in authentication engine versioning, thereby normalizing communication between the BOPS server 102 and one or more biometric engines, providing support for authentication engine versioning, and normalizing communication between the BOPS server 102 and the authentication engines. The authentication service acts as a wrapper for the biometric service when performing authentication.

[0123] As described herein, one or more mechanisms relating to pluggable authentication services and their corresponding biometric engines are provided. Thus, BOPS implementations are configurable (e.g., via the location of authentication services and biometric libraries) and can automatically load and register available services with the system.

[0124] As a result, the following enunciation services are available at the system level: 4F-engine, FACE-engine, IRIS-engine, and VOICE-engine. Examples of authentication components include FIDO authentication and BOPS authentication.

[0125] This application enhances biometric integrated authentication services by supporting the following features: It is possible to provide one or more mechanisms for storing encrypted biometric data within an account or device accessible by the BOPS server 102. It is also possible to provide a mechanism for storing information representing changes in biometric data that have occurred. Furthermore, it is possible to provide a “generic” mechanism for accessing and using authentication services, including those shown and described in U.S. Patent Application No. 14 / 201,462, U.S. Patent Application No. 14 / 201,499, U.S. Patent Application No. 14 / 988,833, and U.S. Patent Application No. 14 / 819,639 by the same applicant, which relate to, for example, facial, four-finger, and iris biometric authentication.

[0126] In one or more implementations of the present invention, the mobile computing device 104 acquires an Enrollment vector and performs an encrypted partitioning operation during the Enrollment process. This improves the computational functionality by distributing the process and reducing the CPU load on the server side. Furthermore, if the "biometric validity verification" step from the authentication flow is configured to be performed on the mobile device, the mobile device 104 can perform an Enrollment request (registration) to the BOPS server 102 and perform an encrypted verification operation.

[0127] In one or more implementations of the present invention, the BOPS server 102 stores user identity information, along with at least a portion of the share vector, in, for example, an APACHE SOLR repository during the Enrollment process. Furthermore, the BOPS server 102 can be configured to manage authentication information, process flows, and integrate at least one biometric service communication component.

[0128] Other components provided in the architecture according to the present invention may include one or more authentication services and one or more biometric engines. The authentication services can be configured to dynamically load one or more libraries configured to assist in versioning of one or more authentication services, to normalize communication between the BOPS server 102 and the authentication services, and to provide one or more deployment scenarios, for example, one or more BOPS instances, which are web application machines, etc., that are either off or in another cloud, and are capable of scaling by themselves.

[0129] In one or more implementations, the biometric engine is configured to include an unmanaged biometric library, which is the subject of the interface and is defined and implemented by each individual library that intends to plug into the BOPS implementation system. The biometric engine preferably provides a “Load” method to load the engine if necessary, an “UnloadLoad” method to unload the engine and release resources (e.g., memory, primary files), a “GetStatus” method to provide status information (e.g., INIT_FAILED, OK, ERROR, OUT_OF_MEMORY), a “Split” method to encrypt vectors obtained during enrollment, a “Match” method to authenticate vectors based on, for example, the share portion of the initial vector, an “Activate / Register” method, and a description of the engine. The description may include, for example, a Biometric Type Identifier, Name and Description, Engine Version, and Biometric Format. Using this information, one or more processes related to the present application can automatically load and register a particular biometric engine.

[0130] In one or more implementations, a mechanism for a pluggable authentication service is supported, which allows the system to be configurable (location of the authentication service) and automatically loads and registers libraries available to the system. Each biometric library, which is invoked by the authentication service, can provide information that describes itself, such as a constant sequence (biometric type), individual versions, names, and descriptions. Furthermore, information such as such pairs (biometric type, biometric version) can identify a unique biometric engine.

[0131] Examples of authentication services and their corresponding lower-level biometric engines may be listed and available at the system level, such as 4F, FACE, IRIS, and VOICE, and are shown and described, for example, in U.S. Patent Application Nos. 14 / 201,462, 14 / 201,499, 14 / 988,833, and 14 / 819,639 by the same applicant.

[0132] As described herein, in one or more BOPS implementations, the Genesis process and the Enrollment process are effectively separated, thereby enabling the determination of the subject's identity without a direct requirement for the BOPS server 102 to access biometric vectors, certificates, or other sensitive information otherwise required for automated processing. Thus, the BOPS solution can be interpreted as "open," and virtually any customization may be possible in Genesis and Enrollment. For example, Genesis may include the use of a username and password to access Active Directory, an email or text message for validation, or organizational personnel to physically verify identity. For example, pre-registration of user accounts, which may occur in batches, can be based on business requirements. Furthermore, the Genesis process can form a complete dependency on risk management to determine further downstream processing. For example, during a post-Genesis process, the user registers their biometrics, which may include a unique client certificate issued for each registered device. Furthermore, it is possible to establish a one-time password (e.g., a "seed") between the client device 104 and the server device 102, and additional seed values ​​can be used to prevent replay attacks.

[0133] This specification recognizes that one user may have multiple devices, and / or one device may have multiple users (i.e., one device may have multiple biometrics). Therefore, a many-to-many relationship can occur as a function to separate the Genesis and Enrollment processes. Thus, a subject identified via Genesis can be registered multiple times using multiple biometrics. In one or more BOPS implementations, the Enrollment process uses a two-way secure socket layer / transport layer security (SSL / TLS) certificate, which may be generated by the server. This generation may occur after the Genesis process, thereby ensuring that the certificate is appropriate for the clearly defined subject.

[0134] Furthermore, one or more BOPS implementations can have various levels of provisioning, which provides flexibility regarding different security levels. For example, a high level of Genesis might include users being physically validated in the presence of a certain person, such as an employee. Alternatively, a low level could simply involve defining a username and password along with a validation email that the user receives. The various levels of Genesis and validation processes can be carried out according to one or more business decisions that may be unique or specific to one or more individual configurations. Subsequent processing may also vary based on the individual Genesis level. For example, in one system, a $1,000,000 transfer might be possible with a high level of Genesis, while a $100 transfer might only be possible with a low level of Genesis.

[0135] Figure 11 is a block diagram showing possible requirements and examples associated with various levels of Genesis according to the present application. If further requirements are needed in the verification process, individual security levels can be developed accordingly. In the example levels in Figure 11, the first and second levels can be swapped based on organizational considerations. For example, if the purpose is to verify business visitors and grant them Wi-Fi access, such verification can be transmitted via a mobile device and is considered a low level of verification in this specification.

[0136] During the enrollment phase, for example, a mobile application running on the mobile computing device 104 registers biometrics based on its individual embedded performance. For example, a mobile application embedded for a particular integration and possessing the necessary default biometrics may have a module specifically hardcoded for that purpose within the application.

[0137] One or more BOPS implementations address the speed of biometric authentication transactions and the virtualized threat problem on mobile devices. An example of such a threat is an intruder attempting to decompile code on a copied virtual image of a mobile device and use this source code to halt authentication calls and gain control of the server that authenticates and establishes authorization.

[0138] To mitigate these risks, the BOPS implementation process encrypts the initial biometric value (IBV) without an encryption key, then stores half of the IBV on the client device 104 and the other half on the server 102, or otherwise makes it accessible by the server 102. Biometric matching can be performed on the server 102. Figure 12 shows an example 1200 of the flow of the initial biometric vector ("IBV") and related information during the Enrollment and Authentication processes. In the example flow shown in Figure 12, during Enrollment, the IBV is captured and split, and a portion of the IBV (e.g., half) is stored on the client device 104. The portion of the IBV (e.g., half or 1 / 2) is sent to the BOPS server 102 in the Enrollment request, and this portion is stored, for example, in a data store accessible by the BOPS server 102. Thus, the Enrollment confirmation is sent by the BOPS server 102.

[0139] Continuing to refer to Figure 12, during the subsequent biometric authentication process, the current biometric vector ("CBV") is captured and, along with the remaining portion (2 / 2), is sent to the BOPS server 102 along with the authentication ("Auth") request. The BOPS server 102 is configured to combine the received portion of the IBV in the authentication request and decrypt it by combining it with the stored portion of the IBV. The received CBV is compared with the plaintext of the entire IBV, and depending on the decision made during the comparison, a number (e.g., a floating-point number) is returned to the client computing device 104. If a match exists, the user may be registered as authenticated. Furthermore, the result can be made part of the authentication process and can be displayed on the client computing device 104.

[0140] In other words, as shown in the steps in Figure 12 and as described herein, the BOPS implementation according to this application addresses the speed of biometric authentication transactions and solves problems associated with virtualized threats on client devices. Such threats may occur, for example, after an intruder attempts to decompile software on a copied virtual image of a mobile device, for example, and use this source code to halt authentication calls and gain control of the server that authenticates and establishes authorization.

[0141] To mitigate these risks, features associated with the BOPS implementation allow for the encryption of the IBV without an encryption key, storing a portion (e.g., half) of the IBV on the client device and another portion (e.g., the remaining half) on the server or a device accessible by the server. Biometric matching can be performed on the server. In this method, an intercepted device cannot bypass authentication, at least partially, because the compromised device or server provides no useful information to the attacker.

[0142] In one or more implementations, a processing agreement for biometric authentication is established in one or more BOPS implementations by the following: The biometric vector is split at least between the client and the server, and the approach to authentication is independent of the type of biometric measurement. For example, with facial recognition, the size of the initial biometric vector may be approximately 20KB, which will be minimized and accepted during the uplink / downlink of the HTTP request and HTTP response. A splitting algorithm for the IBV in facial recognition may be as follows: zero bits are white and one bit is black. Thus, the BOPS implementation can support visual cryptography (VC). As described herein, the present invention can be used virtually with any biometric and provides a mechanism to obtain the IBV and encrypt it using VC. In VC, matching is performed in plaintext. Alternatively, with random matching, matching is performed in an encrypted domain.

[0143] Referring specifically to Figure 12, the user-operated client computing device 104 proceeds to biometric enrollment (1) and captures an initial biometric vector (IBV) (2). In step (3), the IBV is encrypted and divided, with 2 / 2 of the IBV stored on or locally by the client computing device 104 (4), and an enrollment request containing 1 / 2 of the IBV is sent to the BOPS server 102 via the transport layer (via two-way SSL / TLS) (5). 1 / 2 of the IBV is stored by the BOPS server 102, for example, in the BOPS big data (6), and an enrollment confirmation is sent from the BOPS server 102 and returned to the client computing device 104 (7).

[0144] Continuing to refer to Figure 12, following Enrollment, biometric authentication is performed on the client computing device 104 (8), and the current biometric vector is captured (9). Subsequently, an authentication request is sent via the transport layer (10), which is received by the BOPS server 102 and used for decryption in combination with the 2 / 2 IBV (11). Then, the CBV is compared with the plaintext IBV (12), and a floating-point number is returned to the client 104 (14), and the result is displayed (15).

[0145] Referring here to Figure 13, an example 1300 of visual cryptography (VC) implemented with the present invention is shown. VC provides good synergy with cryptography, IBV partitioning, and IBV recovery without key management requirements. In this example of visual cryptography shown in Figure 13, black may be equal to 1 and white may be equal to 0. In this example, the IBV is equal to 00100110. XOR recovery can be used because this solution is Boolean. The encryption process of the original biometric vector can be performed using visual cryptography, and the result may be two vectors written as sheets, containing only white noise. A mobile storage device (e.g., client device 104) contains one of the sheets, and a server device 102 contains or accesses the other sheet. A verification process combines the two sheets using a simple Boolean operation, resulting in the fully recovered original biometric vector.

[0146] Table 1 below shows an example of IBV reconstruction using XOR operation.

[0147] [Table 1] Table 1

[0148] With respect to Table 1, and in relation to the example BOPS implementation, the encryption process of the original biometric vector may be performed using visual cryptography, and the result of this encryption is two vectors recorded as sheets containing only white noise. As described herein, the storage device associated with client device 104 contains one of the sheets, and the storage device associated with server device 102 contains the other sheet. The verification process combines the two sheets using a simple Boolean operation, thereby obtaining the fully restored original biometric vector.

[0149] Figure 14 shows an example of the superposition of two shares (2,2) in Visual Cryptography (VCS), where each bit is encrypted into a share, as associated with an example BOPS implementation. In the example shown in Figure 14, the selection of shares for the zero and one bits is random. When encoding the zero or one bit, a value is obtained from this table for one share, and the adjacent value in the same table is obtained for the other share. After this process, neither share provides any clue about the original bit. The value of the original bit can be obtained by superimposing the two shares (using OR or XOR).

[0150] Continuing with the example shown in Figure 14, the superposition of two shares (2,2) is represented by Visual Cryptography (VCS), where each bit is encrypted into a share. The selection of shares for zero and one bit can be performed by random processing. When encoding a zero bit or a one bit, a value is obtained from a table (e.g., Table 1) for one share, and the value next to it in the same table is obtained for the other share. After this processing, neither share provides any clue about the original bit. Then, the value of the original bit can be obtained by superimposing the two shares, for example, using OR or XOR. This is an example for the (2,2) VCS. VCS can be extended to more than two shares by changing the probability of random processing. By changing the probability of random processing from 0.5 to 0.25, the result is a share with 4 bits instead of the 2 bits in the 0.5 example. Furthermore, by changing the probability of random processing to 0.125, an 8-bit encryption is obtained for each input bit.

[0151] Regarding the detection of matches, one or more modules in a BOPS implementation, for example, employ multiple initial biometric vectors. Then there are two calls to a RESTful web service, one for each biometric, transmitted via SSL / TLS. One call can include half of the IBV in addition to the current biometric in the authentication session, and can return a floating-point value representing the strength of the match. The other call can provide one IBV (half) at a time, along with the current biometric, and can return a floating-point value representing the strength of the match. Regarding this second call, there can be several consecutive calls, for example, one IBV at a time to determine the match.

[0152] For example, the size determination calculation following the agreement of the matching process in the BOPS implementation can be done as follows: 20kb per face vector, 50 vectors for 10 seconds at 5 frames per second; 50 × 20kb = 1000kb.

[0153] An example of the logical calculations for the matching process associated with the implementation specified above is described below. The above 1,000KB is sent to the server for matching. If there is no match, the next 100KB is sent, and so on, until a floating-point value is determined. In one or more BOPS implementations, a minimum threshold is defined, and the floating-point value is at least within the range of the minimum threshold. According to the example matching algorithm, the current frame needs to have 200 milliseconds plus 125 milliseconds of uplink / downlink time to the server. That is, frame transmission, combined with the matching, results in a transaction speed of 325 milliseconds per frame. If the matching is constrained 100 milliseconds higher, frame transmission is approximately 425 milliseconds. Even if it fails, a batch of frames (e.g., 5 at a time) may be sent, and matching may be attempted again. Preferably, the matching process takes less than one second, but in certain less desirable cases, the matching process may take longer, for example, several seconds.

[0154] As shown and described herein, the flexible nature of the present invention, which is independent of the type of authentication unit and biometric, allows organizations to define individual authentication units and biometrics that can be used for authentication and can be designated as default biometrics. If there is no description of biometrics as part of a downstream transaction, it is possible to specify a default biometric, for example, at the organization level, the group user level, or the transaction level, through one or more user interfaces.

[0155] In one or more implementations, the management console can be configured as a graphical user interface and accessible to individual authorized users. The management console may include graphical controls that, when selected, will consequently be configured to the default biometric type. For example, one organization, ACME Plumbing, may specify that the face be the default biometric for all ACME employees for certain access. Furthermore, ACME Plumbing may specify that four fingers be the biometric for all customers in other contexts, and even further, both four fingers and the face be used for all employee transactions exceeding $10,000 in yet another context. These options are presented in the management console for the ACME Plumbing administrator making the specification. In other words, the present invention provides flexible and dynamic application for one or more biometrics.

[0156] Regarding authentication, a specific organization's setup may utilize multiple sources of biometric information, such as a condition engine, member profiles, and member definitions. This condition engine may be based on dynamic rules defined within the system. For example, every transaction exceeding $1,000 may require at least two forms of biometric verification. Member profiles define a user's role and corresponding privileges. For instance, a member profile "Information Security - First Responder" may require authentication every 10 minutes, or based on other conditions, such as each transaction involvement. Member definitions allow for the establishment of default authentication at the organization / integration level. For example, if four types of biometrics are available in the system—4F, FACE, and IRIS—and the default biometric for a particular BOPS / corporate implementation is "FACE," then facial recognition is available as the default and may be provided, for example, through a graphical user interface, such as the dashboard collectively referred to herein as the BOPS Admin Dashboard. Furthermore, individual conditions, such as those described above, can be prioritized. For example, it's possible to consider member definitions as having the lowest priority, and conditional engines as having the highest priority. The highest priority would be the authentication method.

[0157] The following describes example steps related to the Enrollment process according to this application. A mobile computing device 104, configured with a mobile client application, acquires a biometric vector, performs encryption, and makes an enrollment API call. In particular, the enrollment call to the BOPS server 102 after biometric acquisition includes half of the IBV, which is stored on the server 102 for access. The enrollment process makes it possible to initiate a BOPS implementation within the scope of an organization. While much of the description and drawings presented herein show a BOPS implementation appearing as a cluster, BOPS can be configured as a business component. Before a BOPS administrator ("BOPS admin") sets up an environment, the organization registers individual API keys from the BOPS server 102. Individual developers can similarly request API keys in various implementations.

[0158] After the enrollment process is complete, the original site admin can create additional site admins. Enrollment information can be associated with various site admins, for example, and with individual API keys associated with the organization. In one or more implementations, API registration can relate to two domains: the registered original site admin, and the issued API keys, which may be obtained based on the enrollment information, organization, and use case. The registration process is completed after the application is approved. Subsequently, the BOPS administrator (admin) may create the organization's original site admin, and that original site admin may then create site admins (see, for example, the role hierarchy chart shown in Figure 15).

[0159] It is preferable that developers register before the development process using the BOPS service, for example, by using an option in the BOPS administrator console. A new account can be established by providing an application name and identifying the developer using a question-oriented identification mechanism, and an API key is created that is identified by the application name and associated with the application.

[0160] In one or more BOPS implementations, communication between the application running on the client device 104 and the BOPS server 102 is established over two-way SSL / TLS. The Genesis process can establish this connection and determine how the user identifies themselves to the BOPS server 102; therefore, the server 102 can generate a private key and set up two-way SSL / TLS communication. Providing secret questions is one mechanism for users to identify themselves; this is an axiomatic approach, and individual groups (e.g., vendors) can provide a set of questions that uniquely describe an individual during the "Genesis" phase.

[0161] A client application running on the user computing device 104 is involved in providing a unique identifier (ID) to identify the end user's device 104. The application can use the device 104 and associated APIs to inform the BOPS server 102 about the connection between the user and the user device 104. A 5-tuple is one such mechanism that can be used to identify the device 104.

[0162] In one or more BOPS implementations, individual RESTful calls and / or behaviors that the system can use to counter attacks and attack vectors are identified. Furthermore, request formats that protect data in real time from known and unknown attacks are identified and can be made present in the IDS (e.g., via device 112). For example, access can be validated by using replay mitigation in cryptographic one-time tokens. In such cases, the IDS is a third layer that ensures server 102 is fully protected at the application layer by verifying that client 104 and server 102 are aware of each other.

[0163] Figure 16 is a block diagram 1600 showing replay prevention and related devices and transmission flows. As shown in Figure 16, a cryptographic one-time token validates access and protects server 102 at the application layer from International Organization for Standardization (ISO) Layer 7 cyberattacks, such as replays, distributed denial-of-service (DDoS) attacks, and other attacks. The combination of token and IDS is useful for detecting International Organization for Standardization (ISO) Layer 7 cyberattacks, such as replays, distributed denial-of-service (DDoS) attacks, and similar attacks. The token is valid for one use only and is typically passed from client 104 to server 102 and then returned to BOPS using a RESTful call.

[0164] The assumptions in one or more BOPS implementations are that, with respect to DDoS detection, all tokens should be distinct, and that at least one algorithm employed between the client and server should take into account that time may vary and that the values ​​should differ not only between clients but also between accesses. Figure 17 is an advanced flow 1700 showing the token algorithm and associated steps according to an example BOPS implementation. In step 1702, during the Genesis step, a web, mobile, or embedded device (client device 104) issues a RESTful call requesting a token. The token is then received and embedded in an encrypted message from client 104 to server 102 (1704). Server 102 receives the token, verifies the validity of the message by passing the token to the IDS (1706), then verifies that the token is valid and ensures that the difference between the creation time and the current time falls within a specified 60-second period (1708).

[0165] Figure 18 shows the Genesis / Enrollment and User / Device products in a many-to-many relationship. The mobile client 104 shows the identity elements associated with each account. On the server side of Figure 18, the BOPS server 102 is shown as being associated with identity attributes, accounts, and devices related to each identity. To ensure secure client / server communication with a high level of assurance, the identity information is associated with secure elements through which user accounts (for example, Alice's account or Bob's account shown in Figure 18) are properly authenticated according to their corresponding identities.

[0166] To initiate the Genesis step, client device 104 may choose to establish a 5-tuple by identifying one or all of the individual values ​​shown in Table 2 below. The IDS can determine any of these five values ​​not set by the client and can return a token to the client in RESTful format. Client 104 and server 102 share the same 5-tuple, which is then used to calculate a timestamp, which is a SHA512 that is subsequently encoded and compared by the IDS or BOPS server 102. The calculated timestamp moves backward to a certain time based on the 5-tuple and is unique for each call.

[0167] Therefore, in one or more implementations, the token does not contain the timestamp itself; rather, all values ​​within the token are converted to a SHA512 sum for comparison. This changes the interval between the minute values ​​in the number, making it possible to prevent blind replays. Furthermore, by configuring the token's minute range to be 3 (and not 60), a sufficiently large entropy (48,771,072) is possible, making it possible to prevent trial-and-error attacks.

[0168] Furthermore, the semantic engine can be configured to allow security administrators to generate additional custom parameters for detecting and preventing attacks that may be outside of any international standards, thereby providing further confirmation and balance against a wide range of attacks.

[0169] In one or more implementations, replay detection operates outside the 5-tuple. For example, values ​​such as those shown in Table 1 above may be provided to server 102. Alternatively, server 102 can randomly select a value. Depending on the replay, the acceptable range of values ​​and their entropy are determined first. If none of the values ​​in the 5-tuple are identified during the Genesis step, the algorithm may use the following values.

[0170] [Table 2] Table 2

[0171] In the example implementation, an algorithm that rotates backward is executed. If each month is less than or equal to the current month, the year can be considered the same year. Alternatively, if a month is greater than or equal to the current month, the year must be rotated backward. These two examples illustrate the algorithm.

[0172] [Table 3] Table 3

[0173] In Example 1, the current month is 8 (August), and the Genesis value for the month is 11. Since 11 > 8, the year range is narrowed to an interval of 5, making the year 2011. The remaining values ​​are multiples of the Genesis value that are less than the actual day value.

[0174] In Example 2, where the same current date and time are used, the current month is 8 (August), and the Genesis month value is 4, so 4 <= 8. The year is equal to 2015, and the range is narrowed to an interval of 5. That is, the year is 2015, and the remaining values ​​are multiples of Genesis that are less than the actual day value.

[0175] In one or more BOPS implementations, various levels of data privacy may be provided, each potentially including encrypted biometric information to prevent an individual from resetting and / or compromising their biometric data. One level of privacy can stipulate that all non-biometric data be stored in plaintext (passivated). This simplifies the reporting and analysis of usage patterns and authentication records, which can include other factors such as non-repudiation, location, date, and faceted search. For example, anyone could relatively easily see the number of authentication attempt failures in Cleveland during June 2016, and information about individuals and devices could be provided. This first level of privacy can be achieved as a function of a high-performance tool that operates on plaintext passiveized data. Another, higher level of privacy can stipulate that all non-biometric data be stored in encrypted form, but without requiring separate decryption keys for each client. In other words, the client device 104 may be configured to use the same decryption key, which is considered more secure than the first level of privacy described above, where it is most likely that insiders will not have access to it or will not have access to the decryption key. An even higher level of privacy may require that all non-biometric data be stored in encrypted form and that the decryption key be unique for each identity. This enhances privacy and isolation because each user's data is encrypted with a key associated with their biometrics. At higher levels of privacy, it is assumed herein that user data, such as personal information ("PII"), is always encrypted on the client device 104, except perhaps at the moment when matching is performed in memory. In one or more BOPS implementations, the user authenticates to authorize and authenticate a transaction in order to decrypt user data (e.g., login credentials, files, etc.).Furthermore, static data (e.g., passive data) is always encrypted on the server computing device 102 and the client device 104. Plaintext data preferably exists only in memory at the time the matching process is being performed.

[0176] In one or more BOPS implementations, an open platform is provided that allows for virtual, arbitrary customization of the Genesis flow. In some examples of Genesis, this may include a username and password for accessing Active Directory, a verification email or text message, or physical verification of personal identification information, such as a driver's license, birth certificate, passport, social security number, or other suitable credentials.

[0177] User account pre-registration may be performed in a batch process that enforces business rules, and organizational policies and procedures may contribute to those business rules. Business rules can be integrated into an access management platform, which groups users into groups or directories that determine levels of privileges and other attributes that will satisfy certain specific needs in role management. This provides developers with the flexibility to construct clear descriptions of member profiles (e.g., user profiles, administrator (admin) profiles, manager profiles, and senior administrator profiles) that can be applied as input to member definitions accessed by the BOPS server 102. The Genesis process according to this application forms a complete dependency on risk management and is therefore capable of determining downstream processing.

[0178] Figure 19A shows the device and steps 1900 related to multiple users initiating Enrollment on a single client device 104. The relationship between the user and device 104 can be "many-to-many" (M:M). The first Enrollment step can be added (A1, initiate biometric Enrollment, A2, request Enrollment (x.509), A3, return Enrollment requirements, A4, request account registration (device ID, user ID + 1 / 2 IBV), A5, return registration). These steps can be repeated for a second user (B1-B5). The many-to-many relationship can arise as a function to separate Genesis and Enrollment. Furthermore, a subject identified via Genesis can be registered multiple times using numerous biometrics. To initiate client / server communication, the user captures their biometrics on the client device, which leads to the operational Enrollment process for a unique client certificate issued to the client device. Once the security portion of the enrollment process is complete, the registration of the user's biometric information is successfully achieved, and the enrollment process ends. A user may have multiple devices (clients), and a device (client) may have multiple users. A device (client) may support multiple biometrics.

[0179] Figure 19B shows the device and step 1910 for initiating an authentication session from a client device 104 that stores information about multiple user accounts, with respect to Alice, an example user. In the example shown in Figure 19B, Alice initiates an authentication session (1), and an application running on the client device 104 requests biometric authentication (2). After biometric authentication is completed (3), the application running on the client device 104 instructs the device 104 to send Alice's identity attributes via TLS. Subsequently, the BOPS server 102 processes the authentication request based on the integrity of the Enrollment element and returns the result (5).

[0180] As shown in the example in Figure 19B, even if Alice mistakenly starts an authentication session using Bob's account, the client device 104 will not send any requests to the server because the CBV will be different from the IBV created during Enrollment, and authentication will fail.

[0181] Figure 19C shows an example of the device and step 1920 related to the revocation of a user's account. The example shown in Figure 19C shows information related to three users (Eve, Bob, and Alice). A user can define one or more revocation rules, for example, through an administrator console configured with a graphical user interface for administration. A role associated with the administrator (a person who can also be biometrically authenticated) is involved in enforcing the rules. In the example shown in Figure 19C, Alice's account has a valid certificate, Bob's account has an expired certificate blocked by the transport security layer, and Eve's account has been deactivated by the BOPS administrator. More specifically, after Eve's certificate is deactivated via the BOPS server 102 (1), an authentication request is received from the client device 104 associated with Eve's account (2). The BOPS server 102 returns a message indicating that Eve's access has been blocked or other suitable content (3). With respect to Bob's certificate, a 90-day period is specified after which Bob's certificate expires ("TTL") (4). Subsequently, an authentication request is received from the client device 104 associated with Bob's account (5), and, as with Eve, a message or other preferred content indicating that Bob's access has been blocked is sent to the client device 104 by the BOPS server 102 (6). With respect to Alice's account, an additional 90-day extension period is granted (7), and an authentication request is also received from the client device 104 associated with Alice's account (8). The BOPS server 102 returns a message or other preferred content indicating that Alice has been authenticated, for example, as shown and described herein (9).

[0182] One of the challenges addressed by the modules shown and described herein is the prevention of replay attacks. In one or more implementations, all tokens are distinguished with respect to DDoS detection, and the token is typically an identifier that associates a profile on the server with the identity in the Common Name (CN) field. The algorithm between client 104 and server 102 takes into account that time may vary and that the values ​​should differ not only between clients 104 but also between accesses.

[0183] In one or more implementations, certificate distribution works as follows: The X.509 certificate is preloaded on client device 104, for example, as a function of application software installed on client device 104. Before the Genesis process, client 104 establishes the 5-tuple values ​​by identifying any or all of the tuples (as shown and described herein). During the Enrollment process, client 104 issues a RESTful call to request a token from BOPS server 102. Upon receiving the token, it embeds it in the client's encrypted message to the server. The server verifies the validity of the message by receiving the token and ensuring that the difference between the creation time and the current time falls within a specified 60-second period. Server 102 determines which of the 5-tuple values ​​is missing and returns the token to the client in RESTful format. Client 104 and server 102 share the same 5-tuple values, which are then used, for example, in functional analysis, to calculate a timestamp that is a SHA512, which is subsequently encoded and compared by the IDS. For example, as described herein, the calculated timestamp is shifted backward to a certain time based on a 5-tuple and is unique for each call.

[0184] This application makes it possible to configure a time limit (Time-to-Live, or TTL) for a client certificate that remains valid. An invalid certificate for an authenticated user may be silently replaced with a new one. In other words, TTL is a "belt and suspenders" approach, which works to support user authentication in combination with IBV and CBV. Token revocation can also be conditional on the user's role and other factors that contribute to the demands of specific operations for authorization. For example, a certificate may be blocked after 1 or x failed authentication attempts for financial transactions, for example, if conditions y and / or z are not met.

[0185] Figure 20A is a simplified diagram showing the steps 2000 related to the initialization, verification, and confirmation of a client certificate between the client device 104 and the BOPS server 102. Steps related to processing a client signing request ("CSR") may include generating a public-private key pair in the client device 104 and signing the public key and subject name to be sent to the BOPS server 102 (hereinafter generally referred to as performing "Proof of Possession"). As described herein, the client sends a registration account request using two-way SSL. The BOPS server 102 verifies the subject name of the certificate, signs the client request with the private key of the BOPS Certificate Authority (CA), and generates a client certificate password using the OTP mechanism, and then returns the client certificate password to the client device 104. The registered client verifies the certificate signature and generates a .p12 container that stores the client private key and signed certificate, but not the password. Preferably, the password is never stored in the client device because the OTP mechanism generates a one-time password for each client request.

[0186] Figure 20B shows the 2010 client certificate registration process in an example integrating a third-party server and BOPS. This CSR process is outlined, for example, as shown in Figure 20A, and begins with user registration. In the example shown in Figure 20B, the steps related to Genesis and Enrollment are described using "Register User Account," where the client certificate represents identity attributes, and the account represents identity components.

[0187] In the implementation shown in Figure 20B, the user initiates the Enrollment process and sends their biometric information, including an account registration request, to the BOPS server 102, which triggers the generation of a key pair / CSR on the client 104. Upon receiving the registration profile request, the BOPS server 102 further sends it to an access management adapter (which may be an access management solution / platform used by a third-party company) for validation of the profile, as shown in Figure 20B, and then further sends it to a third-party server for verification and validation of the account login. The third-party server verifies the validity of the login data, provides an authentication token, and then returns the verification result to the access management adapter. The adapter then returns the authentication result and authentication token to the BOPS server 102, completing the account / profile registration. The BOPS server 102 encrypts the authentication token, stores the biometric data, signs the CSR with the BOPS CA, and sends the encrypted authentication token to the client application. This represents an implementation of an example, an implementation integrated into a company (e.g., a bank) that already has billions of accounts accumulated in its repository for advanced verification as a biometric authentication function.

[0188] In one or more implementations, a high-speed readable code (QR code) can be used to trigger the execution of one or more modules shown and described herein. For example, a business partner's (e.g., bank) login page can be configured to display a QR code image containing an identifier for each session opportunity. The MCA, implemented on the client computing device 104, can execute one or more modules (e.g., an authentication wizard) to scan the QR code, register the session in response to a signal attached to the session, and authenticate with the user's biometrics in accordance with the teachings herein. Figure 21 shows an example QR code authentication flow 2100 in which a third-party server registers a session opportunity with the BOPS server 102, and accordingly, information that can be used for a new authentication session may be provided to the third-party server by the BOPS server 102, and such information may be provided (e.g., displayed) within the QR code. The third-party server can send one or more requests regarding session status information. The user in Figure 21 (indicated as "Actor") scans a QR code to register a session with the BOPS server 102, which may also be communicated to an external third-party server. With biometric authentication as shown and described herein, the user session can be established, for example, by a third-party server.

[0189] In one or more further implementations of the BOPS server described and detailed herein, a secure user identity model is implemented using the BOPS server, where authority-based issuance of claims is provided, eliminating the need for a third-party identity provider during authentication. The described user identity model leverages blockchain technology to ensure the exchange of verifiable credentials without the need to entrust sensitive biometric data to a third party. For example, multiple cryptographic shares (and potentially redundant shares thereof) described with reference to Figure 14, spread across selective off-chain storage devices (such as portable hard disk drives, mobile device storage, IPFS, Dropbox, Google Drive, AWS, etc.), are retrieved by the BOPS server. These encrypted shares are provided to the BOPS server so that the user's verifiable credentials are used as part of the verification system. The combination of at least two identity technologies (DID and BOPS) enables independent and platform-type-independent verification of the user's existence. Here, by integrating biometric-based protocols in the registration and authentication process, the user is guaranteed to link their digital identity to their real-world presence. Furthermore, the user has complete control over this digital identity. Users can add further data to this digital entity, request others to add further information, or disclose some or all of the data depending on the context. Furthermore, users can record their consent to share data with others and facilitate such sharing. In other words, the digital identities described herein are persistent and portable, but their usefulness does not depend in any way on the authorization or validity verification of a single third party.

[0190] Referring particularly to Figures 22-25, a secure user identity model is implemented as a process or method for the secure exchange of biometric credentials using the BOPS standard. Referring here to Figure 22, the Biometric Open Protocol Standard (BOPS) discussed herein is implemented in a decentralized secure user identity model, giving users control over their authentication and the storage and use of their identity data.

[0191] More specifically, those skilled in the art in the essential technologies will understand that the described BOPS protocol is extensible to a combination of on-device (e.g., FIDO UAF compatible), server-side or multi-point distributed models utilizing remote storage, and a distributed authentication process that allows user control over authentication. The foregoing explanation is for the sake of simplicity and is not intended to limit the integration of the BOPS standard and further approaches enabled by one or more distributed ledger technologies. In fact, in one particular configuration, the BOPS standard enables the use of off-device biometric credentials for participation in authentication challenges and other network-based identity verification. However, in one or more further implementations, the biometric data used for authentication is not only distributed by the BOPS server to distributed storage locations but is also persistent to one or more distributed ledgers using blockchain technology, so as to provide cryptographic-based guarantees that the biometric data is secure and tamper-proof.

[0192] Continuing with reference to Figure 22, User 2200, for example, an end user (or simply "User"), is someone who holds control over the user's individual identification information and / or identity data. In one non-limiting example, User 2200 is a student, employee, customer, and others. However, in an alternative configuration, User 2200 can designate a retainer (e.g., BOPS server 102) that maintains control over the user's individual identification information and / or identity data. For example, the retainer could be one or more services, companies, or organizations authorized by User 2200 to engage in identification-based transactions on the user's behalf. In one or more implementations, authorized retainers include web services, mobile applications, or existing applications installed on or accessible from the user's personal devices (e.g., client devices). As used herein, retainer generally refers to any entity that receives distributed identification information, accesses stored distributed identity information, and / or provides such distributed identity information to a resource access provider in exchange for access to resources. In a specific implementation of 1, the BOPS server 102 described above is configured to function as a repository for various users 2200.

[0193] Each user 2200 requesting registration with the access control platform or identity authorization unit provides various biographic and / or biometric data as part of the registration process. Thus, the collection of biographic and biometric data can be considered as a digital representation of user identity. In one particular implementation, such collection of biographic and biometric information is encapsulated or packaged as a portable file or data structure. In one non-limiting implementation, the DID document 2204 functions as a portable container or file for such biographic and biometric information. In one or more implementations, the DID document 2204 is a data file, container, code, or digital document containing at least metadata necessary to interact with a remote authentication system that requests verification of the user's identity. In a further example, the DID document 2204 is a single JSON object. In a further implementation, the DID document 2204 is a JSON object conforming to the RFC7159 specification. In one or more non-limiting implementations, the DID document 2204 described herein may include authentication and authorization information. In certain configurations, DID document 2204 does not contain personal identifiable information (PII).

[0194] In certain configurations of the systems, methods, and computer products described herein, verifiable credentials are stored outside the blockchain and include at least one or more sets of authentication data or values, in addition to other personal information or credentials. In certain configurations, the set of authentication data may include a set of mechanisms that can be used to authenticate a user to an authentication system (e.g., public keys, biometric templates, or encrypted shares of biometric data). Furthermore, in one configuration, the set of authentication data contained in DID document 2204 includes authorization information that outlines which entities can modify DID document 2204. For example, if a user has granted the holder permission to modify the user's DID document 2204, then DID document 2204 itself will include data indicating the authorized user. Furthermore, the authorization data may also include a set of service endpoints used to initiate trusted interactions with entities such as service providers.

[0195] As further shown in Figure 22, the issuing unit 2206 is the entity that generates the DID document 2204. For example, the issuing unit 2206 is a server or processor configured by the code that executes it to generate the DID document 2204 in response to a registration request in the identity model from a user 2200. In one implementation, the issuing unit 2206 receives information about the expected registrant (e.g., biographic and biometric information) and transmits the received information to the DID document 2204. However, as shown in Figure 25, the issuing unit 2206 itself can delegate the processor that generates the DID document 2204 to a holding system or server, such as the BOPS server 102.

[0196] Any entity can be an issuer 2206, such as a retainer, while further examples of issuers 2206 may include corporations, governments, non-profit organizations, and / or individuals. In one or more configurations, the issuer 2206 transmits the generated DID identifier 2202 and / or DID document 2204 to the retainer. In further implementations, the issuer 2206 transmits the generated DID document 2204 to the identity hub 2208.

[0197] Continuing to refer to Figure 22, verifiable credentials are generated and stored in a secure location for further use. These verifiable credentials are stored, for example, in one or more identity hubs and repositories 2208. Here, the identity hubs and repositories 2208 are secure personal data repositories where the verifiable credentials are stored and retrieved. For example, the identity hubs and repositories 2208 are one or more local or remote access data storage devices accessible to user 2200, holding unit 102, or issuing unit 2206 for storing, modifying, or retrieving verifiable credentials. The identity hubs and repositories 2208 also relay or transmit messages and data to one or more inspection units 2210. In one or more implementations, the identity hub 2208 is configured as a database or storage system, flat file system, relational database, or bulk storage facility accessible by user 2200 or holding unit 102. For example, an identity hub could include Dropbox, Google Drive, AWS, Storj, and other similar "cloud" storage services.

[0198] In a further configuration, the issuing unit 2206 (or holding unit 102) also generates a distributed identifier (DID) 2202 which provides a reference to a DID document 2204. Here, the DID identifier 2202 is a unique identifier that enables retrieval or access to the DID document 2204 without providing a third party with direct access to the personal information referenced by verifiable credentials. In a non-exclusive implementation of 1, the DID identifier 2202 consists of a unique bit, digit, value, string, or sequence that is at least in part the result of cryptographically hashing user identity information contained within the DID document 2204. In a further implementation, the DID identifier 2202 is a text string, number string, alphanumeric string, or hexadecimal sequence, or any combination thereof. Furthermore, such combinations can be embodied in one or more data files, modules, or code fragments. In a further configuration, the DID identifier 2202 is a URI scheme conforming to RFC3986. For example, the DID identifier 2202 consists of a sequence of unique strings followed by an arbitrary path and / or fragment. For example, the issuing unit 2206 generates the DID identifier 2202 by hashing the authentication information stored in the DID document 2202. In an alternative configuration, the DID identifier 2202 is a unique value corresponding to the hashed value of the contents of the DID document 2204 and the storage location of the DID document 2204.

[0199] When a DID identifier 2202 is generated, a transaction record containing the DID is added as a transaction to one or more distributed ledgers 2212. That is, unlike the DID document 2204, the DID identifier 2202 itself is not stored within the identity hub 2208. Instead, the DID identifier 2202 is stored as a transaction within the distributed ledger or blockchain. Storing the DID identifier 2202 as a transaction within the distributed ledger serves not only as an immutable index of the DID document 2204 at the time of DID identifier 2202 generation, but also as an immutable record of the contents of the DID document 2204. Because the DID document 2204 and the DID identifier 2202 are cryptographically linked, when added to the distributed ledger 2212 as a transaction record, the DID identifier 2202 provides an audit trail of the authorized exchange between the issuer 2206, the holder / user 2200, and any third party (e.g., the inspector 2210) that wishes to verify the user's identity.

[0200] Without limiting itself to any particular implementation or configuration of distributed ledger technology, implementation, or specification, the use of the term “blockchain” refers to one or more technologies that provide a publicly transparent and distributed ledger for tracking and storing digital transactions in a publicly verifiable and secure configuration to prevent fraud or modification of underlying identity data. In one particular implementation, the blockchain or distributed ledger 2212 is a database configured as a public ledger configured to maintain a growing list of data records, where entries to the ledger form the blockchain by recording and linking data records using hashing. For example, each time a new transaction is added to the blockchain (e.g., a new DID identifier 2202), a new block is created containing the hash of the previous block. In this technique, each additional block generates further security with respect to the validity of the entire blockchain. Each block records and confirms the sequence and timing of a transaction as it is generated and / or recorded. That is, in one particular implementation, the DID identifier 2202 is stored as a transaction on the blockchain. In certain implementations, when the holder or issuer receives notification that the user (or holder) has provided information for registration with the authentication platform, it generates a DID identifier 2202.

[0201] When user 2200 requests access to a protected resource, the inspection / verification unit 2210 (which controls access to the protected resource) requests a claim in the form of a DID 2202 from the user or a holding unit representing the user in order to allow user 2202 to access the protected resource. The verification unit 2210 verifies that the credentials provided in support of the user's identity (e.g., in the DID identifier 2202 and in the DID document 2204) are suitable for the purpose and confirms the validity of the DID identifier 2202 in the blockchain 2212. In a non-limiting example, the inspection unit 2210 may include systems and servers maintained and provided by employees, security personnel and websites.

[0202] Referring here to Figure 23, in one or more specific implementations of the systems, methods and products implemented by the computer described herein, one or more BOPS servers 102 are configured to register users with the service provider, functioning as holders of biometric shares (as described above). Referring here to the flowcharts in Figures 23 and 24 and the block diagram in Figure 25, user 2202 is registered with the issuing unit 2206. Here, the user (via a user agent browser) is prompted by a user device 2300 or its software application, such as an MCA, which consists of one or more registration modules 2301, to register the user's biometric information with the service provider, which functions as the issuing unit 2206. In a specific implementation, the user device 2300 is configured by an IBV module 2303 to capture the user's initial biometric vector (IBV) (e.g., some biometric data), as shown in step 2103.

[0203] In a further implementation, as shown in step 2105, the captured biometric vector (IBV) is encrypted into at least two shares while remaining local to the user device 2300. For example, the user device 2300 is configured by the encryption module 2305 to visually encrypt the IBV into two or more shares. Here, as shown in step 2107, at least one of the encrypted shares of the encrypted IBV is stored on this local mobile device. In one or more implementations, the user device 2300 generates a vast number of shares using algorithms such as visual cryptography and Shamir's secret sharing. In one non-limiting configuration, the user device 2300 is configured by the encryption share storage module 2307 to store the encrypted shares in one or more local memory devices of the user device 2300 for later retrieval.

[0204] Continuing to refer to Figure 23, the user device 2300 is further configured by the key generation module 2309 to generate public and private keys. Here, as shown in step 2109 of Figure 24, the user device associates the public key with at least one share of the IBV. This public key and the cryptographic share associated with the public key are sent from the user device 2300 to the issuing server 2600A, as shown in step 2111.

[0205] Those skilled in the art will understand that at least one of the further encrypted shares of the IBV may be stored in one of the RDBMS or persistent cluster (e.g., Apache SOLR) backends, but instead, in step 2013, the issuing server 2600A sends the encrypted share and public key, along with the issuing entity signature data, to the BOPS server 102. Here, the issuing entity signature data may be any hash, code, cryptographic value, or data set that identifies the issuing server 2600A as the source of the encrypted share and public key. For example, the issuing entity signature data itself may be the public key or a public / private key pair, with the issuing entity being the holder of the private key.

[0206] As described above, the BOPS server 102 generates the DID document 2204 using not only the issuing department data but also the encrypted share and the public registration encryption key. For example, as shown in step 2115, the BOPS server 102 is configured to generate the DID document 2204 using the issuing department name, the registration public key and / or the encrypted share via the DID generation module 2401. The DID generation module 2401 is also further configured to generate a DID identifier 2202 to be used with the DID document 2204. For example, a unique DID identifier 2202 value is generated using the contents and location of the DID document. This value may represent not only the hash of the DID document 2204 or some or all of the contents of the DID document 2204, but also a specific storage location, file reference, index number, or other data necessary to identify or retrieve the underlying DID document 2204.

[0207] As shown in step 2117, the BOPS server 102 is configured to store DID documents in the identity hub 2208 by the DID storage module 2403. For example, the BOPS server 102 is configured to access the cloud-based storage repository 2208 by one or more APIs to store DID documents 2204 in one or more portable storage formats.

[0208] Furthermore, the BOPS server 102 is further configured to add the generated DID identifier 2202 to the blockchain 2212 selected for persistence by the DID persistence module 2405. In this method, the DID identifier 2202 provides a blockchain-independent method for resolving the DID document 2204. The DID persistence module 2405 configures the processor of the BOPS server 102 to generate transaction blocks and add them to an existing blockchain or distributed ledger. Alternatively, if such a ledger does not exist, the DID persistence module causes a distributed ledger to be generated and the new transaction added to that ledger. Those skilled in the art will recognize and understand that further functions, such as transaction block hashing, are recognized and understood.

[0209] In one configuration, in step 2117, after the BOPS server 102 registers the relevant DID in the blockchain 2212, the mobile device 2300 is notified of the success (or failure) of user registration. As shown in step 2119, if the user registration with the service provider is successful, the user will receive a DID identifier 2202 corresponding to the user's DID document 2204.

[0210] Focusing on a further implementation of the user registration system described, Figure 25 details the data exchange and prompting between user 2200 and registration service provider 2600. For example, user 2200 initiates the registration process using mobile application client 2300. The mobile application client 2300 requests an IBV from user 2200. For example, the mobile application client 2300 causes one or more imaging devices on the mobile computing platform to acquire one or more images of user 2200 to register with the service provider. As further shown in Figure 25, it is possible to convert the biometric vector into an encrypted share. As shown in the implementation in Figure 25, the biometric share is converted using the mobile client application 2300. Of the shares generated from the IBV, one of them is stored locally on the mobile application. Furthermore, if the mobile client application 2300 provides a public / private registration key pair, the private key is used to encrypt the encrypted share that is not stored locally on the mobile client.

[0211] For registration, the encrypted share and the public key of the registration key pair are sent to the service provider 2600. From here, as shown in the implementation of Figure 25, the service provider 2600 provides the issuing entity name (e.g., the public key from the service provider 2600). The issuing entity name, registration public key, and encrypted share are passed to the BOPS server 102. The BOPS server 102 acts as the holder for users requesting registration. The BOPS server 102 generates a DID document 2204 using the issuing entity name, encrypted share, and public key. Once generated, the DID document 2204 serves as the basis for generating a DID identifier 2202 to be attached to the specified compliant blockchain 2212. Once the DID identifier 2202 is generated and the corresponding DID document is stored on the blockchain, the DID identifier 2202 is returned to the mobile client application 2300, thereby giving the user ownership of half of the encrypted IBV share and a copy of the DID identifier 2202.

[0212] While it is possible to store multifaceted data on the blockchain, such as biometric shares, it will be understood that the approach described herein does not store any personally identifiable information on the distributed ledger or blockchain 2212. The biometric shares contained in the DID document 2204 are persistent "off-chain" via the identity hub or personal storage provider 2208, and only references to these "off-chain" data sets are placed within the scope of the public ledger system in the form of cryptographically arranged DID identifiers 2202. Thus, the encrypted biometric shares generated in the registration process provided in Figures 24-25 remain within the scope of the encrypted envelope, but references to these encrypted shares are now available via the blockchain through the associated DID identifier 2202. In this way, the DID identifier 2202 can be used as part of an authentication claim utilizing the same BOPS server 102 (as shown in Figure 23) or a different BOPS server including a verification unit. Here, the verification is possible because when the transaction record of DID identifier 2202 is accessed from blockchain 2212, any changes in the stored DID document 2204 will be revealed.

[0213] Focusing on Figures 26, 27A, and 27B, once the holding unit associates the DID document 2204 and the DID identifier 2202 with their respective personal identities and provides the DID identifier 2202 to the user, access to protected resources controlled by the verification unit server 2600B can be obtained using that information.

[0214] In a particular implementation, the BOPS server 102 provides an interface between the user's data store 2208 and the verification server 2600B. However, in further configurations, different BOPS servers with the same or similar functionality are provided, so that the registration function performed by the issuing server 2600A in Figures 23 and 24 is performed by a different server than the function performed by the verification server 2600B.

[0215] In the non-restrictive example shown in Figure 26, user 2200 uses a mobile client application (MCA) 2300 to request access to resources (e.g., content or data) on a website (e.g., a service provider). In this configuration, user 2200 is already set up and registered using a registration platform mediated by BOPS, as shown in Figures 24-25. Here, the user's specific DID identifier 2202 is created by the holder / issuer (shown in Figures 23-25) and is persistent to the blockchain, and the public key created at registration (in step 2109) is stored in the DID document 2204.

[0216] As part of the user request, the user sends the DID identifier 2202 and the public key created in step 2109 to the service provider (verification unit). In further implementations, the user request also includes the issuing unit name. The service provider (verification unit) 2600 passes this data to the BOPS server 102 along with a request to resolve the DID identifier 2202 via the blockchain and retrieve the corresponding DID document 2204. For example, the BOPS server 102 receives the DID identifier 2202, the issuing data, and the public key from the verification server 2600B.

[0217] Just as a URI uniquely characterizes a web resource by its URN and URL, a DID identifier 2202 characterizes an associated DID document 2204 using one or more blockchain ecosystems. Here, the BOPS server 102 functions as a resolver for a given DID identifier 2202, enabling the holding unit (BOPS server 102) to locate the corresponding DID document 2204. For example, the BOPS server 102 is configured, by a DID resolution module 2407, to look up the DID received in one or more blockchains in step 2606 and use the stored transaction information to identify individual verifiable credentials from an "off-chain" storage device.

[0218] As described, in one or more configurations, the DID identifier 2202 and its corresponding DID document 2204 are cryptographically associated with each other. Thus, any change in the DID document 2204 will cause the DID identifier 2202 to no longer cryptographically match the DID document 2204. Using this relationship, the BOPS server 102 is configured to evaluate (e.g., resolve) the DID document 2204 using the DID identifier 2202 and to verify, using the claim validity verification module 2409, whether the content of the DID document 2204 has been changed since the issuance of the DID identifier 2202. For example, a new DID identifier 2202 is generated for the retrieved DID document 2204. If the DID identifier 2202 received from the user does not match the newly generated DID identifier, the authentication process terminates.

[0219] When the BOPS server 102 accesses the DID document 2204, the DID document 2204 itself is further evaluated to determine whether the data values ​​it contains match the claims sent by the verification server 2600B. For example, the BOPS server 102 is configured, via the claim validity verification module 2409, to compare the issuing department name stored in the DID document 2204 with the issuing department name sent from the user device 2300 via the verification server 2600. In a further configuration, the claim validity verification module 2409 is also configured to configure the BOPS server 102 to compare the public key provided in the access request sent by the user device 2300 with the public key contained within the DID document 2204. If the data cannot be validated against the data in the DID document 2204, the process is stopped and no authorization is established.

[0220] Alternatively, for example, if the DID identifier 2202 and the DID document are cryptographically matched and the contents of the DID document 2204 match the encrypted signature of the issuing unit transmitted by the user device 2300, and the DID document 2204 is deemed to be a valid claim, the BOPS server 102 is configured to determine whether the user is authenticated by the verification module 2411.

[0221] For example, the BOPS server 102 is configured, via the verification module 2411, to request a set of biometric data from the user device 2300 and compare it with the stored encrypted share provided in the DID document. For example, in step 2610, the BOPS server sends a request to the user device 2300 regarding the user's candidate biometric vector (CBV), where the CBV is a biometric vector of the same type of biometric identifier used (in step 2103) to generate the IBV. For example, if the IBV includes facial recognition data and voice recognition data, the CBV requested by the user will also include both facial recognition data and voice recognition data. The user device 2300 is configured, via the CVB request module 2704, to capture the CBV from the user 2200 requesting access and send the CVB and the locally stored encrypted share directly to the BOPS server 102.

[0222] Upon receiving locally stored encrypted shares and CBVs from user 2200, the BOPS server 102 is configured, in step 2114, to decrypt the received encrypted shares and the encrypted shares stored in the DID document 2204 using the decryption module 2413. In further implementations, the decrypted shares are combined to restore the original IBV. Here, the IBV is compared with the CBV. For example, the BOPS server 102 is configured, using the comparison module 2415, to compare pixels, vectors, or other data of the IBV with equivalent data of the CBV.

[0223] As shown in step 2116, if the CBV value matches the IBV (or is within a predetermined threshold range for the IBV), a match is determined and an access verification notification is sent to the verification server 2600B.

[0224] Upon receiving the data, the verification server 2600B grants user device 2300 access to resources provided by the service provider. Once user 2200 has been verified, the decrypted share, IBV, CBV, and public key are removed from the memory of the BOPS server 102.

[0225] As shown in Figures 27A and 27B, a specific configuration of the resource access system is described. Here, user 2200 uses MCA 2300 to access resources (e.g., banking information, social media accounts, etc.) from service provider 2600. To request access, the MCA (acting on behalf of user 2200) sends the user's registration public key, DID identifier 2202, and issuer name. Here, the issuer name is, in one implementation, the public key obtained from issuer 2600 during the registration process, as shown in Figures 24 and 25. Upon receiving these user credentials, the service provider creates a session with BOPS server 102, which acts as the holder for user 2200.

[0226] Here, the BOPS server 102 uses the DID identifier 2202 to resolve the location of the DID document 2204. In a further implementation, the BOPS server 102 first verifies the validity of the DID identifier by evaluating the transaction record on the blockchain. As shown in Figures 27A and 27B, once the location of the DID document 2204 is resolved, the DID document 2204 is accessed and returned to the BOPS server 102. Also, the verified credentials stored in the identity hub 2208 are accessed and returned to the BOPS server 102. In one or more configurations, the verified credentials are the encrypted share (2 / 2) of the user's registered identity. The issuing department name stored in the DID document 2204 is evaluated and verified. Furthermore, the user's provided public key is verified by comparing it with the public key stored in the DID document 2204.

[0227] In the configuration shown in Figures 27A-B, the BOPS server 102 sends a request to the MCA2300 for a local copy of the encrypted IBV share and a signed challenge. Here, the signed challenge may relate to the current biometric vector. For example, when the MCA2300 receives a request from the BOPS server 102, the MCA prompts the user to retrieve the biometric identifier and encrypt it with the private key of the registered key pair. Encrypted biometric identifier, encrypted share, and signed challenge

[0228] As further shown in Figures 27A-B, the signed challenge is verified by the BOPS server 102, and the encrypted share received from the MCA is decrypted using the registered public key. Once decrypted, the IBV is restored by decrypting and combining the IBV share. The restored IBV is compared with the current biometric identifier. If there is a match, the current user and the registered user are the same, and the user is granted access to the resource.

[0229] Focusing on Figure 28, in one or more configurations, the user is authenticated remotely. Here, the new service provider (e.g., acting as the verification unit) uses one or more BOPS servers 102 configured to authenticate user 2200 via the remote authentication module 2417 even if user 2200 has never registered with the new service provider before. In this configuration, the BOPS servers function as the holding unit. As shown in relation to the workflow in Figure 28, authentication can be effectively performed using only user 2200 and the verification server 2600. This configuration is in contrast to and an improvement over other "first-instance" authentication methods such as SAML or OAuth, which rely on a third-party identity provider (IdP) for the intermediary's identity claims in conventional single sign-on (SSO) systems. The configuration of the elements provided here helps the user, who has control over the authentication data via the use of blockchain technology, to ensure that credentials issued by one or more valid authorities (e.g., the issuing unit) are for subsequent use with the new service provider.

[0230] In one or more further configurations, a user (e.g., user 2200) can locally authenticate their user identity when requesting access to a protected resource that the user has not previously registered for. For example, a holder can access issued claims, such as encrypted biometric shares, on behalf of the user during authentication, but is required to perform biometric authentication locally. As illustrated, a local configuration of the BOPS server 102 allows for the combination of biometric shares on the mobile device 2300. As shown in more detail with respect to Figure 28, portions of biometric shares stored in or with the DID document 2204 are retrieved by resolving the DID identification information 2202 referenced from the corresponding DID document 2204. However, unlike the workflow in Figure 24, here the accessed biometric shares are sent to the client by the service provider and the corresponding BOPS server 102. In a particular implementation, the biometric shares sent to the user via the service provider and the BOPS server are not visible to the service provider and the BOPS server. However, the server is provided with sufficient information to understand that it will use the corresponding share on the mobile device (of the biometric shares sent from DID document 2204) for matching based on the HMAC of the encrypted second share. It should be noted that the registered share is never sent to the device, but both shares are held locally according to the BOPS local configuration. The mobile device must hold a private key associated with the registered share for the DID, because it uses the share to calculate the HMAC and sends the HMAC to the server. The server can then compare the HMAC key to the undisclosed encrypted share from the DID document to provide access to the protected resource.

[0231] Further implementations of the systems, platforms, and approaches described herein provide a computer-based method for matching a biometric input record with a biometric record stored in multiple distributed ledgers, where the biometric identifier or DID document 2204 is stored directly within the blockchain (as opposed to reference only through DID 2202). As shown in Figure 29, in one particular implementation, in step 2902, an initial biometric vector is provided to a neural network. The neural network is configured in step 2904 to convert the initial biometric vector into a Euclidean metricable feature vector. Moving to step 2906, the Euclidean metricable feature vector is digitally signed using the private key of a first public / private key pair. The signed Euclidean metricable feature vector is then encrypted in step 2908 using the public key of the first public / private key pair.

[0232] In a further configuration, the encrypted Euclidean metric feature vectors are distributed across multiple ledgers (e.g., one or more identified blockchains) via the BOPS server 102, as shown with respect to step 2910. Here, the Euclidean metric feature vectors are stored on individual nodes of blockchain 2212, along with at least the public key of the first public / private key pair.

[0233] Each node in the distributed ledger (blockchain) decrypts the Euclidean metric feature vector using the public key of the first public / private key pair to verify the validity of the Euclidean metric feature vector. Furthermore, each node is configured to append the Euclidean metric feature vector to its individual ledger 2212.

[0234] The described method further includes receiving a current biometric vector representing an encrypted biometric input record from a mobile computing device 2300 on a data communication network, as shown in step 2912. The received current biometric vector is provided to a neural network, which converts the current biometric vector into a current Euclidean metricable feature vector, as shown in step 2914.

[0235] In one configuration, the current Euclidean metricable feature vector is signed in step 2916 using the private key of a second public / private key pair, and encrypted in step 2918. The signed and encrypted current Euclidean metricable feature vector is then distributed in step 2920, along with the public key of the second public / private key pair, among multiple ledgers 2212 stored on individual nodes.

[0236] More specifically, each individual node of the multiple distributed ledgers is configured in step 2922 to decode the current Euclidean metricable feature vector using the public key of the second public / private key pair and to verify the validity of the current Euclidean metricable feature vector. Furthermore, each individual node is further configured to use the current Euclidean metricable feature vector to perform a search of at least some of the Euclidean metricable feature vectors stored in the ledger. For example, as shown in step 2924, the biometric input record is matched against at least one biometric record as a function of the absolute distance calculated between the current Euclidean metricable feature vector and each calculation of individual Euclidean metricable feature vectors in the portion of the ledger.

[0237] As used herein, “processor” or “computer” means one or more electronic devices (e.g., semiconductor-based microcontrollers) that execute a given set of instructions, composed of codes in software form. For example, the evaluation server 102, database 108, and remote access device 104 include one or more processing or computing components that run a commercially available or custom operating system, such as an implementation of a Microsoft Windows, Apple OSX, UNIX, or Linux-based operating system. In other implementations, the evaluation server 102, database 108, and remote access device 104 each include custom or non-standard hardware, firmware, or software configurations. For example, a processor or computer may include one or more of the following: microcomputing components, on-chip computers, field-programmable gate arrays, graphical processing units, home entertainment consoles, media players, set-top boxes, prototyping devices, or a collection of “hobby” computing components. Such computing components described are directly or indirectly connected to one or more memory storage devices (memories) to form a microcontroller structure. The memory is a persistent or non-persistent storage device that functions to store an operating system for a processor in addition to one or more software modules. According to one or more embodiments, the memory includes one or more volatile and non-volatile memories, such as read-only memory ("ROM"), random access memory ("RAM"), electrically erasable programmable read-only memory ("EEPROM"), phase-change memory ("PCM"), single in-line memory ("SIMM"), dual in-line memory ("DIMM"), or other memory types.Such memory may be fixed or removable, for example, through the use of removable media cards or modules, object-oriented databases, hybrid relational object databases, or key-value data stores such as HADOOP or MONGODB, in addition to structures and other systems for data retrieval that are well known to those skilled in the art. The database 108 includes the necessary hardware and software to enable a processor local to the content evaluation server 102 to retrieve and store data within the database 108.

[0238] Computer memory may also include secondary computer memory, such as magnetic disk or optical disk drives or flash memory, which provide long-term storage of data in a manner similar to persistent memory devices. In one or more embodiments, the processor's memory provides storage for application programs and data files as needed.

[0239] The processors or computers described herein are configured to execute code written in standard, custom, proprietary, or modified programming languages, such as JavaScript, PHP, Ruby, Scala, Erlang, C, C++, Objective-C, Swift, C#, Java, Assembly, Go, Python, Perl, R, Visual Basic, Lisp, TensorFlow for ML, mClust, or Julia, or other object-oriented, functional, or other paradigm-based programming languages, including standard sets, subsets, supersets, or extensions.

[0240] In a particular implementation, a processor computer is implemented as one or more of a server, computing cluster, cloud platform, or computing array, and is configured to communicate and exchange data directly or via communication connections with one or more remote access devices, such as mobile phones, tablet computers, workstations, desktop computers, or other computing components.

[0241] As provided in the illustrated implementation, the computer and processor are configured, by the code they execute, to receive queried electronic data from one of several remote data storage locations (e.g., a database), and to evaluate the queried or accessed data according to predetermined or dynamic rules, logic, instructions, or algorithms. The physical structure of the database can be implemented as solid memory (e.g., ROM), hard disk drive systems, RAID, disk arrays, storage area networks ("SAN"), network-attached storage ("NAS"), and / or other suitable systems for storing computer data. Furthermore, the database may include caches, such as database caches and / or web caches. Programmatically, the database may include flat file data stores, relational databases, object-oriented databases, hybrid relational object databases, and key-value data stores such as HADOOP or MONGODB, in addition to structures and other systems for data retrieval that are well known to those skilled in the art. The database includes the necessary hardware and software to enable a processor local to the server to retrieve and store data in or within the database.

[0242] As used herein, a remote access device is used to exchange data, such as electronic messages, data packages, streams, or files, with one or more local or remote computers or processors (e.g., servers) over a network. In one implementation, the remote access device connects directly to the server, for example, via an internal local network. Alternatively, the remote access device is configured with software and hardware suitable for connecting to the server by first connecting to the internet. As used herein, a remote access device is a general-purpose or specialized computing device composed of hardware or software modules that connect to a network and receive data. For example, a remote access device may be a personal communication device (smartphone, tablet computer, etc.), which is configured to exchange data, including content, with one or more computers or processors using one or more code modules. The remote access device is configured to utilize wired or wireless communication means such as CDMA, GSM, Ethernet, Wi-Fi, Bluetooth, USB, serial communication protocols, etc., and hardware that connects to one or more access points, switches, network nodes, or network routers, for example, but not limited to these. In certain configurations, the remote access device is also configured to connect to further remote servers, computers, peripherals, or other hardware via hardware and software modules, either over a local or remote network or over the internet, using standard or custom communication protocols and settings (e.g., TCP / IP).

[0243] In one embodiment, the remote access device, processor, and computer run a commercially available or custom operating system, such as a Microsoft Windows, Apple OSX, UNIX, or Linux-based operating system implementation. In other implementations, the remote access device, processor, and computer have custom or non-standard hardware, firmware, or software configurations. The remote access device, processor, and computer can communicate with one or more remote networks using USB, digital input / output pins, eSATA, parallel port, serial port, FireWire, Wi-Fi, Bluetooth, or other communication interfaces.

[0244] This specification contains numerous specific implementations and details, which should not be construed as limitations on the scope or claimed scope of any configuration, arrangement, implementation, or embodiment, but rather as descriptions of features that may be specific to a particular implementation or one or more specific embodiments. Certain features described herein in the context of a separate implementation may also be implemented in combination in a single configuration or arrangement. Conversely, various features described in the context of a single implementation may also be implemented individually or in any preferred sub-combination in multiple configurations or arrangements. Furthermore, each feature may be described above as functioning in a certain combination, and may have been described as such initially, but in some cases, it is possible to remove one or more features from the described combination and make the described combination a sub-combination or a variation of a sub-combination.

[0245] Similarly, while operations are shown in a specific order in the diagrams, this should not be understood as requiring that the operations be performed in a specific illustrated or sequential order, or that all of the described operations be performed, in order to achieve the desired result. In some situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the program components and systems described can generally be integrated together in a single software product or packaged in multiple software products.

[0246] The terms used herein are for the sole purpose of describing specific embodiments and are not intended to limit the invention. Where used herein, the singular forms “a,” “an,” and “the” are also intended to include the plural forms unless otherwise explicitly stated in the context. Where used herein, the words “comprise” and / or “comprising” identify the presence of the described features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0247] It should be noted that the use of ordinal numbers in the claims, such as “first,” “second,” and “third,” which modify certain claim elements, does not in itself imply any priority, rank, or order of any one claim element relative to another or temporal order in which the actions of a method are performed. Rather, it is used simply as a mark to distinguish one claim element having a certain name from another claim element having the same name (though the original word is still used), and to distinguish the claim elements from each other. Furthermore, the language and terminology used herein are for illustrative purposes only and should not be considered limiting. The use herein of “including,” “comprising,” “having,” “containing,” “involving,” and their variations means that additional items are included, as well as the items listed thereafter and their equivalents.

[0248] This specification has described specific embodiments of the subject matter. Other embodiments exist within the scope of the appended claims. For example, the operations enumerated in each claim can still achieve the desired results even if performed in a different order. For instance, the processes shown in the appended drawings do not necessarily require the specific order or sequence shown to achieve the desired results. In some embodiments, multitasking and parallel processing may be advantageous.

[0249] Throughout this application, references have been made to published gazettes and publicly known registered trademarks representing various systems, which are incorporated herein by reference. No reference to any of the published gazettes or documents above is intended to endorse any prior art, nor does it constitute any endorsement of the content or date of such published gazettes or documents. All references cited herein, such as published and pending patents and patent applications, are incorporated by reference to the same extent as individual published gazettes and references are specifically and independently cited and incorporated herein by reference.

[0250] The present invention has been described in particular with respect to its preferred embodiments, but those skilled in the art will understand that various modifications in form and detail can be made therein without departing from the spirit and scope of the invention. Thus, the present invention is not defined by the discussions made herein, but by the subsequent points, by the individual features enumerated therein, and by the equivalents of such features.

Claims

1. 1. A computer-implemented method for enrolling an identity with an authentication system, the method comprising: receiving, from a mobile computing device over a data communications network, at least one encrypted cryptographic share of an initial biometric vector (IBV) and a public key of a first public / private key pair mathematically generated using a seed, the at least one encrypted cryptographic share encrypted using the private key of the first public / private key pair; generating a first identity data set including at least a signature of an authorization system, a public key of said first public / private key pair, and said at least one encrypted cryptographic share; storing the first set of identity data in at least one remote storage location; generating an identity reference value associated with the first identity data set, the identity reference value resolving a storage location of the first identity data set and being cryptographically associated with the generated first identity data set; distributing transaction records including at least said identity reference values ​​among each of a plurality of ledgers stored on individual nodes; providing at least the identity reference value to the mobile computing device.

2. 2. The method of claim 1, wherein the cryptographic share of the received IBV is generated by providing the initial biometric vector to a neural network that converts the initial biometric vector into a Euclidean quantifiable feature vector, and encrypting the Euclidean quantifiable feature vector with the private key of a first public / private key pair.

3. The method of claim 1 , wherein the IBV is visually encrypted using Shamir's secret sharing algorithm.

4. 1. A system for providing access to a resource provider to a user, comprising: A processor having a memory, wherein one or more modules from a mobile computing device over a data communications network, at least an identity reference value associated with a first identity data set, resolving a storage location of the first identity data set and cryptographically associated with the first identity data set, the first identity data set including at least an authorization system specific data value, a public key of a registration public / private key pair mathematically generated using a seed, and at least one remote encrypted cryptographic share of an initial biometric vector of the user requesting access; The signature value of the authorization system, receiving a public key of the registration public / private key pair; Locating a transaction record including at least said identity reference value among a plurality of ledgers stored on each node; determining a storage location of a corresponding first identity data set from the located transaction record; accessing a cryptographically associated first set of identity data; verifying a signature value of the authorization system of the first set of identity data and a registration public key; receiving a current biometric vector and a local encrypted biometric cryptographic share from the mobile computing device; decrypting the received local encrypted cryptographic share and the remote encrypted cryptographic share using the public key of the registered public / private key pair; combining the decrypted local cipher share with the decrypted stored cipher share to form a combined cipher vector; a processor configured to compare the combined cryptographic vector with a current biometric vector; If the combined cryptographic vector matches a current biometric vector, the system causes the resource provider to provide access to the resource to the user.

5. Comparing the combined cryptographic vector with the current biometric vector includes:

5. The system of claim 4, further comprising providing the combined cryptographic vector and the current biometric vector to a neural network that transforms the combined cryptographic vector and the current biometric vector into respective Euclidean metric feature vectors.

6. 6. The system of claim 5, wherein the combined cryptographic vector is matched to the current biometric vector as a function of an absolute distance calculated between each Euclidean metric feature vector of the combined cryptographic vector and each calculation of a Euclidean metric feature vector of the current biometric vector.

7. The processor: Classifying Euclidean metric feature vectors, and / or further configured to classify the current Euclidean metric feature vector; The system of claim 5 , wherein the classification is performed at least in part using one or more distance functions.

8. 8. The system of claim 7, wherein classifying the Euclidean metric features and / or the current Euclidean metric feature vector results in floating-point values, and the absolute distance between each floating-point value and its mean is calculated using the Frobenius algorithm.

9. 8. The system of claim 7, wherein the search occurs in time of order log(n).

10. The processor: Use the Frobenius algorithm to classify Euclidean metric biometric vectors, traversing the hierarchy of classified Euclidean metric biometric vectors in time of order log(n); The system of claim 7 , further configured to identify the respective Euclidean metric biometric vector as a current Euclidean metric feature vector.

11. The processor: Identifying a plurality of floating-point values ​​for each Euclidean metric biometric vector; The system of claim 5 , further configured to use a bitmap to exclude from the absolute distance calculation any of a plurality of values ​​that are not present in all of the vectors.

12. The processor: Identifying a plurality of floating-point values ​​for each Euclidean metric biometric vector; 6. The system of claim 5, further configured to define a sliding scale of importance based on the number of vectors in which each one of the floating-point values ​​appears.

13. 6. The system of claim 5, wherein the neural network is configured with various convolutional layers along with rectified linear layers (ReLU) and pooling nodes.

14. the neural network is configured to use pooling as a form of nonlinear downsampling; 6. The system of claim 5, wherein the one or more pooling nodes progressively reduce the spatial extent of the represented Euclidean metric feature vector to reduce the amount of parameters and computations in the neural network.

15. The processor: For each of the plurality of stored Euclidean metric feature vectors, calculating a relative position difference between the average face vector and the individual Euclidean metric feature vector; The difference in relative position is squared, Add up the values ​​and The method of claim 14 further comprising calculating the square root thereof.

16. 6. The system of claim 5, wherein the performance of the neural network is determined as a function of a cost function, where the number of layers given as the spatial magnitude of the output quantity is calculated as a function of the magnitude W of the input quantity, the size K of the kernel field of the layer neurons, the stride S applied to the layer, and the amount P of zero padding used on the boundaries.

17. 6. The system of claim 5, wherein the neural network transforms the initial biometric, the current biometric vector as a function of matrix multiplication for each layer and uses a Euclidean distance algorithm based on a Euclidean cost function.

18. 1. A computer-implemented method for matching a biometric input record with biometric records stored in multiple distributed ledgers, the method comprising: providing the initial biometric vector to a neural network that transforms the initial biometric vector into a Euclidean metric feature vector; digitally signing the Euclidean metric feature vector with a private key of a first public / private key pair; encrypting the Euclidean metric feature vector with a public key of a first public / private key pair; Distributing at least the encrypted Euclidean quantifiable feature vector and the public key of the first public / private key pair among a plurality of ledgers stored on individual nodes, each of the individual nodes comprising: encrypting the Euclidean metric feature vector with a public key of a first public / private key pair; Verify the validity of Euclidean metric feature vectors, and the distribution adding a Euclidean metric feature vector to each node's ledger; receiving a current biometric vector representing an encrypted biometric input record from a mobile computing device over a data communications network; providing the current biometric vector to a neural network that transforms the current biometric vector into a current Euclidean metric feature vector; digitally signing the current Euclidean metric feature vector with a private key of a second public / private key pair; encrypting the current Euclidean metric feature vector with the public key of a second public / private key pair; and distributing at least the current Euclidean metric feature vector and the public key of the second public / private key pair among a plurality of ledgers stored on individual nodes, each of the individual nodes comprising: decrypting the current Euclidean metric feature vector using the public key of the second public / private key pair; Verify the validity of the current Euclidean metric feature vectors, and performing a search of at least a portion of the Euclidean metric feature vectors stored in the ledger using the current Euclidean metric feature vector; A method for matching a biometric input record with at least one biometric record as a function of the absolute distance calculated between a current Euclidean quantifiable feature vector and each calculation of an individual Euclidean quantifiable feature vector in a portion of a ledger.

19. 20. The method of claim 18, wherein the Euclidean metric feature vector is validated as a function of decrypting the Euclidean metric feature vector with a private key of the first public / private key pair and verifying that there is no modification of the Euclidean metric feature vector by comparing the Euclidean metric feature vector at each node with the decrypted Euclidean metric feature vector.

20. Signing a Euclidean metric feature vector is generating a hash value associated with the Euclidean metric feature vector; encrypting the hash value using a private key of a first public / private key pair; 20. The method of claim 18, wherein the hash value is decrypted by each individual node using a public key of a first public / private key pair and compared to the hash value decrypted using the private key of the first public / private key pair.

Images