System and method for biometric protocol standards

Abstract

To securely communicate between a client device and a BOPS server.SOLUTION: In a method, a biometric open protocol standard (BOPS) server receives a registration request from a client device configured via a distributed client software application and processes the registration request. The registration request is usable to register the client device on a network and includes an encrypted partial initial biometric vector associated with a user. Then, for including an encrypted partial second biometric vector and processing an authentication request associated with a user of the client device, comparison of the encrypted partial initial biometric vector and the encrypted partial second biometric vector is performed, a value representing the comparison is transmitted to the client device, and the client device is authenticated when the value exceeds a minimum threshold.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application is a continuation-in-part of, based on, and claims priority to U.S. patent application Ser. No. 15 / 800,748, filed November 1, 2017, entitled "SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS," which is now U.S. Patent Application No. 9,838,388, filed August 22, 2016, which is a continuation-in-part of, and claims priority to, U.S. patent application Ser. No. 62 / 208,328, filed August 21, 2015, entitled "SYSTEM AND METHOD FOR BIOMETRIC PROTOCOL STANDARDS." No. 15 / 243,411, which claims priority to "U.S. Patent Application No. 62 / 241,392, filed October 14, 2015, which claims priority to "U.S. Patent Application No. 62 / 241,392, filed October 14, 2015," and which is a continuation-in-part of U.S. patent application No. 16 / 378,044, filed April 8, 2019, which claims priority to U.S. patent application No. 15 / 592,542, filed May 11, 2017, now Patent No. 10,255,040, each of which is incorporated herein by reference as if set forth in its respective entirety. [Background technology]

[0002] The present invention relates generally to security, and more particularly to a system and method for identifying or authenticating a user.

[0003] Information of all kinds continues to be stored and accessed remotely, such as on storage devices accessible via data communication networks. For example, many people and businesses store and access financial information, health and medical information, goods and services information, purchasing 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., buying, transferring, selling, etc.) using prohibited identities. In a typical scenario, a user registers to access information and then submits a username and password to "log in" and access the 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 provisioning systems rely on centralized databases, which present a security compromise: if the system is compromised, it will directly threaten the user's digital identity.

[0005] Thus, there is a need in the art for systems, methods, and computer-implemented approaches that overcome the security vulnerabilities inherent in such user identity systems. Summary of the Invention

[0006] The systems, methods and computer products described herein are directed to user authentication where there is no compromise of the user identity. For example, a computer-implemented method for registering an identity with an authentication system is provided. 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 a public key of a first public / private key pair mathematically generated with a seed, the at least one encrypted cryptographic share being encrypted with the private key of the first public / private key pair. The described method also includes generating a first identity data set including at least an authorization system signature, the signature being a digital signature, the public key of the first public / private key pair, and the at least one encrypted cryptographic share, and storing the first identity data set at at least one remote storage location. In one or more further implementations, the described method includes 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 cryptographically associated with the generated first identity data set. As a further example, the described method also includes distributing the transaction record including at least the identity reference value among each of a plurality of ledgers stored in the respective 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 for providing a user with access to a resource provider includes a processor having a memory, the processor configured with one or more modules to receive from a mobile computing device on a data communication network at least an identity reference value associated with a first identity data set, the identity reference value 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 a specific data value of the authorization system, 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 a user requesting access. The processor of the system is further configured to receive a signature value of the authorization system, the signature being a digital signature, and the public key of the registration public / private key pair. The system is configured to use the received data to locate a transaction record including at least the identity reference value among a plurality of ledgers stored in the respective nodes, and to determine from the located transaction record a storage location of the corresponding first identity data set. In a particular implementation, the system also includes a processor configured to access the cryptographically associated first identity data set and verify the authorization system signature value and the registration public key of the first identity data set. In a further implementation, the processor of the system is configured to receive from the mobile computing device a current biometric vector and a local encrypted biometric cryptographic share and to decrypt the received local encrypted cryptographic share and the remote encrypted cryptographic share using a public key of the registration public / private key pair.A processor of the described system can then combine the decrypted local cryptographic share with the decrypted stored cryptographic share to form a combined cryptographic vector and compare the combined cryptographic vector to the current biometric vector. If the 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 communications are 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. The registration request includes an encrypted partial initial biometric vector usable to register the user computing device on a network and associated with the user. An authentication request is subsequently received and processed, the authentication request including an encrypted partial second biometric vector and associated with a 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.

[0009] In one or more implementations, secure communications are provided between a user computing device and a server computing device. A registration request is processed, the registration request being received from a user computing device configured with a distributed client software application. The registration request includes a first portion of a first biometric vector usable to register the user computing device in a network and associated with the user. The first portion of the first biometric vector is stored, and a subsequently received authentication request including a second biometric vector and a second portion of the first biometric vector is processed. The first and second portions are combined and compared to the second biometric vector. 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.

[0010] In one or more implementations, a certificate is provided that is included in the enrollment request and the authentication request, and processing the authentication request includes determining whether the certificate is current and has not been revoked.

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

[0012] In one or more implementations, processing the authentication request includes performing at least one match operation in an encryption space as a function of the one-way encryption, which can be performed using a random one-way pad.

[0013] In one or more implementations, a role collection is provided and defined by one or more rules for accessing a digital asset, and a server computing device provides or denies access to the digital asset at a user computing device in response to the role collection. Access may be provided in response to at least one of discretionary 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 usable to register a second user of the user computing device in a 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-temporary processor-readable medium that is accessible by or is part of the server computing device.

[0015] In one or more implementations, the server computing device may revoke a user's registration.

[0016] Other features and advantages of the present invention will become apparent from the following description of the invention which refers to the accompanying drawings. [Brief description of the drawings]

[0017] Further aspects of the present disclosure will be more readily understood from consideration of the following detailed description of its various embodiments, when taken in conjunction with the accompanying drawings, in which:

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

[0019] [Diagram 2] FIG. 2 shows the devices and the flow of information between them associated with an example BOPS implementation. [Diagram 3] FIG. 3 shows the devices and the flow of information between them associated with an example BOPS implementation. [Figure 4] FIG. 4 shows the devices and the flow of information between them associated with an example BOPS implementation. [Diagram 5] FIG. 5 shows the devices and the flow of information between them associated with an example BOPS implementation. [Figure 6] FIG. 6 shows the devices and the flow of information between them associated with an example BOPS implementation.

[0020] [Figure 7A] FIG. 7A illustrates the devices and steps associated with an example enrollment process, with particular emphasis on data confidentiality, in accordance with one or more implementations.

[0021] [Figure 7B] FIG. 7B illustrates an example management console provided with a user interface in accordance with the present application.

[0022] [Figure 8] Figure 8 provides an overview of the enrollment process, including data access and exchange, involved.

[0023] [Figure 9] FIG. 9 illustrates components of a security architecture in accordance with one or more implementations of the present application.

[0024] [Figure 10A] 10A and 10B show two respective alternative enrollment processes and associated apparatus and steps in accordance with one or more implementations of the present application. [Figure 10B] Same as above.

[0025] [Figure 11] FIG. 11 is a block diagram illustrating possible requirements and examples associated with various levels of the Genesis process in accordance with the present application.

[0026] [Figure 12] FIG. 12 shows an example flow of information associated with an initial biometric vector during the enrollment and authentication process.

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

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

[0029] [Figure 15] FIG. 15 illustrates an example of a role hierarchy according to the present application.

[0030] [Figure 16] FIG. 16 is a block diagram illustrating devices and transmission flows associated with replay prevention, according to an example implementation.

[0031] [Figure 17] FIG. 17 is a high-level flow illustrating steps associated with tokens according to an example implementation.

[0032] [Figure 18] FIG. 18 illustrates example devices and features associated with the Genesis process in a many-to-many relationship.

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

[0034] [Figure 19C] FIG. 19C illustrates example steps involved in expiring a user account.

[0035] [Figure 20A] FIG. 20A is a simplified diagram showing the steps involved in initializing, verifying, and validating a client certificate between a client device and a BOPS server.

[0036] [Figure 20B] FIG. 20B illustrates an example of client certificate registration associated with a third party server and a BOPS server.

[0037] [Figure 21] FIG. 21 illustrates an example QR code authentication flow according to an example implementation of the present application.

[0038] [Figure 22] FIG. 22 illustrates example apparatus and features related to an authentication process using a distributed ledger and an identity hub.

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

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

[0041] [Diagram 25]FIG. 25 is a simplified diagram illustrating the steps involved in registering a user with an identity provider.

[0042] [Figure 26] FIG. 26 is a flow diagram illustrating an example of a user gaining access to a resource using an authentication verifier.

[0043] [Figure 27A] FIG. 27A is a simplified diagram showing the steps involved in verifying a user identity with an identity verifier.

[0044] [Figure 27B] FIG. 27B is a variation of the simplified diagram of FIG. 27A showing the steps involved in verifying a user identity with an identity verification unit.

[0045] [Figure 28] FIG. 28 is an alternative simplified diagram illustrating the steps associated with verifying a user identity with an identity verifier.

[0046] [Figure 29] FIG. 29 is a flow diagram illustrating the steps associated with one implementation of verifying a user identity with the identity verifier system described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0047] By way of overview and introduction, the systems, methods, processes and computer products described herein are directed to and utilize a distributed biometric credential storage for digital representation of identity using a distributed ledger (e.g., blockchain). Currently, in the field of user identification, users are forced by centralized databases to give up personal information such as credit history, credentials such as birth certificates, or biometric data such as fingerprint templates to third parties. A novel distributed ecosystem for private and secure identity management implemented by several projects that replaces traditional identity proofing systems. To overcome this problem inherent in the use of identity information in various networks (e.g., the Internet), various approaches are described herein that allow end users to establish control over user identity data when establishing or participating in exchanges over networks other than the traditional centralized configuration.

[0048] In accordance with one or more implementations of the present patent application, a novel set of standards, generally referred to herein as Biometric Open Protocol Standards ("BOPS"), is provided which, when combined with a user-controlled authentication system, enables a framework for authenticating a user whose identity is secured by the user rather than by a 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] 1 illustrates an example hardware configuration 100 and displays data communications associated with one or more BOPS implementations. The deployment 100 may include one or more software applications that configure multiple computing devices, such as a client device (e.g., a smart phone or mobile device) 104, a server computing device (generally referred to herein as a "BOPS server") 102, a third party server 106, and an intrusion detection system ("IDS") that may include multiple computing devices 112, to support and enable the functionality shown and described herein. 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 separate devices.

[0050] The following is a non-exhaustive list of abbreviations and acronyms that may be referred to 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 = rapid read code; RDBMS = relational database management system; REST = representational state transfer; SSL = secure sockets layer; TCSEC = trusted computer system evaluation criteria; TEE = trusted execution environment; TPM = trusted 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] An advantage of the present application is that one or more individual BOPS implementations may include components that provide functionality and that may work with or replace existing components of an enterprise, thereby providing integration with the current operating environment within a relatively short time interval. Furthermore, one or more individual BOPS implementations provide a continuous form of protection, such as determining access to sensitive and private resources. In a BOPS implementation, it is possible to provide a service level of security that meets or exceeds acceptable objectives, at least in part as a function of one or more application programming interfaces (APIs) that support the implementation as a form of "point-and-cut" mechanism to add appropriate security to systems in development as well as to systems in production.

[0052] One or more BOPS implementations may include a BOPS server 102 that may receive a biometric vector, generally referred to herein as an initial biometric vector ("IBV"), from a client device 104a over one or more data communications networks, and algorithmically divide the vector into multiple portions associated with identities. Regardless of the number of portions, the IBV may be encrypted, for example, in a keyless manner, and subsequent biometric matching processing may optionally occur on the client device 104 or on the server 102, for example, as indicated by administrative parameters.

[0053] One or more BOPS implementations may be implemented in a variety of online environments, such as on a public cloud (eg, Amazon Web Services) or in a private cloud.

[0054] According to the organizational structure and functionality of the apparatus shown and described herein, authentication of a user may be provided in a manner such that, instead of authorization, the server maintains a sufficient amount of information to allow recognition of one client from another client rather than retaining client information. Elements of security considerations for one or more BOPS implementations may include identity assertion, role collection, access control, auditing, and assurance. That is, in one or more BOPS implementations, the server-side components are primarily considered in an end-to-end biometric solution.

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

[0056] Additionally, role aggregation is supported as a function of data confidentiality and privileged access, for example based on rules defined and / or enforced by known systems. For example, specific privileges associated with individual roles can be compared to group classifications to determine if a particular mode of access is permitted. The structure of an object can be defined by access control, and role aggregation can be done at the system level or via client / server calls. For example, the BOPS server 102 can store role aggregation information to associate a unique user with a unique device 104. Access control involves implementing one or more modules running on a computing device that determine whether a given subject (e.g., a person, device, or service (e.g., software program)) is authorized to access a given object and / or perform an action on a given object, such as read, write, execute, or delete.

[0057] In general, access control can be discretionary and can additionally or alternatively include mandatory access control, which can be more finely granular. Discretionary access control involves controlling access to one or more objects, for example, depending on designated users and designated objects (e.g., files and programs). The decision mechanism can be, for example, role-based and can allow users and administrators to specify and control sharing of objects by designated individuals and / or by defined groups of individuals. Discretionary access control mechanisms are provided in one or more implementations to protect objects from unauthorized access at a group level or individual level across a single object or a set of objects. That is, the granularity associated with discretionary access can range from individual to group.

[0058] One or more BOPS implementations may enforce mandatory access control policies for all subjects and storage objects (e.g., processes, files, segments, devices) under control within the scope of the individual implementation. These subjects and objects may be assigned sensitivity labels, which may be a combination of levels in a hierarchical taxonomy and categories in a non-hierarchical taxonomy. The labels may be used as a basis for mandatory access control decisions in adjudication. For example, software executing on a client device 104 may cause the device to maintain labels or cause the BOPS server 102 to maintain data to enforce compliance with subject and object labeling. The BOPS server 102 may maintain a trust store as a component of a BOPS implementation. As used herein, a trust store generally refers to storing data in a secure manner where access control (DAC or MAC) ensures that subjects receive the correct objects and also ensures non-repudiation and confidentiality.

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

[0060] The present application operates to increase accountability, for example as a function of one or more modules that provide auditing and verification that the security model is operational, generally referred to herein as assurance. In the unlikely event that a computing device within the scope of the BOPS implementation is compromised, such modules prevent undetected operation of the compromised system. For example, in a BOPS implementation, auditing of requests can be supported at the subject / object level or at the group level, as known in the art, for example as a function of aspect-oriented programming. This increases the likelihood that calls will be securely written to the audit trail. Additionally, RESTful web services and JavaScript Object Notation (JSON) interfaces can provide mechanisms to retrieve the audit trail. Auditing can be done on a subject per action, on an object per action, or on a group per action. For example, a group of users can be designated with a particular name (e.g., "accounting") and all writes to the general ledger can be audited. Additionally, it is possible to provide audit information to an individual, such as the head of finances, for example, to read the income statements.

[0061] In one or more BOPS implementations, boundary conditions can be tested and monitored using one or more of a series of JUnit tests, which can include testing boundary components and boundary conditions within the system. In one or more BOPS implementations, security provisions can be met, at least in part, as a function of APIs. The use of APIs eliminates the need to specify and / or customize a BOPS implementation to conform to an underlying system, such as a relational database management system, a search engine, or virtually any other architecture. The functionality provided by each BOPS implementation can provide a "point-and-cut" mechanism to add appropriate security to systems in development as well as systems in production. Additionally, the architecture of one or more BOPS implementations is language neutral, supporting, for example, REST, JSON, and SSL to provide communication interfaces. In one or more implementations, the architecture is built on the Servlet specification, OpenSSL, Java, JSON, REST, and a persistent store. Tools can adhere to open standards, allowing for maximum interoperability for devices, such as those shown in FIG. 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 a function of the combination of at least one specially configured client device 104 (e.g., a smart phone or mobile device), a BOPS server 102, and an intrusion detection system (IDS)-equipped device 112. In one or more implementations, the client device 104 executes an application to establish a secure initial communication session with the BOPS server 102 and loads a two-way Secure Sockets Layer ("SSL") / Transport Layer Security ("TLS") one-time key. The one-time key is at least functionally replaced by the subject's two-way SSL / TLS key that is generated and / or provided during the identity phase (generally referred to herein as "Genesis"). Genesis generally involves the initial or early step in the process of fusing a set of biometrics with a given subject. Another phase, generally referred to herein as Enrollment, includes steps associated with enrolling users and / or devices in a BOPS implementation and may include issuing certificates to client devices 104, protecting client certificates, and protecting sensitive data stored on the client.

[0063] In one or more BOPS implementations, an infrastructure is provided that handles data encryption and secure client / server communications. The BOPS infrastructure can support decoupling the Genesis and Enrollment processes and coordinating these processes together with various Enrollment elements. These dependencies can specify the BOPS server 102 infrastructure and can include BOPS DNS; BOPS TrustStore; BOPS KeyStore; and BOPS Key negotiation protocols. For certificate management, the DNS entry for the BOPS server 102 hostname can be configured to have a key in the keystore for one-way SSL. The TrustStore in one or more BOPS configurations is a two-way SSL mechanism that defines the certificate authority for signing all corresponding certificates. At the transport level, BOPS identity can be generated through a two-way certificate and truststore by performing a handshake. The key store facilitates transport level security via the keys in the key store, which may use well-defined and recognized certificate authorities, such as VERISIGN, GODADDY, or other authorities, that can be used to identify hosts for encryption over SSL / TLS. As described herein, one or more BOPS implementations use a one-time password (OTP) process from the client device 104 to request a password to unlock the two-way SSL certificate. This can be done by the client device 104 and server 102 synchronizing the OTP to return a key to unlock the certificate after the two-way SSL session has begun.

[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 authenticating the client certificate. For example, a token may be configured as an identifier that binds a profile on the server to an identity, such as a function of a data element that is the "Common Name". The OTP process includes one or more mechanisms that request a password from the server to unlock a two-way SSL (x.509) certificate. The password may be changed for each use by a predefined algorithm coordinated between the server computing device 102 and the client computing device 104, and the channel used for the 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. A different certificate may be used to obtain the password to unlock the personal certificate. In any event, this certificate unlocking mechanism may not involve storage of the password on the client device 104.

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

[0066] Client / server application interaction in a BOPS implementation can be considered a three-step process, with at least two possible variations following the initial first step. In such a case, the BOPS client / server application architecture is described herein with reference to three components: a client application running on a client device 104, an application running on a BOPS server 102, and a server-side application (referred to as an "application server" in the drawings). In the example shown in Figures 2-6, the server-side application does not necessarily go through the BOPS server 102, so the SSL / TLS connection can terminate at the application server. Also, the deployment of a particular BOPS implementation 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. The client device 104 then receives a certificate that is assigned by the BOPS server 102 and is specific to the client identity of the particular application.

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

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

[0069] The features shown and described herein with respect to the example BOPS implementation may be used by or in conjunction with the access control module provided herein, or may be added to the identity assertion elements of existing frameworks. That is, a BOPS implementation enables trusted processing by implementing minimal actions in a production environment, often eliminating the need to modify application software.

[0070] 7A shows the devices and steps 700 associated with an example enrollment process and associated data confidentiality according to one or more BOPS implementations. Two-way SSL / TLS, which in this application builds on one-way SSL / TLS, provides for communication initiated at the client device 104. The initial (e.g., Genesis) communication establishes the identity of the client 104 and may pass a BOPS-compliant two-way certificate along with a session-oriented identity assertion that the 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 allows subsequent Genesis operations.

[0071] According to 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 occurs via both one-way SSL / TLS and two-way SSL / TLS. In one or more implementations, the server 102 uses a data store to retrieve trusted identity information and collect roles for processing on behalf of individual identities. Additionally, auditing maximizes appropriate artifacts for ongoing verification and validation of trusted access. Assurance can occur as a function of the simplification and documentation of the multi-level access control mechanism. In one or more BOPS implementations, an administration console (hereinafter the "admin console") in a graphical user interface is provided following completion of the registration process, which allows for dynamic modification of users, groups, and roles, as described in more detail herein. An example of an admin console is shown in FIG. 7B.

[0072] 7A, a token request (RESTful) is sent from the client device 104 (1) and is received and verified by the BOPS server 102 (2). The DNS entry for the hostname of the BOPS server 102 may be configured to have a key in the key store (3), and the request is formatted (4A), and an m-token response is sent to the client device 104 via two-way SSL / TLS (4B). The client device 104 then sends a c-token (e.g., 5-tuple and timestamp) (5), which is verified, e.g., as a function of the m-timestamp in the request (6, 7). The missing 5-tuple is then determined (8) by comparison to the trust store, and the request is formatted (9), and a SHA512 token is sent to the client device 104 (10).

[0073] 7A, a registration request including a SHA512 token is sent from client device 104 (11) and received and verified by BOPS server 102 (12), and the client signature request is processed to unlock the certificate (13), such as by computing a one-time password and verifying the token count against a key store (14), and sending the client certificate password to an external notification service (15). The verification step of 12 further branches into steps related to analysis to determine device information (16), profile information (17), and biometrics (as shown and described herein) (18).

[0074] Additionally, the client device's certificate password is returned (19) to the client device 104, as well as the formatted request (2) and the SHA512 token (21). A custom security request, such as a SHA512 token, is then sent (22) from the client device 104, which is verified (23) by the BOPS server 102. The request is formatted (24) and the custom security response (e.g., the SHA512 token) is sent (25) to the client device 104.

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

[0076] In one or more BOPS implementations, visual cryptography is used to encrypt an initial biometric vector (IBV). This technique offers the advantage of fast reconstruction of the IBV, such as by using an XOR operation, on a particular device performing biometric matching. For example, a technique developed by Moni Naor and Adi Shamir, which provides a secret sharing scheme, can be used. In an example operation, a vector is split into N shares, so that all 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 can be split into two shares, one stored in a BOPS repository accessible by the BOPS server 102 and the other stored on the mobile computing device 104.

[0077] In one or more implementations of the present application, other forms of encryption methods and / or mechanisms for ensuring 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 example biometric authentication operation, both the newly acquired vector and the share of the registered vector may be available in one place (e.g., the mobile computing device application 104 or the BOPS server 102) or in multiple places. In any case, the share of the registered vector may be used to reconstruct the initial vector in memory, thereby assisting authentication to occur against that vector. FIG. 8 shows an overview of the enrollment process, including data access and exchange, associated with it. With respect to the BOPS server 102, identity is provided as a function of the subject's account and device. The subject's account and device are part of the profile information for a given subject. The profile information is stored in a clustered data store. For the match, the IBV is captured in the share, reconstructed, and decrypted. If the match algorithm is not capable of Euclidean match, the match is performed as plaintext, otherwise the match is performed in the encrypted domain.

[0079] An alternative implementation utilizes homomorphic encryption, which allows for computations to be performed on the ciphertext to produce an encrypted result. The matching operation is possible in the encrypted space, thereby increasing privacy and security. For example, the matching process can be performed in the encrypted space using one-way encryption, thereby providing a high degree of privacy and effectively eliminating the ability to obtain the IBV of the original plaintext.

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

[0081] In one or more implementations, Random One-Time Pad (ROTP) is used to perform one-way encryption that allows for matching in the encrypted space. Alternatively, for matching in the plaintext, visual cryptography is used for reversible encryption. For example, if there is no Hamming distance, visual cryptography is used to return to the plaintext for matching in memory. Preferably, one of two encryption algorithms is used for encryption and decryption: 1. Bitmask, or 2. Matrix transformation. Ideally, the server never has the IBV of the plaintext, since all matching algorithms will have the Hamming distance.

[0082] Below is an example algorithm for iris recognition implemented as a function that calculates the Hamming distance between two binary vectors, in which the matching process can be performed directly on each encrypted half of the biometric without converting them to plaintext, as follows (^ denotes a bitwise XOR operation):

[0083] The server stores:Enrol vector^noise

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

[0085] On the server, do the following comparison: (Enrol vector^noise)^(Verify vector^the same noise)

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

[0087] Since XOR is a self-inverse, (noise^the same noise)=I, where I is the identity factor for XOR, which is 0.

[0088] Therefore, the formula simplifies to: (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 the noizsed vectors is the same as the Hamming distance between the original vectors.

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

[0092] a) Registration vector:

[0093] 00110011

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

[0095] 01010101

[0096] c) The second half of the vector (calculated): stored on the phone

[0097] 01100110

[0098] During validation the following occurs:

[0099] e) Verification Vector: (only tell us the last bit that changed between enrollment and verification, since this is a good match).

[0100] 00110010

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

[0102] 01100110

[0103] f) Approximate the first half of the vector (e to c):

[0104] 01010100

[0105] During the match process the following occurs:

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

[0107] h) Currently, the server has:

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

[0109] 01010101

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

[0111] 01010100

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

[0113] 00000001

[0114] All the system can tell is the last bit that changed between enrollment and verification, which indicates a good match, but it knows how the server was only dealing with encrypted data, and that the actual vector is not known at the server, only the difference between the vectors can be calculated.

[0115] In an alternative implementation, face recognition is performed by calculating the Euclidean distance between template vectors, from which the face cannot be reverse engineered. When matching two face images, for example using a neural network, each face is first converted to a float vector of size 128 bytes. This representation of the float vector is arbitrary, but cannot be reverse engineered back to the original face. To compare faces, the Euclidean distance of the two vectors is calculated. Two faces from the same person should have similar vectors, and faces from different people should be further apart in Euclidean space. A verification vector can be calculated on the mobile device and sent to a remote server to be matched against a stored enrollment vector. Thus, the original biometric (e.g., face) never leaves the user's device, and all matching operations can be computed on the server.

[0116] In yet another implementation, fingerprint recognition is performed by calculating the Euclidean distance between template vectors, from which the fingerprint cannot be reverse engineered. Similarly, as described above, a neural network can be applied for fingerprint matching. In this case, the fingerprint can be converted to a vector on the device and the vector will be transmitted, thereby eliminating the possibility of recovering 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 and is used to obfuscate the output vector from the neural network. For example, encrypted biometric vector = encryption matrix x plaintext biometric vector. In this case, the encryption matrix transformation has the special property that the Euclidean distance is preserved, i.e., the matrix should be a rigid transformation. In this case, the biometric vector does not leave the device in unencrypted form, and the server compares the two encrypted biometrics to calculate the Euclidean distance without knowing the plaintext. If the user wants to perform verification from a new device, the user can send the 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] Thus, increased privacy is provided as a function of the biometric vector being split, stored, encrypted, and traversed between devices. No portion of the biometric vector resides on the server in plaintext form, either on disk or in memory. Additionally, analysis is enhanced in this application since users who wish to perform "what-if" analysis on individual authentications and failed authentications can do so via an administrative interface that supports facets, searches, analysis, etc.

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

[0120] Continuing with reference to FIG. 9, the persistent cluster 906 can include one or more database security groups and can be configured to auto-scale the BOPS data cluster. The authentication service can address large data objects and employ a big data store, such as NoSQL, and one or more horizontal partitions ("shards") of the data when dealing with large data sets, improving performance by reading from the shards simultaneously and merging the results. The database security architecture 900 implements a BOPS architecture to prevent the centralized storage of sensitive data in a single location. Also shown in FIG. 9 is a monitoring cluster 908, which can include an IDS device 112.

[0121] Figures 10A and 10B respectively show apparatus and steps for alternative enrollment processes 1000 and 1010 in accordance with one or more BOPS implementations. The implementations shown in Figures 10A and 10B provide mechanisms to store encrypted biometric data associated with an account or device, store information about any biometric data changes, load and use authentication services and their corresponding biometric libraries (e.g., FACE, 4F, IRIS), and provide API operations to support new flows (e.g., enrollment and authentication).

[0122] In the implementation shown in FIG. 10A, when the method for authentication flow is configured to occur on the client 104 side, a software application ("MCA") running on the mobile computing device 104 provides for obtaining an initial biometric vector (IBV), performing cryptographic splitting operations during the enrollment process and distributing this process to reduce CPU load on the server side, performing the enrollment request with the BOPS server 102, and performing cryptographic matching operations. The BOPS server 102 can be configured to store the user's identity data along with the share vector during the enrollment process, for example, in the BOPS big data store 1002. Additionally, the BOPS server 102 can manage the authentication flow and orchestrate the authentication service communication component (1004). The authentication service (1006) can dynamically load one or more authentication algorithms, biometric engine libraries, support authentication engine versioning, thereby normalizing communication between the BOPS server 102 and one or more biometric engines, provide authentication engine versioning support, and normalize communication between the BOPS server 102 and the authentication engines. The authentication service acts as a wrapper around the biometric service in performing authentication.

[0123] As described herein, one or more mechanisms for pluggable authentication services and their corresponding biometric engines are provided, such that a BOPS implementation is 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, for example the following list of enunciation services are available at the system level: 4F-Engine, FACE-Engine, IRIS-Engine, VOICE-Engine. The list of authenticators includes FIDO authentication or BOPS authentication.

[0125] The present application enhances the biometric integrated authentication service by supporting the following features: One or more mechanisms can be provided for storing encrypted biometric data within an account or device that is accessible by the BOPS server 102. Also, a mechanism can be provided for storing information representative of changes to the biometric data that have occurred. Additionally, a "generic" mechanism can be provided for accessing and using authentication services including those shown and described in commonly assigned U.S. patent application Ser. No. 14 / 201,462, U.S. patent application Ser. No. 14 / 201,499, U.S. patent application Ser. No. 14 / 988,833, and U.S. patent application Ser. No. 14 / 819,639, for example, associated with face, four finger, and iris biometric authentication.

[0126] In one or more implementations of the present application, the mobile computing device 104 obtains the enrollment vector and performs a cryptographic split operation during the enrollment process, which improves computational functionality by distributing the process and reducing the CPU load on the server side. Also, if the "biometric validation" step from the authentication flow is configured to occur on the mobile, the mobile device 104 can perform an enrollment request to the BOPS server 102 and perform a cryptographic match operation.

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

[0128] Other components provided in the architecture according to the present application may include one or more authentication services and one or more biometric engines. The authentication services may be configured to dynamically load one or more libraries configured to support versioning of the one or more authentication services, normalize communication between the BOPS server 102 and the authentication services, and provide one or more deployment scenarios, such as one or more BOPS instances being a web application machine that leaves or is another cloud that can be scaled by itself.

[0129] In one or more implementations, the biometric engine is configured to include unmanaged biometric libraries that are the subject of an interface and are defined and implemented by each individual library that wishes 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 free resources (e.g., memory, temporary files), a "GetStatus" to provide status information (e.g., INIT_FAILED, OK, ERROR, OUT_OF_MEMORY), a "Split" method to encrypt a vector obtained during enrollment, a "Match" method to authenticate a vector, e.g., based on a share of the initial vector, an "Activate / Register" method, and a description of the engine. The description may include, for example, a Biometric Type Identifier, a Name and Description, an Engine Version, and a Biometric Format. Using this information, one or more processes associated with this application may automatically load and register a particular biometric engine.

[0130] In one or more implementations, a mechanism is supported for pluggable authentication services that allows configuration to the system (location of authentication services) and automatically loads and registers available libraries to the system. Each biometric library, which is called by the authentication service, can provide information that describes itself, such as a constant sequence (type of biometric), individual version, name and description, etc. Furthermore, information such as the pair (type of biometric, version of biometric) can identify a unique biometric engine.

[0131] Exemplary authentication services and their corresponding lower level biometric engines may be listed and utilized at the system level, such as 4F, FACE, IRIS, and VOICE, and are shown and described, for example, in commonly assigned U.S. patent application Ser. No. 14 / 201,462, U.S. patent application Ser. No. 14 / 201,499, U.S. patent application Ser. No. 14 / 988,833, and U.S. patent application Ser. No. 14 / 819,639.

[0132] As described herein, in one or more BOPS implementations, the Genesis and Enrollment processes are effectively separated, allowing for determining a subject's identity without a direct requirement for the BOPS server 102 to access biometric vectors, certificates, or other sensitive information that would otherwise be required for automated processing. Thus, the BOPS solution can be construed as "open" and allows for virtually any customization in Genesis and Enrollment. For example, Genesis can include using a username and password to access an ACTIVE DIRECTORY, an email or text message for validation, or an organizational staff member to physically verify identity. Pre-registration of user accounts, which may occur in batches, for example, can be based on business requirements. Furthermore, the Genesis process can be fully dependent on risk management to determine further downstream processing. During an example post-Genesis process, users enroll their biometrics, which may include a unique client certificate being issued for each enrolled device. Additionally, a one-time password (eg, a "seed") may be established between the client device 104 and the server device 102, and an additional seed value may be used to prevent replay attacks.

[0133] It is recognized herein that a user may have many devices and / or a device may have many users (i.e., a device may have many biometrics). Thus, a many-to-many relationship may arise as a function of the separation of the Genesis and Enrollment processes. Thus, a subject identified via Genesis may be enrolled many times with 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 a well-defined subject.

[0134] Additionally, one or more BOPS implementations may have different levels of provisioning, which allows flexibility for different security levels. For example, a high level of Genesis may involve the user being physically validated in the presence of a person, such as an employee. Alternatively, a low level may simply involve the user defining a username and password along with a validation email that the user receives. The various levels of Genesis and validation process may be implemented according to one or more business decisions that may be unique or specific to one or more individual configurations. Also, subsequent processing may vary based on the individual Genesis level. For example, in a system, a transfer of $1,000,000 may be allowed at a high level of Genesis, but a transfer of $100 may only be allowed at a low level of Genesis.

[0135] FIG. 11 is a block diagram illustrating possible requirements and examples 1100 associated with various levels of Genesis in accordance with the present application. If more requirements are needed in the verification process, the individual security levels can be developed accordingly. In the example levels in FIG. 11, the first and second levels can be swapped based on organizational considerations. For example, if the purpose is to verify business visitors and provide Wi-Fi access, the verification can be sent via a mobile device and is considered a low verification level herein.

[0136] During the enrollment phase, for example, a mobile application running on the mobile computing device 104 will enroll biometrics based on its individual built-in capabilities. For example, a mobile application that is built for a particular integration and has required default biometrics may have a module specifically hard-coded for that in the application.

[0137] One or more BOPS implementations address the speed of biometric authentication transactions and address the problem of virtualization threats on mobile devices, such as an intruder attempting to decompile code on a copied virtual image of a mobile device and use this source code to stop authentication calls and take control of the servers that authenticate and establish authorization.

[0138] To mitigate these risks, a process in a BOPS implementation encrypts an initial biometric value (IBV) without an encryption key and then stores half of the IBV on the client device 104 and the other half on or otherwise accessible by the server 102. The biometric matching process may occur on the server 102. FIG. 12 illustrates an example 1200 of the flow of information associated with an initial biometric vector ("IBV") during the enrollment and authentication process. In the example flow illustrated in FIG. 12, during enrollment, the IBV is captured and split, and a portion (e.g., one half) of the IBV is stored on the client device 104. A portion (e.g., one half or one half) of the IBV is sent in the enrollment request to the BOPS server 102, where it is stored, for example, in a data store accessible by the BOPS server 102. Confirmation of the enrollment is then sent by the BOPS server 102.

[0139] Continuing with reference to FIG. 12, during a subsequent biometric authentication process, the current biometric vector ("CBV") is captured and sent, including the remaining portion (2 / 2), along with an authentication ("Auth") request to the BOPS server 102. The BOPS server 102 is configured to combine the received portion of the IBV in the authentication request and combine it with the stored portion of the IBV for decryption. It compares the received CBV with the plaintext of the entire IBV and returns a number (e.g., a floating point number) to the client computing device 104 depending on the decision during the comparison. If there is a match, the user may be registered as authenticated. Additionally, results may be of the authentication process and may be displayed on the client computing device 104.

[0140] That is, the present BOPS implementation, as illustrated by the steps shown in Figure 12 and described herein, addresses the speed of biometric authentication transactions and also resolves issues associated with virtualized threats on client devices that may arise, for example, after an intruder attempts to decompile software on a copied virtual image of, for example, a mobile device and use this source code to stop authentication calls and take control of the servers that authenticate and establish authorization.

[0141] To mitigate these risks, features of a BOPS implementation allow for the encryption of the IBV without an encryption key and for a portion (e.g., half) of the IBV to be stored on the client device and a portion (e.g., the other half) on the server or on a device accessible by the server. The biometric matching process can be performed on the server. In this way, an eavesdropped device cannot bypass the authentication, at least in part because a compromised device or server does not provide any useful information to an attacker.

[0142] According to one or more implementations, the following establishes a processing agreement for biometric authentication in one or more BOPS implementations: The biometric vector is split at least between the client and the server, making the approach to authentication independent of the type of biometric. For example, with face recognition, the size of the initial biometric vector may be around 20KB, which is to be minimized and accepted in upstream / downstream http-requests and http-responses. The splitting algorithm for IBV with face recognition may be as follows: zero bits are white and one bits are black. Thus, BOPS implementations can support visual cryptography (VC). As described herein, the present application can be used with virtually any biometric and provides a mechanism to obtain the IBV and encrypt it with VC. With VC, matching is done in the clear. Alternatively, with random, matching is done in the encrypted domain.

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

[0144] 12, following enrollment, biometric authentication occurs at the client computing device 104 (8) and a current biometric vector is captured (9). An authentication request is then sent over the transport layer (10), which is received by the BOPS server 102 and combined with the 2 / 2 IBV and used for decryption (11). The CBV is then compared (12) to the cleartext IBV and a floating-point number is returned (14) to the client 104, which displays the result (15).

[0145] Referring now to FIG. 13, an example 1300 of visual cryptography (VC) implemented with the present application is shown. VC provides good synergy with cryptography, splitting the IBV, and recovery of the IBV without the requirement for key management. In this visual cryptography example shown in FIG. 13, black can be equal to 1 and white can be equal to 0. In this example, the IBV is equal to 00100110. XOR recovery can be used since this solution is Boolean. The encryption process of the original biometric vector can be done using visual cryptography, and the result can be two vectors, denoted as sheets, containing only white noise. The mobile storage device (e.g., client device 104) contains one of the sheets, and the server device 102 contains or has access to the other sheet. The verification process combines the two sheets using simple Boolean operations, resulting in a fully recovered original biometric vector.

[0146] An example recovery of IBV with XOR operation is shown in Table 1 below.

[0147] [Table 1] Table 1

[0148] With reference to Table 1, and in conjunction with an example BOPS implementation, an encryption process of the original biometric vector may be performed using visual cryptography, and the result of this encryption is two vectors depicted as sheets containing only white noise. As described herein, storage associated with the client device 104 contains one of the sheets, and storage associated with the server device 102 contains the other sheet. A verification process combines the two sheets using simple Boolean operations, resulting in a perfectly restored original biometric vector.

[0149] Figure 14 shows an example of superposition of two shares (2,2) in visual cryptography (VCS) where each bit is encrypted into a share, associated with an example BOPS implementation. In the example shown in Figure 14, the selection of shares for zero and one bits is a random process. When encoding a zero or one bit, one takes a value from this table for one share and its neighbor in the table for the other share. At the end of the process, neither share provides any clue about the original bit. By superimposing the two shares (using OR or XOR), the value of the original bit is found.

[0150] Continuing with the example shown in FIG. 14, the superposition of two shares (2,2) is shown in visual cryptography (VCS) where each bit is encrypted into a share. Note that the selection of shares for zero and one bits can be performed in a random process. When encoding a zero or one bit, one takes a value from a table (e.g., Table 1) for one share and the value next to it in the table for the other share. At the end of the process, neither share gives any clue about the original bit. The value of the original bit is then found by superimposing the two shares, for example with OR or XOR. This is an example for a VCS of (2,2). VCS can be extended to more than two shares by changing the probability of the random process. Changing the probability of the random process from 0.5 to 0.25 results in a share with 4 bits instead of the 2 bits present in the 0.5 example. Furthermore, changing the probability of the random process to 0.125 results in an 8-bit encryption for each input bit.

[0151] With respect to finding a match, one or more modules in the example BOPS implementation take multiple initial biometric vectors. There are then two RESTful web service calls, one for each biometric, over SSL / TLS. One call includes half of the IBV, along with the current biometric in the authentication session, and can return a floating point value representing the strength of the match. The other call provides one IBV (half) at a time, plus the current biometric, and can return a floating point value representing the strength of the match. With respect to this second call, there can be several successive calls: e.g., one IBV at a time to determine a match.

[0152] A sizing calculation according to the agreement of an example BOPS implementation and associated matching process can be as follows: 20kb per face vector, 50 vectors for 10 seconds at 5 frames per second; 50 x 20kb = 1000kb.

[0153] An example of the logical calculations of the matching process associated with the implementation identified above is described as follows: Send the 1,000 KB to the server for matching. If there is no match, send the next 100 KB, 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 minimum threshold. According to an example matching algorithm, the current frame needs 200 ms plus 125 ms of up / down time to the server. That is, the frame transmission, together with the matching, makes the transaction rate 325 ms per frame. If the matching is bounded 100 ms higher, the frame transmission is approximately 425 ms. If it fails, a batch of frames (e.g., 5 at a time) can be sent and the matching can be attempted again. Preferably, the matching process takes less than one second, but in certain less favorable cases, the matching process can take longer, e.g., several seconds.

[0154] As shown and described herein, the flexible, authenticator and biometric type agnostic nature of the present application allows organizations to define individual authenticators and biometrics that can be used for authentication and can be defined as default biometrics. In the absence of a biometric description as part of a downstream transaction, a default biometric can be specified via one or more user interfaces, for example at the organization level, group user level, or transaction level.

[0155] In one or more implementations, the administration console can be configured with a graphical user interface and accessible to each authorized user. The administration console can include a graphical control that, when selected, results in configuration of a default biometric type. For example, one organization, ACME Plumbing, specifies that for certain accesses, the default biometric for all ACME employees is face. In yet another context, ACME Plumbing specifies that the biometric for all customers is four fingers, and in yet another context, specifies that all employee transactions over $10,000 are both four fingers and face. These options are presented in the administration console for ACME Plumbing's administrator to make the selection. In other words, the present application provides for flexible and dynamic application of one or more biometrics.

[0156] For authentication, multiple sources of biometric information may be used in a particular organizational setup, such as the condition engine, the member profile, and the member definition. The condition engine may be based on dynamic rules defined within the system. In one example, at least two forms of biometric verification are required for any transaction over $1,000. The member profile defines the user's role and corresponding privileges. For example, the member profile "Information Security--First Responder" may require authentication every 10 minutes or other conditions, such as per transaction engagement. The member definition may define default authentication at the organizational / integration level. For example, if there are four types of biometrics available in the system--4F, ​​FACE, IRIS--and for a particular BOPS / enterprise implementation, the default biometric is "FACE," then face authentication may be available as the default and may be provided as such, for example, in a dashboard provided via a graphical user interface and generally referred to herein as the BOPS Admin Dashboard. Additionally, individual conditions, such as those described above, may indicate priority. For example, the member definition can be considered to be the lowest priority and the condition engine can be considered to be the highest priority. The highest priority will be the authentication method.

[0157] The following describes example steps associated with the enrollment process according to the present 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, after biometric acquisition, the enrollment call to the BOPS server 102 includes one half of the IBV, which is stored for access at the server 102. The enrollment process can be used to initiate a BOPS implementation within an organization. While many of the descriptions and figures presented herein show a BOPS implementation appearing as a cluster, it is contemplated that BOPS can be configured as business components. Before a BOPS administrator ("BOPS admin") sets up an environment, the organization registers an individual API key from the BOPS server 102. Individual developers can similarly apply for 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 the various site admins, for example, and associated with individual API keys associated with the organization. In one or more implementations, API registration can involve two domains: the registered original site admin, and the issued API key, which can be based on the enrollment information, organization, and use case. After the application initiation is agreed upon, the registration process is complete. The BOPS admin may then create the original site admin for the organization, and the original site admin may create the site administrator (see, for example, the role hierarchy chart shown in FIG. 15).

[0159] Prior to any development process that utilizes BOPS services, a developer is preferably registered, 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 will be identified by the application name and associated with the application.

[0160] In one or more BOPS implementations, communications between applications running on client devices 104 and the BOPS server 102 are established over two-way SSL / TLS. Because the Genesis process establishes the connection and specifies how users identify themselves to the BOPS server 102, the server 102 can generate private keys to set up the two-way SSL / TLS communications. Providing a challenge question is one mechanism for a user to identify themselves, but this is an axiomatic approach and each party (e.g., a vendor) can provide a set of questions during the "Genesis" phase that uniquely describe the individual.

[0161] A client application running on a user computing device 104 is responsible for providing a unique identifier (ID) that identifies the end user's device 104. The application can use the device 104 and associated APIs to inform the BOPS server 102 of the association between the user and the user device 104. The 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 can be used by the system to counter attacks and attack vectors are identified. Additionally, types of requests that protect data in real time from known and unknown attacks can be identified and presented in the IDS (e.g., via device 112). For example, access can be validated using replay mitigation in cryptographic one-time tokens. In such cases, the IDS is a third tier that ensures that the server 102 is fully protected at the application layer by verifying that the client 104 and server 102 know each other.

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

[0164] The assumption in one or more BOPS implementations is that, for DDoS detection, all tokens should be distinct and at least one algorithm employed between the client and server takes into account that time may vary and that values ​​should differ not only between clients but also between accesses. FIG. 17 is a high-level flow 1700 illustrating the steps associated with the token algorithm 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 (1704) in an encrypted message from the client 104 to the server 102. The server 102 receives the token and checks the validity of the message by passing the token to the IDS (1706), which 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 product of Genesis / Enrollment and users / devices in a many-to-many relationship. On the mobile client 104, an identity element is shown linking with each account. On the server side of Figure 18, the BOPS server 102 is shown as associating identity attributes, accounts and devices associated with each identity. To facilitate data encryption and secure client / server communication with a high level of assurance, identity information is associated with a secure element through which user accounts (as an example, Alice's account or Bob's account shown in Figure 18) can be properly authenticated according to their corresponding identity.

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

[0167] Thus, in one or more implementations, the token does not contain the timestamp itself, but rather all values ​​in the token are converted to SHA512 sums for comparison. This changes the number to an interval for each minute value, preventing blind replay. Additionally, configuring the token's minute range to be 3 (and not 60) allows for large enough entropy (48,771,072) to prevent trial-and-error attacks.

[0168] Additionally, the semantic engine can be configured to allow security administrators to generate additional custom parameters for detection and prevention of attacks that may be outside of any international standard, providing further checks and counterbalances against a wide variety of attacks.

[0169] In one or more implementations, replay detection works off of the 5-tuple. Values ​​such as those shown in Table 1 above may be provided to the server 102. Alternatively, the server 102 may randomly select a value. Depending on the replay, the allowable range of values ​​and their entropy are first determined. If no value of the 5-tuple is identified during the Genesis step, the algorithm may use the following values:

[0170] [Table 2] Table 2

[0171] An example implementation performs a backwards rotation algorithm: if the respective month is less than or equal to the current month, the year can remain the same, or if the month is greater than the current month, the year needs to be rotated backwards. These two cases illustrate the algorithm.

[0172] [Table 3] Table 3

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

[0174] For example 2, where the same current date and time are used, the current month is 8 (August) and the month value in Genesis is 4, where 4<=8. The year is narrowed to the interval 5, which is equal to 2015. That is, the year becomes 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 of which may include encrypted biometric information to prevent a person from resetting and / or compromising the biometric information. One privacy level may stipulate that all non-biometric data is stored in plaintext (passivated). This simplifies reporting and analysis of usage patterns and authentication records, and may include other factors such as non-repudiation, location, date, and faceted search. For example, anyone may be relatively easy to see the number of failed authentication attempts in Cleveland during June 2016, and may be provided with information about individuals and devices. This first privacy level may be achieved as a function of sophisticated tools operating on the passivated data in plaintext. Another higher privacy level may stipulate that all non-biometric data is stored in encrypted form, but does not require a separate decryption key per client. That is, the client device 104 may be configured to use the same decryption key, which is considered more secure than the first privacy level described above, where insiders may not have access or will most likely not have access to the decryption key. An even higher privacy level may require that all non-biometric data be stored in encrypted form and that the decryption key be unique per identity. This increases privacy and isolation, since each user's data is encrypted with a key associated with a biometric. At the higher privacy levels, it is contemplated herein that user data, such as personally identifiable 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, in order to decrypt user data (e.g., login credentials, files, etc.), the user authenticates to authorize and authenticate the transaction.Additionally, data at rest (e.g., passivated data) is always encrypted on the server computing device 102 and on the client device 104. Clear data preferably only resides in memory at the time of the matching process.

[0176] One or more BOPS implementations provide an open platform that allows for virtually any customization of the Genesis flow. Some examples of Genesis may include a username and password to access an ACTIVE DIRECTORY, an email or text message for validation, or may physically verify an individual's identity, such as against a driver's license, birth certificate, passport, social security number, or other suitable credentials.

[0177] Pre-registration of user accounts can be done in a batch process that enforces business rules, and organizational policies and procedures can contribute to those business rules. Business rules can be integrated into an access management platform that groups users into groups or directories that determine the level of privileges and other attributes that will meet some specific needs in role management. This provides flexibility to developers to configure clear descriptions of member profiles (e.g., user profiles, admin profiles, manager profiles, and super-admin profiles) that can be applied as inputs to member definitions accessed by the BOPS server 102. The Genesis process according to the present application can be fully dependent on risk management and therefore determine downstream processing.

[0178] FIG. 19A shows the devices and steps 1900 associated with multiple users initiating enrollment on a single client device 104. The relationship between users and devices 104 can be "many-to-many" (M:M). A 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, IBV of user ID+1 / 2), A5, return enrollment). These steps can be repeated (B1-B5) for a second user. The many-to-many relationship can arise as a function of the separation of Genesis and Enrollment. Additionally, a subject identified via Genesis can be enrolled multiple times using multiple biometrics. To initiate client / server communication, a user captures their biometrics on the client device, which leads to an operational enrollment process for a unique client certificate issued to the client device. Once the security portion of the enrollment is complete, the user's biometric information has been properly registered, which concludes the enrollment process. 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 illustrates an apparatus and steps 1910 for initiating an authentication session from a client device 104 that stores information about multiple user accounts for an example user, Alice. In the example illustrated 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 causes the device 104 to send Alice's identity attributes over TLS. The BOPS server 102 then processes the authentication request given the integrity of the Enrollment element and returns a result (5).

[0180] According to the example shown in FIG. 19B, if Alice mistakenly initiates an authentication session using Bob's account, the client device 104 will not make any requests to the server because the CBV will be different from the IBV created during enrollment and authentication will not be successful.

[0181] FIG. 19C illustrates an example of the apparatus and steps 1920 for revoking a user's account. In the example illustrated in FIG. 19C, information related to three users (Eve, Bob, and Alice) is shown. One or more revocation rules can be defined by a user, for example, via an administrator console configured to include an administrative graphical user interface. A role associated with an administrator (who may also be biometrically authenticated) is responsible for enforcing the rules. In the example illustrated in FIG. 19C, Alice's account has a valid certificate, Bob's account has an expired certificate that is blocked at the transport security layer, and Eve's account has been disabled by a BOPS administrator. More specifically, after Eve's certificate is revoked via the BOPS server 102 (1), an authentication request is received from a client device 104 associated with Eve's account (2). The BOPS server 102 returns a message or other suitable content indicating that Eve's access has been blocked (3). For Bob's certificate, a 90 day period is provided after which Bob's certificate will expire ("TTL") (4). An authentication request is then received from a client device 104 associated with Bob's account (5), and as with Eve, a message or other suitable content is sent by the BOPS server 102 to the client device 104 indicating that Bob's access has been blocked (6). For Alice's account, an additional 90 day extension period is provided (7), and an authentication request is also received from a client device 104 associated with Alice's account (8). The BOPS server 102 returns a message or other suitable content indicating an authentication result that Alice has been authenticated (9), for example, as shown and described herein.

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

[0183] In one or more implementations, certificate distribution works as follows: An X.509 certificate is preloaded on the client device 104, for example, as a function of application software installed on the client device 104. Prior to the Genesis process, the client 104 establishes the 5-tuple values ​​by identifying any or all of the tuples (as shown and described herein). During the enrollment process, the client 104 issues a RESTful call requesting a token from the BOPS server 102. Once the token is received, it is embedded in the client's encrypted message to the server. The server receives the token and validates the message by ensuring that the difference between the creation time and the current time falls within a specified 60 second period. The server 102 determines which of the 5-tuple values ​​are missing and returns the token to the client in a RESTful format. The client 104 and server 102 share the same 5-tuple value, which is then used to calculate a timestamp that is SHA512 encoded and compared by the IDS, for example, as a function analysis. For example, as described herein, the calculated timestamp is unique per invocation, moving backwards in time based on the 5-tuple.

[0184] The present application allows for the configuration of the length of time (Time-to-Live or TTL) for client certificates to remain valid. Revoked certificates of authenticated users can be silently replaced with new certificates. That is, the TTL is a "belt and suspenders" approach that works in combination with IBV and CBV to help authenticate users. Token revocation can also be conditional on user role and other factors that contribute to the specific business needs for authorization. For example, a certificate can be blocked after 1 or x failed authentication attempts for financial transactions, e.g., if conditions y and / or z are not met.

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

[0186] Figure 20B illustrates a client certificate enrollment process 2010 in an example with third-party server and BOPS integration. The CSR process is shown generally, for example as shown in Figure 20A, and begins with user enrollment. In the example shown in Figure 20B, "Register a User Account" is used to describe the steps associated with Genesis and Enrollment, where the client certificate represents the identity attribute, while the account represents the identity component.

[0187] In the example implementation shown in FIG. 20B, the user initiates the enrollment process and sends his / her biometric information with the account registration request to the BOPS Server 102, which triggers the generation of a key pair / CSR in the client 104. Once the BOPS Server 102 receives the registration profile request, it further sends it to an access management adapter (which may be an access management solution / platform used by a third party company) as shown in FIG. 20B depicting profile validation, and then further sends it to a third party server for account login verification and validation. The third party server provides an authentication token after validating the login data, and then sends the validation result back to the access management adapter, which returns the authentication result and the 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 one example implementation integrated into an enterprise (e.g., a bank) that already has billions of accounts collected in its repository for advanced verification as a function of biometric authentication.

[0188] In one or more implementations, a rapid read code (QR code) can be used to trigger the execution of one or more modules shown and described herein. For example, a login page of a business partner (e.g., a bank) can be configured to display a QR code image containing an identifier for a particular session opportunity. An MCA running on a client computing device 104 can execute one or more modules (e.g., an authentication wizard) to scan the QR code and register the session with a signal attached to the session and authenticate with the user's biometrics according to the teachings herein. FIG. 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 in response, information that can be used for a new authentication session can be provided to the third party server by the BPOS server 102 and that can be provided (e.g., displayed) in the QR code. The third party server can send one or more requests for session status information. 21 (denoted as "Actor") scans a QR code to register a session with the BOPS server 102, which may be communicated to an external third party server. With biometric authentication as shown and described herein, a user session may 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 deposit sensitive biometric data with a third party. For example, a number of cryptographic shares (and potentially redundant shares thereof) as described with reference to FIG. 14 spread across selective off-chain storage (such as portable hard disk drives, mobile device storage, IPFS, Dropbox, Google Drive, AWS, etc.) are retrieved by the BOPS server. These cryptographic 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) allows for independent and platform-agnostic verification of a user's presence. 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 full control over this digital identity. Users can add more data to this digital presence, or invite others to add more information, or reveal some or all of the data depending on the context. Additionally, users can record their consent to sharing data with others and easily facilitate such sharing. That is, the digital identities described herein are persistent and portable, but do not depend on any single third party authorization or validation for their usefulness.

[0190] With particular reference 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 now to Figure 22, the Biometric Open Protocol Standard (BOPS) discussed herein is implemented in a distributed, secure user identity model, giving users control over the storage and use of their authentication and identity data.

[0191] In particular, those skilled in the art will appreciate that the described BOPS protocol can be extended 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 users control over authentication. The above description is merely for ease of explanation and is not intended to limit the integration of the BOPS standard and further approaches enabled by one or more distributed ledger technologies. Indeed, in one particular configuration, the BOPS standard allows off-device biometric credentials to be used to participate in authentication challenges and other network-based identity verifications. 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, such that cryptographically based assurances are provided that the biometric data is secure and tamper-resistant.

[0192] With continued reference to FIG. 22, a user 2200, such as an end user (or simply "user"), is someone who holds control over the user's individual identity and / or identity data. In one non-limiting example, the user 2200 is a student, employee, customer, and others. However, in alternative configurations, the user 2200 can designate an entity (e.g., the BOPS server 102) that maintains control over the user's individual identity and / or identity data. For example, an entity can be one or more services, businesses, or institutions authorized by the user 2200 to engage in identity-based transactions on the user's behalf. In one or more implementations, authorized entities include web services, mobile applications, or native applications that reside on or are accessible from the user's personal device (e.g., client device). As used herein, an entity generally refers to any entity that receives distributed identity information, accesses stored distributed identity information, and / or provides the distributed identity information to a resource access provider during a transaction for access to a resource. In one particular implementation, the BOPS server 102 described above is configured to act as a repository for various users 2200 .

[0193] Each user 2200 seeking to register with the access control platform or identity authorizer 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 the user identity. In one particular implementation, the 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 serves as a portable container or file for the biographic and biometric information. In one or more implementations, the DID document 2204 is a data file, container, code, or digital document that contains at least the metadata necessary to interact with a remote authentication system seeking to verify the user's identity. In a further example, the DID document 2204 is a 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 can include authentication and authorization information. In certain configurations, the DID document 2204 does not contain personally identifiable information (PII).

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

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

[0196] While any entity can be an issuer 2206, such as a repository, further examples of an issuer 2206 may include a business, a government, a non-profit organization, and / or an individual. In one or more configurations, the issuer 2206 sends the generated DID identifier 2202 and / or DID document 2204 to the repository. In a further implementation, the issuer 2206 sends the generated DID document 2204 to an identity hub 2208.

[0197] 22, a verifiable credential is generated and stored in a secure location for further use. The verifiable credential is stored, for example, in one or more identity hubs and repositories 2208, where the identity hubs and repositories 2208 are secure personal data repositories where the verifiable credential is stored and retrieved. For example, the identity hubs and repositories 2208 are one or more local or remote access data storage devices accessible to the user 2200, the repository 102, or the issuing unit 2206 to store, modify, or retrieve the verifiable credential. The identity hubs and repositories 2208 also relay or transmit messages and data to one or more verification units 2210. In one or more implementations, the identity hub 2208 is configured as a database or storage system, a flat file system, a relational database, or a bulk storage facility accessible by the user 2200 or the repository 102. For example, an identity hub can include Dropbox, Google Drive, AWS, Storj, and other similar "cloud" based storage facilities.

[0198] In a further arrangement, the issuer 2206 (or the repository 102) also generates a decentralized identifier (DID) 2202 that provides a reference to the DID document 2204, where the DID identifier 2202 is a unique identifier that allows the DID document 2204 to be searched or accessed without providing a third party with direct access to the personal information referenced by the verifiable credential. In one non-limiting implementation, the DID identifier 2202 is composed of unique bits, numbers, values, strings, or sequences that are at least in part the result of cryptographically hashing the user identity information contained within the DID document 2204. In a further implementation, the DID identifier 2202 is a text string, a numeric string, an alphanumeric string, or a hexadecimal sequence, or any combination thereof. Furthermore, such a combination 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 according to RFC3986. For example, the DID identifier 2202 consists of a sequence of unique strings followed by an optional path and / or fragment. For example, the issuer 2206 generates the DID identifier 2202 by hashing authentication information stored in the DID document 2202. In an alternative configuration, the DID identifier 2202 is a unique value that corresponds to a hashed value of the contents of the DID document 2204 and the storage location of the DID document 2204.

[0199] Upon generating the DID identifier 2202, 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 in the identity hub 2208. Instead, the DID identifier 2202 is stored as a transaction in the distributed ledger or blockchain. Storing the DID identifier 2202 in the distributed ledger as a transaction serves as an immutable record of the contents of the DID document 2204 as well as an immutable index of the DID document 2204 at the time of the generation of the DID identifier 2202. Because the DID document 2204 and the DID identifier 2202 are cryptographically bound, 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) wishing to verify the user's identity.

[0200] Without being limited 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 that tracks and stores digital transactions in a publicly verifiable and secure configuration to prevent fraud or modification to the underlying identity data. In one particular implementation, the blockchain or distributed ledger 2212 is a database configured as a public ledger configured to maintain an ever-growing list of data records, where entries in the ledger form a blockchain by recording and connecting the data records by using hashing. For example, each time a new transaction is added to the blockchain (e.g., a new DID identifier 2202), the new block contains the hash of the previous block. In this manner, each additional block creates further security regarding the validity of the entire blockchain. Each block records and verifies the sequence and timing of the transaction as it is generated and / or recorded. That is, in a particular implementation, the DID identifier 2202 is stored as a transaction on the blockchain. In a particular implementation, the repository or issuer generates a DID identifier 2202 upon receiving notification that a user (or repository) has provided information for registration with the authentication platform.

[0201] When a user 2200 seeks access to a protected resource, the checker / verifier 2210 (which controls access to the protected resource) requests a claim in the form of a DID 2202 from the user or a holder representing the user in order to allow the user 2202 access to the protected resource. The checker 2210 verifies that the credentials provided in support of the user's identity (e.g., DID identifier 2202 and in DID document 2204) are valid and verifies the validity of the DID identifier 2202 in the blockchain 2212. As non-limiting examples, the checker 2210 may include systems and servers maintained and provided by employees, security personnel, and websites.

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

[0203] In a further implementation, the captured biometric vector (IBV) is encrypted into at least two shares while remaining local to the user device 2300, as shown in step 2105. For example, the user device 2300 is configured to visually encrypt the IBV into two or more shares via encryption module 2305. At least one of the encrypted shares of the encrypted IBV is then stored on the local mobile device, as shown in step 2107. In one or more implementations, the user device 2300 generates a large 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 to store the encrypted shares via encrypted share storage module 2307 in one or more local memory devices of the user device 2300 for later retrieval.

[0204] 23, the user device 2300 is further configured to generate public and private keys via key generation module 2309. The user device then associates the public key with at least one share of the IBV, as shown in step 2109 of Figure 24. The public key and the encrypted shares associated with it are transmitted from the user device 2300 to the issuing server 2600A, as shown in step 2111.

[0205] Alternatively, in step 2013, the issuing server 2600A sends the encrypted share and public key along with issuing server signature data to the BOPS server 102, along with issuing server signature data, which may be any hash, code, cryptographic value, or data set that identifies issuing server 2600A as the source of the encrypted share and public key. For example, the issuing server signature data itself may be a public key or a public / private key pair, with the issuing server being the holder of the private key.

[0206] As previously described, the BOPS server 102 generates the DID document 2204 using both the encrypted shares and the public registration encryption key as well as the issuer data. For example, the BOPS server 102 is configured to generate the DID document 2204 by the DID generation module 2401 using the issuer signature, the registration public key and / or the encrypted shares as shown in step 2115. The DID generation module 2401 is further configured to generate a DID identifier 2202 for use with the DID document 2204. For example, the content and location of the DID document are used to generate a unique DID identifier 2202 value. The value may represent a hash of the DID document 2204 or some or all of the content of the DID document 2204 as well as a specific storage location, file reference, index number, or other data required to identify or locate the underlying DID document 2204.

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

[0208] Additionally, the BOPS server 102 is further configured by the DID persistence module 2405 to add the generated DID identifier 2202 to the selected blockchain 2212 for persistence. In this approach, the DID identifier 2202 provides a blockchain-agnostic method of resolving the DID document 2204. The DID persistence module 2405 configures a processor of the BOPS server 102 to generate and add a transaction block to an existing blockchain or distributed ledger. Alternatively, if no such ledger exists, the DID persistence module creates a distributed ledger and adds new transactions to the ledger. Those skilled in the art will recognize and understand additional functionality, such as hashing of transaction blocks.

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

[0210] Turning attention to further implementations of the described user registration system, FIG. 25 details the exchange of data and prompts between the user 2200 and the registration service provider 2600. For example, the user 2200 initiates the registration process using a mobile application client 2300. The mobile application client 2300 requests an IBV from the user 2200. For example, the mobile application client 2300 causes one or more imaging devices of the mobile computing platform to capture one or more images of the user 2200 who is to register with the service provider. As further shown in FIG. 25, the biometric vector can be converted into cryptographic shares. As shown in the implementation of FIG. 25, the biometric shares are converted using the mobile client application 2300. Of the shares generated from the IBV, one of the shares 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 cryptographic shares that are not stored locally on the mobile client.

[0211] The encrypted share and the public key of the registration key pair are sent to the service provider 2600 for registration. From there, the service provider 2600 provides an issuer signature (e.g., a public key from the service provider 2600), as shown with respect to the implementation of FIG. 25. The issuer signature, the registration public key, and the encrypted share are passed to the BOPS server 102, which acts as a repository for the user seeking registration. The BOPS server 102 uses the issuer signature, the encrypted share, and the public key to generate a DID document 2204. Once generated, the DID document 2204 serves as the basis for generating a DID identifier 2202 that is added to the specified compliant blockchain 2212. Once the DID identifier 2202 is generated and the corresponding DID document is stored in the blockchain, the DID identifier 2202 is returned to the mobile client application 2300, such that the user now has ownership of half of the encrypted IBV share and a copy of the DID identifier 2202.

[0212] It will be appreciated that while it is possible to store multifaceted data on the blockchain, such as biometric shares, the approach described herein does not store any personally identifiable information in 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 a reference to such "off-chain" data collection is placed within the public ledger system in the form of a cryptographically ordered DID identifier 2202. In this manner, the encrypted biometric shares generated in the registration process provided in Figures 24-25 remain within the encrypted envelope, but a reference to the encrypted shares is now available via the blockchain with the associated DID identifier 2202. In this manner, the DID identifier 2202 may be used as part of a claim of authentication using the same BOPS server 102 (as shown in Figure 23) or a different BOPS server that includes a validator. Here, such verification is possible because any changes in the stored DID document 2204 will become apparent when the transaction record of the DID identifier 2202 is accessed from the blockchain 2212.

[0213] 26, 27A and 27B, once the holder has associated the DID document 2204 and the DID identifier 2202 with their personal identity and provided the user with the DID identifier 2202, that information can be used to gain access to protected resources controlled by the verification server 2600B.

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

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

[0216] As part of the user's request, the user sends the service provider (verifier) ​​the DID identifier 2202 and the public key created in step 2109. In a further implementation, the user request also includes the issuer signature. The service provider (verifier) ​​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 issuance data, and the public key from the validating server 2600B.

[0217] Just as a URI uniquely characterizes a web resource by means of a URN and a URL, a DID identifier 2202 characterizes an associated DID document 2204 using one or more blockchain ecosystems. Here, the BOPS server 102 acts as a resolver for a given DID identifier 2202 that allows the repository (the BOPS server 102) to locate the corresponding DID document 2204. For example, the BOPS server 102 is configured by the DID resolution module 2407 to search for the received DID in one or more blockchains in step 2606 and identify the respective verifiable credentials from the "off-chain" storage by using the stored transaction information.

[0218] As described, in one or more configurations, the DID identifier 2202 and its corresponding DID document 2204 are cryptographically related to each other. In this way, any change in the DID document 2204 will cause the DID identifier 2202 to no longer be cryptographically consistent with 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 validation module 2409, whether the content of the DID document 2204 has been altered since 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 ends.

[0219] Once the BOPS server 102 has accessed 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 validation server 2600B. For example, the BOPS server 102 is configured by the claims validation module 2409 to compare the issuing department signature stored in the DID document 2204 with the issuing department signature sent by the user device 2300 via the validation server 2600. In a further configuration, the claims validation module 2409 also configures 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 stops and no authorization is established.

[0220] Alternatively, if the DID document 2204 is a valid claim, for example because the DID identifier 2202 and the DID document are cryptographically matched and the contents of the DID document 2204 match the issuer's cryptographic signature sent by the user device 2300, the BOPS server 102 is configured to determine, via the verification module 2411, whether the user can be authenticated.

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

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

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

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

[0225] A particular configuration of a resource access system is described, as shown in Figures 27A-B. Here, a user 2200 uses an MCA 2300 to access resources (e.g., banking information, social media accounts, etc.) from a service provider 2600. To request access, the MCA (acting on behalf of the user 2200) sends the user's registration public key, a DID identifier 2202, and an issuer signature, which in one implementation is the public key obtained from the issuer 2600 during the registration process provided in Figures 24 and 25. Upon receiving these user credentials, the service provider creates a session with the BOPS server 102, which acts as a repository for the 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 credential stored in the identity hub 2208 is accessed and returned to the BOPS server 102. In one or more configurations, the verified credential is an encrypted share (2 / 2) of the user's registered identity. The issuer signature stored in the DID document 2204 is evaluated and verified. Additionally, the user's supplied public key is verified against the public key stored in the DID document 2204.

[0227] Continuing with the configuration provided in FIGS. 27A-B, the BOPS server 102 sends a request to the MCA 2300 for a local copy of the encrypted IBV share and a signed challenge, where the signed challenge may be for the current biometric vector. For example, when the MCA 2300 receives the request from the BOPS server 102, the MCA prompts the user to obtain a biometric identifier and encrypt the biometric identifier with the private key of the enrollment key pair. The encrypted biometric identifier, the encrypted share, and the signed challenge.

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

[0229] Turning to FIG. 28, in one or more configurations, a user is authenticated remotely. Here, a new service provider (e.g., functioning as a verifier) ​​uses one or more BOPS servers 102 configured to authenticate the user 2200 via remote authentication module 2417 even if the user 2200 has never previously registered with the new service provider. In this configuration, the BOPS server functions as a repository. As shown with respect to the workflow of FIG. 28, authentication can be effectively performed using only the user 2200 and the validating server 2600. This configuration contrasts with and improves upon other "first instance" authentication, such as SAML or OAuth, which rely on a third-party identity provider (IdP) to claim the identity of the intermediary in traditional single sign-on (SSO) systems. Here, the configuration of elements provided helps ensure that a user who has control over the authentication data through the use of blockchain technology has one or more valid authority (e.g., issuer) issued credentials for subsequent use at the new service provider.

[0230] In one or more further configurations, a user (e.g., user 2200) may locally authenticate the user identity when requesting access to a protected resource for which the user has not previously registered. For example, the repository may access the issued claims, such as the encrypted biometric shares, on behalf of the user during authentication, but is required to perform the biometric authentication locally. As shown, the local configuration of the BOPS server 102 allows the combining of the biometric shares to be performed on the mobile device 2300. As shown in more detail with respect to FIG. 28, the portion of the biometric shares stored in or with the DID document 2204 is retrieved by resolving the DID identity 2202 referenced from the corresponding DID document 2204. However, unlike the workflow of FIG. 24, here the accessed biometric shares are sent to the client by the service provider and the corresponding BOPS server 102. In one particular implementation, the biometric shares sent to the user via the service provider and the BOPS server are not transparent to the service provider and the BOPS server. However, the server is provided with enough information to know to use the corresponding share on the mobile device (one of the biometric shares sent from the DID document 2204) in the matching process resulting from the HMAC of the encrypted second share. Note that the registered share is never sent to the device, but both shares are kept locally according to the BOPS local configuration. The mobile device must keep a private key associated with the share registered for the DID, because it uses the share to compute the HMAC and send the HMAC to the server. The server can compare the HMAC key to the non-obvious encrypted share from the DID document to provide access to the protected resource.

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

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

[0233] Each node of the respective distributed ledger (blockchain) decrypts the Euclidean quantifiable feature vector using a public key of the first public / private key pair to verify the validity of the Euclidean quantifiable feature vector, and each node is further configured to append the Euclidean quantifiable feature vector to the node's respective ledger 2212.

[0234] The described method further includes receiving a current biometric vector representing the encrypted biometric input record from the mobile computing device 2300 over the data communications network, as shown in step 2912. The received current biometric vector is provided to a neural network that transforms the current biometric vector into a current Euclidean metric feature vector, as shown in step 2914.

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

[0236] More specifically, each of the individual nodes of the plurality of distributed ledgers is configured to decrypt the current Euclidean metric feature vector using a public key of the second public / private key pair and validate the current Euclidean metric feature vector in step 2922. Additionally, each individual node is further configured to perform a lookup of at least a portion of the Euclidean metric feature vectors stored in the ledger using the current Euclidean metric feature vector. For example, as shown in step 2924, the biometric input record is matched with at least one biometric record as a function of an absolute distance calculated between the current Euclidean metric feature vector and each calculation of the individual Euclidean metric feature vectors in the portion of the ledger.

[0237] As used herein, a "processor" or a "computer" refers to one or more electronic devices (e.g., a semiconductor-based microcontroller) that execute a given set of instructions, which may be configured by code in the form of software. For example, the assessment server 102, the database 108, and the remote access device 104 include one or more processing or computing components that execute a commercially available or custom operating system, e.g., an implementation of a MICROSOFT WINDOWS, APPLE OSX, UNIX, or Linux-based operating system. In other implementations, the assessment server 102, the database 108, and the 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 a microcomputing component, an on-chip computer, a field programmable gate array, a graphical processing unit, a home entertainment console, a media player, a set-top box, a prototyping device, or a collection of "hobby" computing components. Such computing components as described may be directly or indirectly connected to one or more memory storage devices (memory) to form a microcontroller structure. The memory is a persistent or non-persistent storage device that functions to store an operating system for the processor as well as 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 fixable or removable, as known to those skilled in the art, such as through the use of removable media cards or modules, object oriented databases, hybrid relational object databases, key-value data stores such as HADOOP or MONGODB, in addition to other systems for structuring and retrieving data known to those skilled in the art. The database 108 includes the necessary hardware and software to enable a processor local to the content rating server 102 to retrieve and store data within the database 108.

[0238] Computer memory may also include secondary computer memory, such as a magnetic or optical disk drive or flash memory, that provides 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 when needed.

[0239] The described processor or computer may be configured to execute code written in a standard, custom, proprietary, or modified programming language, such as a standard set, sub-set, super-set, or extended set of 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 any other object-oriented, functional, or other paradigm-based programming language.

[0240] In one particular implementation, the 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, either directly or via a communication connection, with one or more remote access devices, such as, for example, a mobile phone, a tablet computer, a workstation, a desktop computer, or other computing components.

[0241] As provided in the illustrated implementation, the computer and processor are configured, by code executing thereon, to accept queried electronic data from one of a number of remote data storage locations (e.g., databases) and to evaluate the queried or accessed data according to predefined or dynamic rules, logic, instructions, or algorithms. The physical structure of the database may be realized as solid state 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. Additionally, 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, key-value data stores such as HADOOP or MONGODB, in addition to other systems for data retrieval and structure 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 the database or databases.

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

[0243] In one embodiment, the remote access devices, processors, and computers 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 devices, processors, and computers are custom or non-standard hardware, firmware, or software configurations. The remote access devices, processors, and computers can communicate with one or more remote networks using USB, digital input / output pins, eSATA, parallel ports, serial ports, FIREWIRE, Wi-Fi, Bluetooth, or other communication interfaces.

[0244] Although the present specification contains numerous specific implementations and details, these should not be construed as limitations on the scope of any configuration, arrangement, implementation or embodiment or the scope that may be claimed, but as descriptions of features that may be specific to a particular implementation or one or more specific embodiments. Certain features described in the present specification 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 separately or in any suitable subcombination in multiple configurations or arrangements. Furthermore, although each feature may be described above as functioning in a certain combination, and may even be initially described as such, in some cases, one or more features of the described combination may be removed from the combination, and the described combination may be reduced to a subcombination or a variation of a subcombination.

[0245] Similarly, although operations are shown in a particular order in the figures, this should not be understood as requiring that the operations be performed in the particular order shown, or in sequential order, or that all of the described operations be performed, to achieve desired results. 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 may generally be integrated together in a single software product or packaged in multiple software products.

[0246] The terms used herein are merely for the purpose of describing particular embodiments and are not intended to limit the present invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It is further understood that the words "comprise" and / or "comprising", as used herein, specify the presence of stated 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 terms, such as "first," "second," "third," etc., in the claims to modify a claim element does not in itself imply any priority, ranking, or order of a claim element relative to another or the chronological order in which the actions of a method are performed, but is merely used as a label to distinguish one claim element having a certain name from another claim element having the same name (but to use the original word). Also, the phraseology and terminology used herein are for purposes of description and should not be considered limiting. The use herein of "including," "comprising," or "having," "containing," "involving," and variations thereof, is meant to encompass not only the items listed thereafter and equivalents thereof, but additional items as well.

[0248] Specific embodiments of the subject matter described herein have been described. Other embodiments exist within the scope of the appended claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As an example, the processes depicted in the accompanying figures do not necessarily require the particular order depicted, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may be advantageous.

[0249] Throughout this application, references have been cited to publications and known trademarks depicting various systems, the disclosures of which are incorporated herein by reference. The citation of any of the above publications or documents is not intended as an admission of the adequacy of any of the foregoing as prior art, nor does it constitute any admission as to the contents or date of such publications or documents. All references cited herein, such as issued and pending patents and patent applications, are incorporated by reference to the same extent as if each individual publication and reference was specifically and individually indicated to be incorporated by reference.

[0250] While the present invention has been particularly shown and described with respect to preferred embodiments thereof, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention. Thus, the present invention is not defined by the discussion set forth above, but by the individual features recited in each of the following points, and by 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 being 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 crypto share; storing the first identity data set 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 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 respective 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 a 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, the processor being configured to: from a mobile computing device over a data communications network, an identity reference value associated with a first identity data set, said identity reference value being cryptographically associated with said first identity data set by resolving a storage location of said first identity data set, said 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 of a remote encrypted cryptographic share of an initial biometric vector of a 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 among a plurality of ledgers stored on each node, the transaction record including at least the identity reference value; determining a storage location of a corresponding first identity data set from the located transaction record; Accessing a cryptographically associated first identity data set; Verifying a signature value of the authorization system of the first set of identity data and a registration public key; receiving from the mobile computing device a current biometric vector and a local encrypted biometric cryptographic share; 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 a 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 quantifiable feature vectors.

6. 6. The system of claim 5, wherein the combined cryptographic vector is matched against 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 the Euclidean metric feature vector, 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 classification of the Euclidean quantifiable features and / or the current Euclidean quantifiable feature vector results in floating point values, and the Frobenius algorithm is utilized to calculate the absolute distance between each floating point and its mean.

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 classified hierarchy of Euclidean metric biometric vectors in time of order log(n); The system of claim 7 , further configured to identify the respective Euclidean quantifiable biometric vector as a current Euclidean quantifiable 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 rectifier linear layers (ReLUs) and pooling nodes.

14. The neural network is configured to use pooling as a form of nonlinear downsampling; 6. The system of claim 5, further comprising: one or more pooling nodes that progressively reduce a 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 respective Euclidean metric feature vector; The difference in relative positions is squared, Add up those values, 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 the spatial extent of the output quantity is calculated as a function of the extent 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 a plurality of 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 quantifiable feature vector with a private key of a first public / private key pair; encrypting the Euclidean quantifiable feature vector with a public key of a first public / private key pair; Distributing at least the encrypted Euclidean quantifiable feature vector and a public key of the first public key / private key pair among a plurality of ledgers stored on respective nodes, each of the respective nodes comprising: encrypting the Euclidean quantifiable feature vector with a public key of a first public / private key pair; Verify the validity of Euclidean metric feature vectors, and the distributing step adding a Euclidean quantifiable feature vector to each of the nodes' ledgers; 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 quantifiable feature vector with a private key of a second public / private key pair; encrypting the current Euclidean quantifiable feature vector with a public key of a second public / private key pair; Distributing at least the current Euclidean quantifiable feature vector and a public key of the second public key / private key pair among a plurality of ledgers stored on respective nodes, each of the respective 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 vector, and performing a lookup of at least a portion of the Euclidean quantifiable feature vectors stored in the ledger using the current Euclidean quantifiable feature vector; A method for matching a biometric input record with at least one biometric record as a function of an 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 quantifiable feature vector is validated as a function of decrypting the Euclidean quantifiable feature vector with a private key of the first public / private key pair and verifying that there is no modification of the Euclidean quantifiable feature vector by comparing the Euclidean quantifiable feature vector at each node with the decrypted Euclidean quantifiable feature vector.

20. Signing a Euclidean metric feature vector is generating a hash value associated with the Euclidean quantifiable feature vector; encrypting the hash value with a private key of a first public / private key pair; 20. The method of claim 18, wherein the hash value is decrypted by each of the individual nodes 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