Decentralized ID with user biometric authentication

Abstract

Systems, methods, and other embodiments for decentralized identity through user biometric authentication are presented herein. In one embodiment, the method includes, in response to a request by a computing device to access a resource of a cloud service provider, sending a request for a biometric private key to a mobile device associated with the user, in response to receiving the biometric private key, submitting the biometric private key for verification to a blockchain associated with the user and the mobile device, adding a record of the results of the verification to the blockchain, and controlling access to the resource of the cloud service provider based on the record in the blockchain by (i) denying access if the record indicates that the verification failed, and (ii) allowing access if the record indicates that the verification was successful.

Description

[Background technology]

[0001] background Multi-factor authentication (MFA) is an authentication method in which a user is granted access to a secure computing system or application only after presenting two or more "factors" to an authenticator. A factor is an item of evidence that confirms the identity of a user, such as a knowledge factor - something only the user knows, a possession factor - something only the user has, or a unique factor - something only the user is, a location factor - a location where only the user is, or any other factor that is uniquely associated with the user. One form of possession factor is a token device that generates a one-time password or passcode from a seed known only to the authenticator. This password can be a private key. The token device can be either (i) a disconnected token device that presents the one-time password to the user (e.g., on a display such as an LCD or LED 7-segment array) for later provision to the secure computing system as an authentication factor, or (ii) a connected token device that presents the one-time password directly to the computing system the user is using to access the secure computing system (e.g., via a USB or wireless interface) for later provision to the secure computing system as an authentication factor. One significant drawback of token devices is that users may not always be able to carry the token device with them when they need to access a secure computing system. To make matters worse, the token device may be damaged or malfunction, preventing the user from accessing the secure computing system. Also, the token device may be stolen from the user, allowing a malicious user to access the secure computing system. Furthermore, systems that generate passwords to verify the identity of a user before the user attempts to access a secure computing system reduce security by providing an opportunity for a malicious user to intercept and use the password between the generation of the password and the access attempt. Summary of the Invention [Means for solving the problem]

[0002] overview In one embodiment, a computer-implemented method is provided that includes, in response to a request by a computing device to access a resource of a cloud service provider, sending a request for a biometric private key to a mobile device associated with a user; in response to receiving the biometric private key, submitting the biometric private key for verification to a blockchain associated with the user and the mobile device; adding a record of the results of the verification to the blockchain; and controlling access to the resource of the cloud service provider based on the record in the blockchain by (i) denying access if the record indicates that the verification failed and (ii) allowing access if the record indicates that the verification was successful.

[0003] In one embodiment, the blockchain is maintained by the cloud service provider and each of the one or more other cloud service providers, and the computer-implemented method further includes controlling access to resources of the other cloud resource providers based on the records in the blockchain by (i) denying access to the resources of the other cloud service providers if the records indicate that validation failed, and (ii) allowing access to the resources of the other cloud service providers if the records indicate that validation was successful.

[0004] In one embodiment, the computer implemented method further includes generating a biometric private key by prompting the user to input biometric coordinates using the mobile device, receiving the biometric coordinates from a biometric input device of the mobile device, and generating the biometric private key from the biometric coordinates by the mobile device, and enrolling the user by submitting the biometric private key for inclusion as an initial record block in a blockchain associated with the user and the mobile device.

[0005] In one embodiment, where the recording indicates that the validation failed, the computer-implemented method further includes causing validation of any subsequent biometric keys submitted following the recording to fail, and requiring the user to re-enroll to create a new blockchain associated with the user and the mobile device before the user is allowed access to resources of the cloud service provider.

[0006] In one embodiment, the biometric private key is generated from one or more of fingerprint biometric coordinates, facial biometric coordinates, and retinal biometric coordinates.

[0007] In one embodiment, a non-transitory computer readable medium is provided having computer-executable instructions stored thereon that, when executed by at least a processor of a computer, cause the computer to: in response to a request by the computing device to access a resource of a cloud service provider, send a request for a biometric private key to a mobile device associated with a user; in response to receiving the biometric private key, submit the biometric private key for verification to a blockchain associated with the user and the mobile device, add a record of the results of the verification to the blockchain; and, based on the record in the blockchain, control access to the resource of the cloud service provider by (i) denying access if the record indicates that the verification failed and (ii) allowing access if the record indicates that the verification was successful.

[0008] In one embodiment, the blockchain is maintained by the cloud service provider and each of the one or more other cloud service providers, and the instructions further cause the computer to control access to the resources of the other cloud resource providers based on the records in the blockchain by (i) denying access to the resources of the other cloud service provider if the records indicate that validation failed, and (ii) allowing access to the resources of the other cloud service provider if the records indicate that validation was successful.

[0009] In one embodiment, the instructions include instructions for enrolling a user whereby the computer further performs the following: prompting the user to input biometric coordinates using a mobile device, generating a biometric private key from the biometric coordinates by the mobile device, and submitting the biometric private key for inclusion as an initial record block in a blockchain associated with the user and the mobile device.

[0010] In one embodiment, the instructions include instructions for generating a biometric private key, whereby the computer further performs the following: prompting a user to input biometric coordinates using a mobile device; receiving the biometric coordinates from a biometric input device of the mobile device; and generating, by the mobile device, a biometric private key from the biometric coordinates, wherein the biometric private key is an Advanced Encryption Standard (AES) key or a Rivest-Shamir-Adleman (RSA) key.

[0011] In one embodiment, a non-transitory computer-readable medium in which a federated identity provider acts as a peer, performs biometric private key validation, adds a resulting record to a blockchain maintained within the identity provider, and propagates the record to the cloud service provider and other cloud service providers for inclusion in copies of the blockchain maintained by the cloud service provider and other cloud service providers.

[0012] In one embodiment, a computing system is provided that includes a processor; a memory operatively connected to the processor; and a non-transitory computer readable medium operatively connected to the processor and the memory and storing computer-executable instructions that, when executed by at least the processor of the computer, cause the computing system to: in response to a request for access to a cloud service provider resource by the computing device, send a request for a biometric private key to a mobile device associated with the user; in response to receiving the biometric private key, submit the biometric private key for verification against a blockchain associated with the user and the mobile device, add a record of the results of the verification to the blockchain; and, based on the record in the blockchain, control access to the cloud service provider resource by: (i) denying access if the record indicates that the verification failed, and (ii) allowing access if the record indicates that the verification was successful.

[0013] In one embodiment, the blockchain is maintained by the cloud service provider and each of the one or more other cloud service providers, and the instructions further cause the computing system to control access to resources of the other cloud resource providers based on the records in the blockchain by (i) denying access to the resources of the other cloud service provider if the records indicate that validation failed, and (ii) allowing access to the resources of the other cloud service provider if the records indicate that validation was successful.

[0014] In one embodiment, the instructions include instructions for enrolling a user whereby the computing system further performs the following: prompting the user to input biometric coordinates using a mobile device, generating a biometric private key from the biometric coordinates by the mobile device, and submitting the biometric private key for inclusion as an initial record block in a blockchain associated with the user and the mobile device.

[0015] In one embodiment, the instructions include instructions for generating a biometric private key that further causes the computing system to: prompt a user to input biometric coordinates using a mobile device; receive the biometric coordinates from a biometric input device of the mobile device; and generate, by the mobile device, the biometric private key from the biometric coordinates.

[0016] In one embodiment, the instructions further cause the computing system to: store the blockchain in a cloud service provider's key store, perform validation of the biometric private key, add a resulting record to the blockchain in the key store, and propagate the record to other cloud service providers for inclusion in copies of the blockchain maintained in the other cloud service providers' key stores.

[0017] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate various systems, methods, and other embodiments of the present disclosure. It will be understood that element boundaries (e.g., boxes, groups of boxes, or other shapes) shown in the figures represent one embodiment of a boundary. In some embodiments, one element may be implemented as multiple elements, or multiple elements may be implemented as one element. In some embodiments, an element shown as an internal component of another element may be realized as an external component, and vice versa. Additionally, elements may not be drawn to scale. [Brief description of the drawings]

[0018] [Figure 1] FIG. 1 illustrates one embodiment of a computing system related to providing decentralized identity through user biometric authentication. [Diagram 2] FIG. 1 illustrates one embodiment of a method related to providing a decentralized identity through user biometric authentication. [Diagram 3] FIG. 1 illustrates one embodiment of a biometric private key generation method associated with providing a decentralized identity through user biometric authentication. [Figure 4] FIG. 1 illustrates one embodiment of a method for enforcing re-registration of a compromised user identity in connection with providing decentralized identity through user biometric authentication. [Diagram 5] 1 illustrates an exemplary mobile device configured and / or programmed with one or more of the systems and methods relating to providing decentralized identity through user biometric authentication described herein, and / or equivalents. [Figure 6] An exemplary computing system is illustrated that is configured and / or programmed as a special-purpose computing device with one or more exemplary systems and methods relating to providing decentralized identity through user biometric authentication as described herein, and / or the like. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] Detailed Description Described herein are systems and methods for providing decentralized identity using user biometrics. In one embodiment, the system and method for decentralized identity with user biometrics overcomes the shortcomings of possessive factor password generation mentioned above by forming a federated trust platform that uses a user's biometric coordinates, such as fingerprint, face or retina scan coordinates, to generate passwords (secret keys). The system and method described herein fulfills the need for a decentralized identity provider across cloud providers to provide multi-factor authentication using human biometrics.

[0020] In one embodiment, the federated trust platform is used to access secure computing systems, such as cloud systems, and establishes tighter integration between cloud providers through federated trust relationships. In one embodiment, a user computing device equipped with an input device capable of observing a user's biometric characteristics (e.g., a camera, a dedicated fingerprint scanner, a dedicated retinal scanner, a camera configured to take a retinal image, or other sensing device, collectively referred to herein as a biometric input device) is configured by software to function as a proprietary factor token device that generates a private key based on the user's biometric coordinates.

[0021] In one embodiment, the systems and methods described herein include an application, such as a mobile application, provided by an app store and downloadable to a user computing device, such as a mobile device with a biometric input device. When installed, the mobile application configures the user computing device to function as a token device, as described herein. A user is added to the system in an initial registration operation using the application. The system asks the user to provide a thumbprint, fingerprint, or retinal scan coordinate of the eye using the application. The user opens the application and registers their identity by placing their thumb or finger on a fingerprint scanner or placing their eye in front of a retinal scanner or camera (such as the camera of a mobile device). The app reads the user's fingerprint or retinal coordinate of the eye and generates a secret key.

[0022] After registration, when the user attempts to access a secure computing system, such as a cloud platform or cloud service provider, the secure computing system redirects the user request to a server of a federation trust platform configured according to the systems and methods described herein. The federation trust platform prompts the user to place their eye in front of a camera or use an application to scan their fingerprint to verify against a private key. Once the private key is verified, an authorization request is sent to the cloud provider.

[0023] A blockchain is a growing list of cryptographically linked records or blocks. A block typically contains transaction data, a timestamp, and a cryptographic hash of the previous block in the chain that verifies the integrity of the previous block. Blockchain allows for a shared digital ledger to record user transactions across multiple cloud providers. As user transactions are performed and verified, they are appended to the end of the blockchain, making it an immutable history of all valid transactions.

[0024] In one embodiment, the system and method described herein creates a blockchain network between cloud providers and a federated trust platform described herein. In one embodiment, the federated trust platform described herein acts as a master in a distributed certificate authority (CA) and multiple cloud providers act as slaves. Each slave cloud provider is added as a peer in the blockchain network. Each slave cloud provider obtains a root of trust certificate from the master and stores it in the cloud provider's keystore. The slaves (various cloud providers) only need a root of trust certificate from the master (the federated trust platform described herein). The master needs a root of trust certificate and address from each slave cloud provider to establish a closer trust relationship within the business network. The master's federated trust platform loads a network configuration file and a policy file and shares its policies to the slave cloud providers to receive partial ID block loads into the blockchain. When the distributed CA is initiated, a private key is distributed that is stored in each cloud provider's keystore system. In one embodiment, the private key is distributed as shards (portions of the private key), portions of which can be used to reconstruct the private key. For example, Amazon Web Services (AWS) cloud provider uses a Key Management Service (KMS) keystore to store private keys. Or, in another example, Microsoft Azure cloud provider uses a Keyvault keystore to store private keys. In yet another example, Oracle Cloud Infrastructure (OCI) uses a Java Keystore (JKS) to store private keys. The master federation trust platform then wraps the CA public key as a Certificate Signing Request (CSR) and adds the wrapped key to the partial identity block to form the initial or genesis block of the blockchain.The Master Federation Trust Platform then provisions each cloud provider with an intermediate certificate authority (ICA). Each cloud provider generates an ICA key pair, the ICA private key is stored in the cloud provider node's keystore, and the public key is wrapped as a CSR and shared with the Master Federation Trust Platform "out of band", or on a network (or network channel) separate from the primary network (or network channel). The Master Federation Trust Platform then provisions an identity user account for each cloud provider and generates a biometric identity key using a mobile application. The public key wrapped as a CSR is shared out of band with the master (e.g., the Federation Trust Platform). The master invokes a system smart contract (also known as a self-executing contract, where the contractual clauses are written as code that is executed when the contractual conditions are met) to register each of the cloud provider's ICACSRs and reconstruct and output the certificates.

[0025] The Master further calls the system contract to register each of the admin CSRs and output a certificate. The Master adds the certificate to the partial identity block. Each identity user at each cloud provider creates a public / private key pair for their cloud peer node. Thus, the private key is added to the node keystore, the public key is wrapped as a CSR, and each identity user calls the system smart contract to add the peer node. The function call is signed by the calling cloud provider's ICA using the user identity key (e.g., from a mobile app) to form a peer certificate. The calling cloud provider sends the peer certificate to the Master Federation Trust Provider for insertion into the blockchain's identity block. The identity block is finally processed and sent to the slave. The blockchain network for this user identity (combination of user and mobile device) is now active.

[0026] In some scenarios, a separate blockchain system may be deployed at each cloud provider to provide an identity solution (e.g., as shown and described with reference to the decentralized (and blockchain-based) biometric ID component 125 of FIG. 1). Each blockchain system may create a business network archive (blockchain network) between the cloud provider, the enterprise, and the enterprise identity provider. In another embodiment, multi-cloud identity may be provided by an interoperable blockchain architecture that combines distinct blockchain systems at each of the cloud providers. In such an interoperable blockchain architecture, each blockchain system represents a distributed data ledger, execution of cloud identity transactions may span multiple combined blockchain systems, and data recorded in one blockchain is reachable and verifiable from another, possibly external, transaction in a semantically compatible manner.

[0027] In other embodiments, a mobile application that interfaces with the blockchain system may be provided for download. For example, a user of the blockchain system downloads the mobile application from an app store. When registering a user with the system, the invention requires the user to provide biometric information, such as a fingerprint, face, or eye retina scan coordinates, using the mobile app. The user opens the app and registers their identity by placing a finger on the screen or showing their face or eyes in front of the mobile device near the camera. The app reads the user's fingerprint or eye retina coordinates, generates a private key, and registers with the blockchain platform using the private key. When the user accesses the cloud platform, the cloud platform redirects the user's request to the blockchain platform to verify the user's identity, and the user opens the mobile app and provides the fingerprint, face, or retina scan coordinates to authenticate with the blockchain platform. In response to a prompt by the mobile application, the user presents the user's fingerprint, face, retina, or other biometric identifier to the mobile device for verification against the user's private key stored by the blockchain platform. If the biometric identifier is a fingerprint, the user places their fingerprint on a fingerprint reader and the fingerprint is read for verification. If the biometric identifier is face, the user places their face in front of a camera and records their face for verification. If the biometric identifier is retina, the user places their eye in front of (and near) a camera and records their retina for verification. The blockchain platform compares the user's identity by verifying their fingerprint or retina scan with a private key generated based on the fingerprint or retina scan. Once the private key is verified, the blockchain platform sends the request to the cloud provider for authorization.

[0028] The acts or functions described or claimed herein are not performed by the human mind, and any interpretation that any act or function can be performed within the human mind is inconsistent with and contrary to the present disclosure.

[0029] -Example environment- FIG. 1 illustrates one embodiment of a computing system 100 related to providing a decentralized identity through user biometric authentication.

[0030] In one embodiment, the system 100 includes multiple cloud service providers, such as cloud service provider 1 105 to cloud service provider n 110, connected to an enterprise network 120 by a network 115 (such as the Internet, other suitable communication network, or combination of networks), and a mobile device 125 configured as a biometric token device. Optionally, a dedicated federated identity provider 130 may also be connected to the cloud service providers 105, 110, the enterprise network 120, and the mobile device 125 via the network 115. In one embodiment, the cloud service providers 105, 110 may be Oracle® Cloud Infrastructure (OCI), Amazon Web Services (AWS), Microsoft Azure, Google Cloud, Alibaba Cloud, IBM Cloud, Salesforce, SAP, Rackspace Cloud, VMWare, or other cloud computing systems configured to execute the methods for providing a decentralized user identity with user biometric authentication as shown and described herein. Each of the cloud computing systems such as those listed above may be improved by configuring a decentralized identity to be coupled with a user biometric authentication system to provide a decentralized federated identity with multi-factor authentication based on user biometrics enabled by the systems and methods described herein. This allows various cloud providers to share a common federated identity service based on user biometrics. In one embodiment, the cloud service provider 105, 110 includes various systems and components including a decentralized biometric identity component 135, other cloud service components 140, a data store 145, and a web interface server 150.

[0031] In one embodiment, the decentralized biometric identity component 135 (and any dedicated federated identity provider 130) includes one or more components configured to implement the methods, functions, and features described herein in connection with providing decentralized identity through user biometric authentication. The decentralized biometric identity component 135 may include a trust component 153 configured to generate, communicate, and evaluate trust information for registering cloud providers as blockchain peers according to the systems and methods described herein, and a validator 155 configured to analyze, inspect, and approve or reject biometric keys associated with requests to access resources of the cloud service provider for inclusion in the blockchain 160. The trust component 153 may include an intermediate certificate authority (ICA). The blockchain 160 may be stored as a data structure data store 145.

[0032] A blockchain 160 is a form of distributed digital ledger that consists of record data structures called blocks. In a blockchain, each block is sequentially linked to the previous block in the blockchain by a cryptographic hash that links the previous block back to the initial or "genesis" block. Blocks are automatically added to the blockchain by validators (such as validator 155) when they are successfully "validated" or found to satisfy the rules of a smart contract that governs the block's inclusion in the blockchain. The validation rules vary depending on the blockchain's application. Blockchains are tamper-evident because for a block in the blockchain to be able to be retroactively changed, all subsequent blocks in the blockchain must also be changed. Blockchains can be public, with no access restrictions for participation or validation; or private, with participation and validation limited to entities with appropriate permissions. Blockchains are maintained by participating peer computing systems connected through a network, with a copy of the blockchain stored by each peer.

[0033] In one embodiment, each of cloud service provider 1 105 through cloud service provider n 110 and dedicated federated identity provider 130 is a member of federated identity group 165. Each of cloud service provider 1 105 through cloud service provider n 110 and dedicated federated identity provider 130 is configured by decentralized biometric identity component 135 to operate as a blockchain peer in accordance with the systems and methods described herein. In one embodiment, each individual blockchain in blockchain 160 is configured to represent cloud computing service authorization activity for a particular two-factor user and mobile device combination as shown and described herein. For example, a genesis block in the blockchain is configured to represent authentication contingent on presentation of a suitable biometric private key, and subsequent blocks in the blockchain are configured to represent an access request and the success or failure of validation of the biometric private key presented with the access request. The validator 155 is configured to include and execute smart contract rules to determine whether the biometric private key submitted with the access request is valid, as shown and described herein, and to add a block to the blockchain indicating the validity or invalidity of the submitted private key.

[0034] In one embodiment, the federated identity provider 130 is configured to integrate multiple cloud service providers into a federated identity group 165 that uses blockchain to manage identities in a decentralized manner. In one embodiment, the federated identity provider 130 is a standalone system separate from the cloud service providers in the federated identity group 165. In one embodiment, the federated identity provider 130 is part of one of the cloud service providers in the federated identity group 165. As shown and described herein, the federated identity provider may also include a validator 155 and a blockchain 160, a cloud service provider registration component 161 configured to register cloud service providers as peers in the federated identity group, and a user registration component 163 configured to register user identities for accessing the cloud service providers. In one embodiment, the federated identity group 165 implements a private or permissioned blockchain, so that the federated identity provider 130 manages the initial registration of blockchain peers (cloud service providers) and the initial registration of user identities. After registration, the peers maintain a blockchain of access transactions for each user identity.

[0035] In one embodiment, a biometric token application 127 is installed on the mobile device 125. The biometric token application 127 configures the mobile device 125 to operate as a token device that generates a user-specific secret key based on the user's multi-factor authentication possession factor, i.e., biometric input from the user. In one embodiment, the biometric token application 127 includes a fingerprint coordinate generator 191 configured to receive scanned fingerprints 192 from the fingerprint scanning hardware of the mobile device 125 and convert them into mathematical coordinates that describe the scanned fingerprints 192. In one embodiment, a retina coordinate generator 193 of the biometric token application 127 is configured to receive images of a retina 194 from the camera of the mobile device 125 or a dedicated retina scanner and convert them into mathematical coordinates that describe the imaged retina 194. In one embodiment, the biometric token application 127 includes a face coordinate generator 195 configured to receive images of a face 196 from the camera of the mobile device 125 and convert them into mathematical coordinates that describe the scanned face 196. In one embodiment, the mobile device 125 has only one of the fingerprint coordinate generator 191, the retina coordinate generator 193, and the face coordinate generator 195. In one embodiment, the mobile device has one or more of the fingerprint coordinate generator 191, the retina coordinate generator 193, and the face coordinate generator 195. In one embodiment, the biometric token application 127 includes a biometric private key generator 197 configured to obtain biometric coordinates generated by at least one of the fingerprint coordinate generator 191, the retina coordinate generator 193, and the face coordinate generator 195 and convert the coordinates into a private key token. The biometric token application 127 can cause the mobile device 125 to transmit the generated biometric private key to the validator 155 or the user enrollment component 163 over the network 115, for example, in response to a request for a private key received by the mobile device 125.

[0036] Each of the components of cloud service provider 1 105 through cloud service provider n 110, the dedicated federated identity provider 130, the mobile device 125, and the computing device 180 is configured by logic to perform the functions that the component is described as performing. In one embodiment, the components may each be implemented as a set of one or more software modules executed by one or more computing devices specifically configured for such execution. In one embodiment, the components of cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130 are implemented on one or more hardware computing devices or hosts interconnected by a data network. For example, the components of cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130 may be executed by networked computing devices of one or more computing hardware configurations, such as central processing unit (CPU) or general purpose configurations, high density input / output (I / O) configurations, graphics processing unit (GPU) configurations, and high performance computing (HPC) configurations. In one embodiment, the components of cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130 are each realized by one or more dedicated computing devices. In one embodiment, some or all of the components of each of cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130, although depicted as separate units in Figure 1, are realized by a common (or shared) computing device. In one embodiment, the components of cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130 may be realized across multiple computing devices.In one embodiment, each of cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130 may be realized as a service on a cloud infrastructure. In one embodiment, cloud service provider 1 105 through cloud service provider n 110 and the dedicated federated identity provider 130 may each be hosted by a dedicated third party, such as in an Infrastructure as a Service (IAAS), Platform as a Service (PAAS), or Software as a Service (SAAS) architecture.

[0037] In one embodiment, the components of computing system 100 communicate with each other by electronic messages or signals. These electronic messages or signals may be configured as calls to functions or procedures that access features or data of the components, such as, for example, application programming interface (API) calls. In one embodiment, these electronic messages or signals are transmitted between hosts in a format compatible with Transmission Control Protocol / Internet Protocol (TCP / IP) or other computer networking protocols. Computing system 100 may (i) generate or configure electronic messages or signals to issue commands or requests to another component, (ii) transmit messages or signals to other components of computing system 100, and (iii) analyze the content of received electronic messages or signals to identify commands or requests that the components can execute, and in response to the identification of the commands, the components may automatically execute or perform the commands or requests.

[0038] The API calls may include queries to a database, which may be formulated and executed in a query language compatible with the database and executed in a runtime environment compatible with the query language.

[0039] In one embodiment, data store 145 is a computing stack for structured storage and retrieval of one or more collections of information or data in a non-transitory computer-readable medium, for example as one or more data structures. In one embodiment, data store 145 includes one or more databases, including a blockchain 160 database configured to store and provide blockchain data, or other databases configured to store and provide other information used by the cloud service provider. In one embodiment, blockchain 160 is maintained in a key store of each cloud service provider 105-110. A key store, such as a JKS, KMS key store, Keyvault key store, etc., is a repository of the cloud service provider's security credentials. In one embodiment, blockchain 160 of access attempts may be stored and updated or otherwise maintained from time to time in the cloud service provider's key store. In one embodiment, the database used herein is an Oracle® database. In some exemplary configurations, data store 160 may be realized using one or more Oracle® Exadata computing shapes, network attached storage (NAS) devices, and / or other dedicated server devices.

[0040] The enterprise network 115 may be associated with a company or other enterprise. For simplicity and clarity of explanation, the enterprise network 115 is represented by one or more personal computers 145 or servers 150 (such as computing devices 180) operatively interconnected. Each personal computer 145 is typically dedicated to a particular end user, such as an employee or contractor associated with the business, although such dedication is not required. The personal computers 145 and remotes may be, for example, desktop computers, laptop computers, tablet computers, mobile devices (such as smartphones, tablet computers, mobile phones, or other handheld portable computing devices), or other devices capable of connecting to the enterprise network 120 or network 115 through wired or wireless connections.

[0041] A computing device (e.g., computing device 180) in enterprise network 120 may include a cloud connectivity application 185 that utilizes multiple cloud service providers in federated identity group 165. Cloud connectivity application 185 may interface with cloud service provider 1 105 through cloud service provider n 110 via Internet 115 (or another suitable communications network or combination of networks). In one embodiment, a remote computing system (e.g., a system in enterprise network 115) may access information or applications provided by cloud service provider 1 105 through cloud service provider n 110, and dedicated federated identity provider 130, via a web interface, such as web interface server 150. In one embodiment, the remote computing system may send requests to and receive responses from web interface server 150. In one example, access to the information or applications may be achieved through the use of a web browser running on computing device 180 or other computer in enterprise network 120. The web browser may be configured to display a graphical user interface for requesting access to cloud services of the cloud connectivity application 185 and display instructions for generating a biometric private key in association with the access request using the mobile device 125 as shown and described herein. In one example, communications may be exchanged between the web interface server 150 and the computing device 180 and may take the form of, for example, Remote Representational State Transfer (REST) ​​requests using JavaScript Object Notation (JSON) as the data exchange format, or Simple Object Access Protocol (SOAP) requests to and from an XML server.

[0042] -An example of a distributed biometric ID access control method- In one embodiment, each step of the computer-implemented methods described herein may be performed by a processor of one or more computing devices (such as processor 610 shown and described with reference to FIG. 6) configured with (i) memory (such as memory 615 and / or other computing device components shown and described with reference to FIG. 6) and (ii) logic that causes the system to perform the method steps (such as distributed biometric user ID logic 630 shown and described with reference to FIG. 6). For example, the processor accesses and reads and writes to memory to perform the computer-implemented method steps described herein. These steps may include (i) obtaining necessary information, (ii) calculating, determining, generating, classifying, or otherwise creating data, and (iii) storing the calculated, determined, generated, classified, or otherwise created data for later use. References to storage or memory refer to storage as a data structure within the memory or storage / disk of a computing device (such as the memory 615, storage / disk 635 of the computing device 605 or remote computer 665 shown and described with reference to FIG. 6, or the data store 145 shown and described with reference to FIG. 1).

[0043] In one embodiment, each subsequent step of the method is initiated automatically in response to analysis of a received signal or acquired stored data indicating that the previous step has been performed at least to the extent necessary for the initiation of the subsequent step. Typically, the received signal or acquired stored data indicates completion of the previous step.

[0044] FIG. 2 illustrates one embodiment of a method 200 relating to providing a decentralized identity through user biometric authentication. In one embodiment, the steps of method 200 are performed by a decentralized biometric ID component 135 (shown and described with reference to FIG. 1). In one embodiment, the decentralized biometric ID component 135 is a dedicated computing device (such as computing device 605) configured with decentralized biometric user identity logic 630. In one embodiment, the decentralized biometric ID component 135 is a module of a dedicated computing device configured with logic 630. In one embodiment, the steps of method 200 enable biometric multi-factor authentication across members of a federated identity system that previously could not be performed by a computing device. Additionally, the system enables real-time biometric multi-factor authentication across members of a federated identity system, with the biometric private key being generated only at the time of an access request, enhancing security and eliminating the opportunity for a malicious party to intercept the biometric private key.

[0045] Method 200 may be initiated automatically based on various triggers, such as in response to receiving a signal over a network or analyzing stored data indicating: (i) a user (or administrator) of system 100 has initiated method 200; (ii) method 200 has been scheduled to begin at a defined time or time interval; (iii) a user (or administrator) of system 100 has initiated a request to access resources of a cloud service provider (e.g., cloud service provider 105); or (iv) a request to access resources of a cloud service provider has been received from a cloud client (e.g., computing device 180). Method 200 begins at start block 205 in response to analyzing a received signal or acquired stored data and determining that the signal or stored data indicates that method 200 should be initiated. Processing proceeds to process block 210.

[0046] At process block 210, in response to a request by the computing device to access a resource of a cloud service provider, the processor sends a request for a biometric private key to a mobile device associated with the user.

[0047] In one embodiment, a cloud service provider (e.g., cloud service provider 1 105) receives a login request associated with a user that, if authorized, allows a computing device (e.g., computing device 180) associated with the user to utilize one or more computing services provided by the user. The cloud service provider is configured by a decentralized biometric ID component (e.g., decentralized biometric ID component 135) to require an additional authentication factor of a biometric private key before the login request is approved and access is granted. The cloud service provider retrieves an identifier for a mobile device associated with the user, for example, by reading the identifier from a genesis block of a blockchain (e.g., a blockchain stored in blockchain 160) of an access request associated with the user. For example, the identifier may be a phone number, a network address, a media access control (MAC) address, a mobile identification number (MIN), or other identifier that uniquely identifies the mobile device and enables routing of information to the mobile device. The cloud service provider generates a request for a biometric private key (a message configured to cause an application on the mobile device to initiate generation of a biometric private key). In one embodiment, the message includes routing information to the mobile device and an API request to the application on the mobile device. The cloud service provider then sends a request message over a network (such as network 115) to the mobile device, causing the mobile device to begin the process of generating a biometric private key. The cloud service provider then waits for a message from the mobile device that includes the biometric private key.

[0048] Thus, once the processor has completed sending a request for the biometric private key to the mobile device associated with the user in response to the computing device's request for access to resources at the cloud service provider, processing at process block 210 is complete and processing proceeds to process block 215.

[0049] At process block 215, in response to receiving the biometric private key, the processor submits the biometric private key for validation to a blockchain associated with the user and the mobile device.

[0050] In one embodiment, the cloud service provider receives the message from the mobile device and parses it to identify the biometric private key. In one embodiment, the message includes an X.509 certificate that includes the biometric private key. In one example, the biometric private key is used as a signature for the X.509 certificate. The cloud service provider extracts the biometric private key from the message. The cloud service provider then generates a request (e.g., an API request) to a validator (e.g., validator 155) to validate the biometric private key. The cloud service provider presents the validation request along with (or including) the biometric private key to the validator.

[0051] Once the processor, in response to receiving the biometric private key, completes submitting the biometric private key for verification to the blockchain associated with the user and mobile device, processing of process block 215 is complete and processing continues to process block 220.

[0052] At process block 220, the processor adds a record of the result of the verification to the blockchain.

[0053] In one embodiment, the validator is configured to evaluate whether the biometric private key authenticates the access request by evaluation against a blockchain record of the access request associated with the user. In one embodiment, the validator includes a smart contract or automated rules for making this determination. In one embodiment, the validator retrieves an initial biometric key from the genesis block of the blockchain. The initial biometric key was generated from the user's identity and the user's biometric coordinates upon initial registration of the mobile device. The validator compares the biometric private key presented to the validator with the initial biometric key to determine whether they match. In one embodiment, the initial biometric key is a public key in the asymmetric key architecture of the systems and methods described herein. In one embodiment, the initial biometric key is a private key in the symmetric key architecture of the systems and methods described herein.

[0054] In one embodiment, if the biometric private key and the first biometric key match, the validator adds a block (or record) to the blockchain indicating that the access request is approved and the verification is successful, and if the biometric private key and the first biometric key do not match, the validator adds a block (or record) to the blockchain indicating that the access request is not approved and the verification is unsuccessful. This records the result of the verification in the blockchain. The validator signals that the verification process is complete.

[0055] In one embodiment, the validator also evaluates whether the blockchain indicates that a previous access request was not approved when determining whether a current access request is approved, as described in more detail with reference to Figure 4 and methods herein. For example, if a previous access request in the blockchain was not approved, the validator may determine that all subsequent access requests added to the blockchain are not approved (verification failed) because the mobile device may have been compromised.

[0056] Once the processor has completed adding the record of the verification results to the blockchain, processing at process block 220 is complete and processing continues to process block 225.

[0057] At process block 225, the processor controls access to the cloud service provider's resources based on the records in the blockchain by (i) denying access if the records indicate that validation failed and (ii) allowing access if the records indicate that validation was successful.

[0058] In one embodiment, the cloud service provider retrieves the most recent or last block of the blockchain associated with the user who submitted the access request (attempted to log in) and parses it to determine whether the validation was successful (indicating the access request is authorized) or failed (indicating the access request is not authorized). If the validation is successful, the cloud service provider grants the access request and allows the login attempt to complete successfully, allowing the computing device to access and use the cloud service provider's resources or services. If the validation is successful, the cloud service provider denies the access request and terminates the login attempt, preventing the computing device from accessing or using the cloud service provider's resources or services.

[0059] Once the processor has thus completed controlling access to the cloud service provider's resources based on the records in the blockchain by (i) denying access if the records indicate that validation failed and (ii) allowing access if the records indicate that validation was successful, processing at process block 225 is complete and processing continues to end block 230 where process 200 ends.

[0060] -Federation example- In one embodiment, a cloud service provider joins with other cloud service providers to share the login and authentication processes provided by federated identity provider 130 to form a federated identity group 165. In federated identity group 165, a blockchain is maintained by each of the cloud service provider and one or more other cloud service providers. This allows a single validation process to manage access to resources of all cloud service providers in federated identity group 165 based on the most recent (latest) records in the blockchain. Access to resources of other cloud resource providers is controlled based on the records in the blockchain by (i) denying access to the resources of the other cloud service providers if the records indicate that validation failed, and (ii) allowing access to the resources of the other cloud service providers if the records indicate that validation was successful.

[0061] In one embodiment, the features and functions described as belonging to federated identity provider 130 are performed by a decentralized biometric identity component 135 of a cloud service provider that does not have a dedicated identity provider system. This is a peer-to-peer configuration of federated identity group 165, where authentication and possibly user registration may be performed by a cloud service provider (such as cloud service provider1 105), where the authentication transaction is handled internally by the cloud service provider using the decentralized biometric identity component 135, and the verification results are propagated to other peer cloud service providers in the federated identity group 165. In this configuration, the cloud service provider acts as a peer, performing the biometric private key verification, adding a record of the results to a blockchain maintained within the cloud service provider, and propagating the record to other cloud service providers for inclusion in the copies of the blockchain maintained by the other cloud service providers.

[0062] In one embodiment, the features and functions described as belonging to the federated identity provider 130 are performed by a dedicated federated identity provider (as shown in FIG. 1 ). This is a master / slave configuration of the federated identity group 165, where registration and authentication are performed exclusively by the federated identity provider 130. The trusting cloud service provider redirects all authentication transactions to the federated identity provider 130 and relies on the validation performed by the federated identity provider 130. In this configuration, a separate or dedicated federated identity provider, separate from the cloud service provider, acts as a peer, performing the validation of the biometric private key, adding the resulting record to a blockchain maintained within the identity provider, and propagating the record to the cloud service provider and other cloud service providers for inclusion in copies of the blockchain maintained by the cloud service provider and other cloud service providers.

[0063] The trust component 153 maintains information about which cloud service providers and / or federated identity providers are authorized to update the local blockchain. In one embodiment, this includes a list of all cloud service providers that are members of the federated identity group 165. The addition of new members of the federated identity group 165 is controlled by the CSP registration component 161. In one embodiment, the CSP 161 receives an application to join the federated identity group 165 from a new cloud service provider that is not already part of the federated identity group 165, evaluates the credentials provided in the application, and if the credentials meet the conditions for joining the federated identity group 165, the new cloud service provider is admitted and the identity of the new cloud service provider is added to the trust component 153 of all cloud service providers in the federated identity group 165.

[0064] - Example of how to generate a biometric private key - 3 illustrates one embodiment of a method 300 for biometric private key generation in connection with providing a decentralized identity through user biometric authentication. In one embodiment, the steps of method 300 are performed by a mobile device 125 specially configured as shown and described with reference to FIG. 1. In one embodiment, the mobile device 125 is a dedicated computing device (such as mobile device 500) configured with decentralized biometric user identity logic 505. In one embodiment, the fingerprint coordinate generator 191, the retina coordinate generator 193, the face coordinate generator 195, and the biometric private key generator 197 are modules of a dedicated computing device (such as mobile device 500) configured with decentralized biometric user identity logic 505.

[0065] Method 300 may be initiated automatically based on a variety of triggers, such as in response to receiving a signal over a network or in response to (i) a user (or administrator) of system 100 initiating method 300, (ii) method 300 being scheduled to initiate at a defined time or time interval, (iii) mobile device 125 receiving a request for a biometric private key of a user (or administrator) of system 100 with a request to access resources at a cloud service provider (e.g., cloud service provider 105) using the user's identity, or (iv) analyzing stored data indicating that mobile device 125 has received a request for a biometric private key of a user (or administrator) of system 100 with a request to register the user's identity with federated identity provider 130. Method 300 begins at start block 305 in response to analyzing a received signal or acquired stored data and determining that the signal or stored data indicates that method 300 should be initiated. Processing continues to process block 310.

[0066] At process block 310, the processor prompts the user to enter their biometric coordinates using the mobile device.

[0067] In one embodiment, a biometric token application, such as biometric token application 127, is installed on a mobile device, such as mobile device 125. In one embodiment, the biometric token application is listening for a request for a user's biometric key. In one embodiment, the biometric token application is launched in response to receiving the request. Upon receiving the request, the mobile device audibly, tactilely, and / or visually prompts the user to enter their biometric coordinates. For example, the mobile device may emit a sound indicating that a request for biometric coordinates has been received as an audible prompt. For example, the mobile device may vibrate in a manner indicating that a request for biometric coordinates has been received as a tactile prompt. For example, the mobile device may display a graphical user interface (GUI) or illuminate an indicator light as a visual prompt. In one embodiment, the GUI is a GUI of a biometric token application installed on the mobile device. In one embodiment, the GUI displays instructions indicating that a request for a user's biometric key has been received and instructing the user to provide their biometric coordinates. In one embodiment, if the biometric coordinates are fingerprint coordinates, the instructions instruct the user to place their fingerprint on a fingerprint sensor of the mobile device. In one embodiment, the biometric coordinates are retinal coordinates and the instructions instruct the user to place their eyes in front of the mobile device camera, e.g., positioned close to the camera so that the camera can image the user's retina through the pupil of the user's eye. In one embodiment, if the biometric coordinates are face coordinates, the instructions instruct the user to place their face in front of the mobile device camera, e.g., positioned so that the camera can image the user's face.

[0068] Thus, once the processor has completed prompting the user to enter the user's biometric coordinates using the mobile device, processing at process block 310 is complete and processing continues at process block 315.

[0069] At process block 315, the processor receives biometric coordinates from a biometric input device of the mobile device.

[0070] In one embodiment, a biometric sensor (fingerprint scanner, retina scanner, or camera) on the mobile device captures a user's biometric input, for example as a data image or other data structure. A biometric token app on the mobile device then converts the data from the image or other data structure into a series of coordinates (also referred to herein as biometric coordinates) on a graph that represents the biometric input. In one embodiment, if the biometric input is a fingerprint, the fingerprint coordinates are generated by a fingerprint coordinate generator, such as fingerprint coordinate generator 191. In one embodiment, the fingerprint coordinate generator identifies relative positions of fingerprint features, such as crosses, cores, branches, ridges, deltas, pores, loops, or whorls, in the fingerprint image and records the coordinates of these features on a graph to form the coordinates of the fingerprint. In one embodiment, if the biometric input is a retinal image, the retinal coordinates are generated by a retinal coordinate generator, such as retinal coordinate generator 193. In one embodiment, the retinal coordinate generator identifies relative positions of retinal features, such as the positions of blood vessel branches in the retina of the eye. In one embodiment, if the biometric input is a face image, the face coordinates are generated by a face coordinate generator, such as face coordinate generator 195. In one embodiment, the face coordinate generator identifies the relative location of facial features, such as the location of the eyes, nose, mouth, ears, or other facial features. In one embodiment, feature location (fingerprint, retina, face, etc.) is performed by a machine learning (ML) model trained to accurately identify the location of such features. Once the biometric coordinates are generated, they are stored as a data structure for subsequent processing. In one embodiment, multiple types of biometric inputs are captured and converted to coordinates for added security. For example, both retina and fingerprint coordinates may be captured.

[0071] Once the processor has thus completed receiving biometric coordinates from the biometric input device of the mobile device, processing of process block 315 is complete and processing continues to process block 320.

[0072] At process block 320, the processor generates a biometric private key from the biometric coordinates by the mobile device.

[0073] In one embodiment, a biometric private key generator, such as biometric private key generator 197, generates a biometric private key. The biometric coordinates are retrieved from storage. The biometric coordinates are processed to generate a biometric private key from the coordinates. In one embodiment, the biometric coordinates are used as a seed to generate the private key. For example, (i) a binary representation of the biometric coordinates, (ii) a hexadecimal representation of the biometric coordinates, (iii) an ASCII string of the biometric coordinates, (iv) a Unicode string of the biometric coordinates, or (v) another representation of the biometric coordinates is provided as a seed to the key generation module. The key generation module can implement various key generation software such as HyperCrypt or PuTTY key generator. In one embodiment, the key generation module receives the seed and returns a public / private key pair where the system is configured to use an asymmetric key as the biometric private key. For example, the key generation module can generate a public / private key pair using the Rivest-Shamir-Adleman (RSA) algorithm. Other acceptable asymmetric key algorithms include Diffie-Hellman, Digital Signature Algorithm (DSA), El Gamal, Elliptic Curve Diffie-Hellman, Elliptic Curve DSA, other Elliptic Curve Cryptography algorithms, Paillier cryptosystem, Cramer-Shoup, YAK. In one embodiment, the key generation module receives a seed and returns a private key that the system is configured to use as a biometric private key with the symmetric key. For example, the key generation module may generate the private key using the Advanced Encryption Standard (AES) algorithm. Other acceptable symmetric key algorithms may include Blowfish, Camellia, CAST5, ChaCha20, DES, 3DES, Kuznyechik, RC4, Safer, Salsa20, Serpent, Skipjack, and Twofish. Other methods of using biometric coordinates to seed the generation of the private key are also contemplated by the present disclosure. In this manner, the biometric private key is generated from one or more of the fingerprint biometric coordinates, the facial biometric coordinates, and the retina biometric coordinates.The biometric application wraps the newly generated biometric private key in a message and sends it to the requesting entity of the federated identity group. In one embodiment, the message is an X.509 certificate and the biometric private key is inserted into a field of the certificate, such as a signature field.

[0074] Once the processor has thus completed generation of the biometric private key from the biometric coordinates by the mobile device, processing of process block 320 is complete and processing proceeds to end block 325 where process 300 ends.

[0075] In one embodiment, the generation of the biometric private key from the biometric coordinates is performed as part of an initial registration process. In one embodiment, the combination of the mobile device and the user's biometric coordinates is registered as a proprietary factor token for multi-factor authentication as shown and described herein. In one embodiment, the user attempts to log in to access resources at a cloud service provider (e.g., CSP1 105). In response to the login attempt, the cloud service provider queries a blockchain (e.g., blockchain 160) in a decentralized biometric ID component (e.g., decentralized biometric ID component 135) of the cloud service provider. In response to finding either (i) that there is no blockchain established for the user and mobile device combination, or (ii) that the blockchain established for the user and mobile device combination contains a block (record) indicating that a previous verification attempt failed, the cloud service provider redirects the login request to a user registration component (e.g., user registration component 163) of a federated identity provider (e.g., federated identity provider 130) to complete the registration process. The user registration component presents prompts to the user to complete the registration process, including downloading and installing a biometric token app (e.g., biometric token app 127) on the user's mobile device. Following installation, the user uses the biometric token application to generate a biometric private key for the first time and performs process 300 as part of the initial registration process to approve the user and mobile device pair as a biometric token device. The biometric token app sends the biometric key (in an X.509 certificate wrapper) to the user registration component.

[0076] In one embodiment, the user registration continues by submitting a biometric private key for inclusion as an initial record block in a blockchain associated with the user and the mobile device. The user registration component receives the biometric key in a message from the biometric token app and parses the message to extract the key. The user registration component adds the key to an initial or genesis block of the new blockchain, specifically to record the user's multi-factor authentication attempts using the mobile device. The user registration component adds the new blockchain to the blockchain repository 160 of the federated identity provider 130. The federated identity provider propagates the new blockchain to the blockchain repositories 160 of all cloud service providers in the federated identity group 165.

[0077] -An example of how to force re-registration of a compromised ID- 4 illustrates one embodiment of a method 400 for enforcing re-registration of a compromised user identity associated with providing a decentralized identity through user biometric authentication. In one embodiment, the steps of method 400 are performed by the decentralized biometric identity component 135 and the federated identity provider 130 (as shown and described with reference to FIG. 1 ). In one embodiment, the federated identity provider 130 is a dedicated computing device (such as computing device 605) configured with decentralized biometric user identity logic 630. In one embodiment, the federated identity provider 130 is a module of the dedicated computing device configured with logic 630.

[0078] Method 400 may be initiated automatically based on various triggers, such as in response to receiving a signal over the network or analyzing stored data indicating: (i) a user (or administrator) of system 100 initiates method 400; (ii) method 400 is scheduled to begin at a defined time or time interval; (iii) verification of a biometric private key received from a mobile device as part of a current request to access a cloud computing provider resource fails; (iv) a previous verification of a previous biometric private key received from a mobile device as part of a previous request to access a cloud computing provider resource fails; or (v) a record (block) of the results of the verification included in the blockchain indicates that the verification failed. Method 400 begins at start block 405 in response to analyzing a received signal or acquired stored data and determining that the signal or stored data indicates that method 400 should be initiated. Processing continues at process block 410.

[0079] At process block 410, the processor fails verification of any subsequent biometric keys submitted following recording.

[0080] In one embodiment, during the validation process of the subsequent biometric key performed by the validator 155, the cloud service provider accesses the blockchain for the user and mobile device combination. The cloud service provider parses the blockchain (e.g., the latest block of the blockchain) to determine whether a previous attempt to validate the user's previous biometric key failed. If a failure of a previous attempt to validate the previous biometric key is detected, the validation process of the subsequent biometric key also fails, even if the subsequent biometric key matches the user's biometric key provided in the genesis block of the blockchain. The validator 155 includes a rule that if a previous validation in the blockchain for the user and mobile device combination fails, then validation of that user and mobile device combination fails. An intervening validation failure indicates that the mobile device may have been compromised and indicates that the user and mobile device combination needs to be re-registered.

[0081] Once the processor has thus completed failing verification of subsequent biometric keys submitted following recording, processing at process block 410 is complete and processing continues at process block 415.

[0082] At process block 415, the processor requires re-enrollment of the user to create a new blockchain associated with the user and the mobile device before the user is granted access to the cloud service provider's resources.

[0083] In one embodiment, in response to an attempt to access resources of a cloud service provider in a federated identity group after a failed validation, the cloud service provider displays to the user a message that is either (i) generated and presented to the user on a display of the mobile device 125, e.g., in a GUI of the biometric token app 127, or (ii) generated and presented to the user on a display of the computing device 180, e.g., in a GUI of one or more of the cloud connectivity applications 185. The message may indicate, for example, that the registration of the mobile device has expired, been canceled, or is no longer valid, and that the user must re-register the mobile device before access to resources of the cloud service provider is permitted. The message may further indicate the steps for re-registration or include a link to initiate the re-registration process.

[0084] Once the processor has thus completed the user's request to re-enroll to create a new blockchain associated with the user and mobile device before the user is granted access to the cloud service provider's resources, processing at process block 415 is complete and processing proceeds to end block 420 where process 400 ends.

[0085] -Selected embodiment- In one embodiment, a computer-implemented method includes, in response to a request by a computing device to access a cloud service provider resource, sending a request for a biometric private key to a mobile device associated with a user, in response to receiving the biometric private key, submitting the biometric private key for validation to a blockchain associated with the user and the mobile device, adding a record of the result of the validation to the blockchain, and controlling access to the cloud service provider resource based on the record in the blockchain by (i) denying access if the record indicates that validation failed and (ii) allowing access if the record indicates that validation was successful. In one embodiment, the blockchain is maintained by the cloud service provider and each of the one or more other cloud service providers, and the computer-implemented method includes controlling access to the other cloud resource provider resource based on the record in the blockchain by (i) denying access to the other cloud service provider resource if the record indicates that validation failed and (ii) allowing access to the other cloud service provider resource if the record indicates that validation was successful. In one embodiment of the computer-implemented method, generating the biometric private key includes prompting a user to input their biometric coordinates using a mobile device, receiving the biometric coordinates from a biometric input device of the mobile device, and generating, by the mobile device, the biometric private key from the biometric coordinates. In one embodiment, the method further includes enrolling the user by submitting the biometric private key for inclusion as an initial record block in a blockchain associated with the user and the mobile device.In one embodiment, the record indicates that the validation failed, and the computer-implemented method further includes failing validation of subsequent biometric keys submitted after the record, and requiring the user to re-enroll to create a new blockchain associated with the user and the mobile device before the user is allowed access to resources of the cloud service provider. In one embodiment of the computer-implemented method, the biometric private key is Advanced Encryption Standard (AES) or Rivest-Shamir-Adleman (RSA). In one embodiment of the computer-implemented method, the biometric private key is generated from one or more of a fingerprint biometric coordinate, a face biometric coordinate, and a retina biometric coordinate. In one embodiment of the computer-implemented method, the cloud service provider acts as a peer, performs validation of the biometric private key, adds a resulting record to a blockchain maintained within the cloud service provider, and propagates the record to other cloud service providers for inclusion in copies of the blockchain maintained by the other cloud service providers. In one embodiment of the computer-implemented method, the federated identity provider acts as a peer, performs a biometric private key verification, adds a resulting record to a blockchain maintained within the identity provider, and propagates the record to the cloud service provider and other cloud service providers for inclusion in copies of the blockchain maintained by the cloud service provider and other cloud service providers. In one embodiment of the computer-implemented method, the blockchain is maintained in a key store of the cloud service provider. In one embodiment, computer-readable instructions are stored in a non-transitory computer-readable medium that, when executed by a processor of the computer in cooperation with other components of the computer as necessary, causes the computer to perform the method. In one embodiment, a computing system includes a processor, a memory, and a computer-readable medium that stores computer-readable instructions that, when executed by the computing system, causes the computer to perform the method.

[0086] -Software module embodiment- Generally, software instructions are designed to be executed by one or more appropriately programmed processors that access memory, such as accessing CPU or GPU resources. These software instructions may include, for example, computer executable code and source code that may be compiled into computer executable code. These software instructions may also include instructions written in an interpreted programming language, such as a scripting language.

[0087] In a complex system, such instructions are arranged in program modules, with each such module capable of performing a particular task, process, function, or operation. The entire set of modules may be controlled or coordinated in its operation by the system's main program, operating system (OS), or other form of organizational platform.

[0088] In one embodiment, one or more of the components described herein are configured as modules stored on a non-transitory computer-readable medium with stored software instructions that, when executed by at least a processor accessing a memory or storage, cause a computing device to perform corresponding functions described herein.

[0089] -Cloud or enterprise examples- In one embodiment, the system (e.g., system 100) includes a computing / data processing system including a computing application or a collection of distributed computing applications (e.g., providers 105, 110, 130 of federated identity group 165) for access and use by other client computing devices associated with an enterprise (e.g., client devices 170, 175, and 180 of enterprise network 120) that communicate with each other over a network (e.g., network 115). The applications and computing systems can be configured to operate in or be realized as a cloud-based network computing system, infrastructure as a service (IAAS), platform as a service (PAAS), or software as a service (SAAS) architecture, or other type of network computing solution. In one embodiment, the system provides at least one or more of the functionality disclosed herein and a graphical user interface for accessing and operating the functionality.

[0090] -Mobile device embodiment- Referring now to FIG. 5, an exemplary mobile device 500 configured and / or programmed with one or more of the systems and methods described herein and / or equivalents is shown. In one example, the mobile device 500 may include a distributed biometric user ID logic 505 configured to facilitate providing a distributed ID through user biometric authentication, similar to the logic, systems, and methods shown and described with reference to FIGS. 1-4. The mobile device 500 may include a cellular antenna 510 for receiving or transmitting information over a cellular communication network. An exemplary embodiment may implement signal processing and / or control circuitry, generally identified at 520 in FIG. 5. In some implementations, the mobile device 500 includes a microphone 530, an audio output 540, such as a speaker and / or audio output jack, a display 550, and / or an input device 560, such as a keypad, a pointing device, a touch screen, a voice-activated and / or other input device. In one embodiment, input device 560 also includes a fingerprint scanner 562 for receiving a fingerprint, such as an optical fingerprint scanner, a capacitive fingerprint scanner, or an ultrasonic fingerprint scanner. In one embodiment, input device 560 also includes a camera 564 capable of imaging the retina or imaging the face. In one embodiment, input device 560 also includes a dedicated retina scanner (not shown). Signal processing and / or control circuitry 520 and / or other circuitry (not shown) within mobile device 500 may process data, perform encoding and / or encryption, perform calculations, format data, and / or perform other mobile phone functions.

[0091] The mobile device 500 can communicate with mass data storage 570 that stores data non-volatilely, such as on optical and / or magnetic storage devices including, for example, HDDs and / or DVDs. The HDD may be a magnetic HDD having one or more platters, or a solid-state drive (SSD). The mobile device 500 can be connected to memory 580, such as RAM, ROM, low-latency non-volatile memory such as flash memory, and / or other suitable electronic data storage. The mobile device 500 can also support connection to a wireless local area network (WLAN) via a WLAN network interface 590. The mobile device 500 can include a WLAN antenna 595 for receiving or transmitting information over the WLAN. In this exemplary embodiment, the exemplary system and method can be implemented using this WLAN network interface 590, although other configurations are possible.

[0092] -Computing device embodiment- FIG. 6 illustrates an exemplary computing system 600 configured and / or programmed as a dedicated computing device with one or more of the exemplary systems and methods described herein and / or equivalents. The exemplary computing device may be a computer 605 including a processor 610, a memory 615, and an input / output port 620 operatively connected by a bus 625. In one example, the computer 605 may include a distributed biometric user ID logic 630 configured to facilitate providing a distributed identity through user biometric authentication, similar to the logic, systems, and methods shown and described with reference to FIGS. 1-4. In another example, the distributed biometric user ID logic 630 may be implemented in hardware, a non-transitory computer readable medium having instructions stored thereon, firmware, and / or a combination thereof. Although the distributed biometric user ID logic 630 is illustrated as a hardware component connected to the bus 625, it should be understood that in other embodiments, the distributed biometric user ID logic 630 may be implemented within the processor 610, stored in the memory 615, or stored on a disk 635 on a computer readable medium 637.

[0093] In one embodiment, the distributed biometric user ID logic 630 or computing system 600 is a means (structure: hardware, non-transitory computer readable media, firmware, etc.) for performing the described operations. In some embodiments, the computing device may be a server operating in a cloud computing system, a server configured in a Software as a Service (SaaS) architecture, a smartphone, a laptop, a tablet computing device, etc.

[0094] The means may be realized, for example, as an ASIC programmed to perform the provision of a decentralized identity by user biometric authentication as shown and described herein. The means may also be realized as stored computer-executable instructions temporarily stored in memory 615 and presented to computer 605 as data 640 that are then executed by processor 610.

[0095] The distributed biometric user ID logic 630 may also provide the means (e.g., hardware, a non-transitory computer-readable medium storing executable instructions, firmware) for performing the provision of a distributed ID through user biometric authentication.

[0096] To generally describe an exemplary configuration of computer 605, processor 610 may be a variety of different processors including dual microprocessors and other multi-processor architectures. Memory 615 may include volatile and / or non-volatile memory. Non-volatile memory may include, for example, ROM, PROM, EPROM, EEPROM, etc. Volatile memory may include, for example, RAM, SRAM, DRAM, etc. Storage disk 635 may be operatively connected to computer 605 via, for example, input / output (I / O) interface (e.g., card or device) 645 and input / output port 620, which are controlled by at least input / output (I / O) controller 647. Disk 635 may be, for example, a magnetic disk drive, a solid state disk drive, a floppy disk drive, a tape drive, a Zip drive, a flash memory card, a memory stick, etc. Additionally, disk 635 may be a CD-ROM drive, a CD-R drive, a CD-RW drive, a DVD-ROM, etc. Memory 615 may store, for example, processes 650 and / or data 640 formatted as one or more data structures. Disk 635 and / or memory 615 may store an operating system that controls and allocates resources of computer 605. Computer 605 may interact with, control, and / or be controlled by input / output (I / O) devices via input / output (I / O) controller 647, I / O interface 645, and input / output ports 620.The input / output devices include one or more displays 670, printers 672 (such as inkjet, laser, or 3D printers), and audio output devices 674 (such as speakers or headphones), text input devices 680 (such as a keyboard), pointing and selection devices 682 (such as a mouse, trackball, touchpad, touchscreen, joystick, pointing stick, stylus mouse, etc.), audio input devices 684 (such as a microphone), video input devices 686 (such as a video camera or still image camera), video cards (not shown), disks 635, network devices 655, fingerprint scanners 690, Internet of Things sensors (not shown), etc. The input / output ports 620 can include, for example, serial ports, parallel ports, USB ports.

[0097] Computer 605 may operate in a networked environment and thus may be connected to a network device 655 via I / O interface 645 and / or I / O port 620. Through network device 655, computer 605 may interact with a network 660. Through network 660, computer 605 may be logically connected to remote computer-controllable hardware, such as a remote computer 665, a remote mobile device, or an autonomous vehicle 690. The networks with which computer 605 may interact may include, but are not limited to, a LAN, a WAN, and other networks.

[0098] -Definitions and other embodiments- In another embodiment, the described methods and / or equivalents thereof may be performed using computer-executable instructions. Thus, in one embodiment, a non-transitory computer-readable / storage medium is configured with stored computer-executable instructions of an algorithm / executable application that, when executed by a machine, causes the machine (and / or associated components) to perform the method. Examples of machines include, but are not limited to, processors, computers, servers operating in a cloud computing system, servers configured in a Software as a Service (SaaS) architecture, smartphones, etc. In one embodiment, a computing device is implemented with one or more executable algorithms configured to perform any of the disclosed methods.

[0099] In one or more embodiments, the disclosed method or its equivalent is performed by either computer hardware configured to perform the method; or computer instructions embodied in a module stored on a non-transitory computer-readable medium, the instructions configured as an executable algorithm configured to perform the method when executed by at least a processor of a computing device.

[0100] For ease of explanation, the methodologies depicted in the figures are shown and described as a series of algorithmic blocks, but it should be understood that the methodologies are not limited by the order of the blocks. Some blocks may occur in a different order than shown and described, and / or concurrently with other blocks. Furthermore, fewer than all of the illustrated blocks may be used to implement the example methodologies. The blocks may be combined or separated into multiple operations / components. Furthermore, additional and / or alternative methodologies may employ additional operations not shown in the blocks.

[0101] The following includes definitions of selected terms used herein. The definitions include various examples and / or forms of components that fall within the scope of the term and may be used to implement. These examples are not intended to be limiting. Both singular and plural forms of the terms may be included within the definitions.

[0102] References to "one embodiment," "embodiment," "one example," "example," etc. indicate that the embodiment or example so described may include a particular feature, structure, characteristic, attribute, element, or limitation, but not all embodiments or examples necessarily include that particular feature, structure, characteristic, attribute, element, or limitation. Moreover, repeated use of the phrase "in one embodiment" may, but does not necessarily, refer to the same embodiment.

[0103] AES: Advanced Encryption Standard. API: Application Programming Interface.

[0104] ASIC: Application Specific Integrated Circuit. AWS: Amazon Web Services CA: Certificate Authority.

[0105] CD:Compact disc. CD-R: Recordable CD.

[0106] CD-RW: Rewritable CD. CPU: Central Processing Unit.

[0107] CSR: Certificate Signing Request. DVD: Digital Versatile Disc and / or Digital Video Disc.

[0108] GPU: Graphics Processing Unit. HDD: Hard disk drive.

[0109] HTTP: Hypertext Transfer Protocol. I / O: Input / Output.

[0110] IAAS: Infrastructure as a Service. ICA: Intermediate Certificate Authority.

[0111] JKS: Java Keystore. JSON: JavaScript Object Notation.

[0112] KMS: Key Management Service. LAN: Local Area Network.

[0113] WLAN: Wireless LAN. MAC: Media Access Control.

[0114] MIN: Mobile Identification Number. ML: Machine learning.

[0115] NAS: Network Attached Storage. OCI: Oracle Cloud Infrastructure.

[0116] OS: Operating system. PAAS: Platform as a Service RAM: Random Access Memory.

[0117] DRAM: Dynamic RAM. SRAM: Synchronous RAM.

[0118] REST: Representational State Transfer. ROM: Read-only memory.

[0119] PROM: Programmable Read-Only. EPROM: Erasable PROM.

[0120] EEPROM: Electrically Erasable PROM. RSA: Rivest-Shamir-Adleman.

[0121] SAAS: Software as a Service. SOAP: Simple Object Access Protocol.

[0122] SQL: Structured Query Language. SSD: Solid State Drive.

[0123] TCP / IP: Transmission Control Protocol / Internet Protocol USB: Universal Serial Bus.

[0124] XML: Extensible Markup Language. WAN: Wide Area Network.

[0125] A "data structure" as used herein is an organization of data within a computing system that is stored in a memory, storage device, or other computerized system. A data structure may be, for example, any one of a data field, a data file, a data array, a data record, a database, a data table, a graph, a tree, a linked list, and the like. A data structure may be formed from and contain many other data structures (e.g., a database contains many data records). According to other embodiments, other examples of data structures are possible as well.

[0126] As used herein, "computer-readable medium" or "computer storage medium" refers to a non-transitory medium that stores instructions and / or data configured to perform one or more of the disclosed functions when executed. In some embodiments, data can function as instructions. Computer-readable media can take forms including, but not limited to, non-volatile media and volatile media. Non-volatile media can include, for example, optical disks, magnetic disks, and the like. Volatile media can include, for example, semiconductor memory, dynamic memory, and the like. Common forms of computer-readable media can include, but are not limited to, floppy disks, flexible disks, hard disks, magnetic tapes, other magnetic media, application specific integrated circuits (ASICs), programmable logic devices, compact disks (CDs), other optical media, random access memory (RAM), read only memory (ROM), memory chips or cards, memory sticks, solid state storage devices (SSDs), flash drives, and other media on which a computer, processor, or other electronic device can function. Each type of medium, when selected for implementation in an embodiment, can include stored instructions of an algorithm configured to perform one or more of the disclosed and / or claimed functions.

[0127] "Logic" as used herein refers to components implemented in computer or electrical hardware, non-transitory media having instructions of an executable application or program module stored thereon, and / or combinations thereof, performing any of the functions or operations disclosed herein and / or causing functions or operations from another logic, method, and / or system to be performed as disclosed herein. Equivalent logic may include firmware, a microprocessor programmed with an algorithm, discrete logic (e.g., ASIC), at least one circuit, analog circuit, digital circuit, programmed logic device, memory device containing algorithmic instructions, and the like, any of which may be configured to perform one or more of the disclosed functions. In an embodiment, logic may include one or more gates, combinations of gates, or other circuit components configured to perform one or more of the disclosed functions. Where multiple logics are described, the multiple logics may be incorporated into one logic. Similarly, where a single logic is described, the single logic may be distributed among multiple logics. In an embodiment, one or more of these logics are corresponding structures associated with performing the disclosed and / or claimed functions. The choice of which type of logic to implement can be based on the required system requirements or specifications: for example, if high speed is a consideration, hardware is selected to implement the functionality, if low cost is a consideration, stored instructions / executable applications are selected to implement the functionality.

[0128] An "operable connection," or a connection in which entities are "operably connected," is a connection in which signals, physical communications, and / or logical communications may be transmitted and / or received. An operable connection may include physical interfaces, electrical interfaces, and / or data interfaces. An operable connection may include different combinations of interfaces and / or connections sufficient to enable operable control. For example, two entities may be operably connected to communicate signals directly or through one or more intermediate entities (e.g., processors, operating systems, logic, non-transitory computer-readable media). Logical and / or physical communication channels may be used to create an operable connection.

[0129] As used herein, a "user" includes, but is not limited to, one or more people, computers or other devices, or any combination thereof.

[0130] Although the disclosed embodiments have been illustrated and described in considerable detail, it is not intended to limit or in any way restrict the scope of the appended claims to such details. Of course, it is not possible to describe every conceivable combination of components or methodologies for purposes of describing various aspects of the subject matter. Thus, the disclosure is not limited to the specific details or illustrative examples shown and described. Thus, the disclosure is intended to embrace changes, modifications, and variations that fall within the scope of the appended claims.

[0131] To the extent the terms "comprise" or "comprising" are used in the detailed description or in the claims, this term is intended to be as inclusive as the term "comprise" as it is interpreted when used as a transitional term in the claims.

[0132] To the extent the term "or" is used in the detailed description or claims (e.g., A or B), it is intended to mean "A or B or both." If the applicant intends to indicate "A or B but not both," the phrase "A or B but not both" is used. Thus, use of the term "or" herein is inclusive and not exclusive.

Claims

1. A method executed by a computer, comprising: responding to an access request to a resource of a cloud service provider by a computing device, and sending a request for a biometric secret key to a mobile device associated with a user; responding to the reception of the biometric secret key, submitting the biometric secret key for verification against a blockchain associated with the user and the mobile device; adding a record of the result of the verification to the blockchain; controlling access to the resource of the cloud service provider based on the record in the blockchain by (i) denying access if the record indicates that the verification has failed, and (ii) permitting access if the record indicates that the verification has succeeded.

2. The blockchain is maintained by each of the cloud service provider and one or more other cloud service providers, and further comprises controlling access to resources of the other cloud service providers based on the record in the blockchain by (i) denying access to resources of the other cloud service providers if the record indicates that the verification has failed, and (ii) permitting access to the resources of the other cloud service providers if the record indicates that the verification has succeeded. The method executed by a computer according to Claim 1.

3. prompting the user to input biometric coordinates using the mobile device; receiving the biometric coordinates from a biometric input device of the mobile device; generating the biometric secret key by generating the biometric secret key from the biometric coordinates by the mobile device; registering the user by submitting the biometric secret key for inclusion as an initial record block in the blockchain associated with the user and the mobile device. The method executed by a computer according to Claim 1 or 2.

4. The record indicates that the verification has failed, failing the verification of a subsequent biometric key submitted after the record. Before the user is permitted access to the resources of the cloud service provider, further comprising the step of requesting re-registration of the user to create a new blockchain associated with the user and the mobile device. The method executed by a computer according to claim 1 or claim 2.

5. The biometric secret key is generated from one or more of fingerprint biometric coordinates, face biometric coordinates, and retinal biometric coordinates. The method executed by a computer according to claim 1 or claim 2.

6. A program comprising computer-executable instructions, which, when executed by at least a processor of a computer, cause the computer to In response to an access request to the resources of a cloud service provider by a computing device, send a request for a biometric secret key to a mobile device associated with the user. In response to receiving the biometric secret key, submit the biometric secret key for verification against a blockchain associated with the user and the mobile device. Add a record of the result of the verification to the blockchain. Based on the record in the blockchain, control access to the resources of the cloud service provider by (i) denying access if the record indicates that the verification has failed, and (ii) permitting access if the record indicates that the verification has been successful. A program that causes the above to be done.

7. The blockchain is maintained by each of the cloud service provider and one or more other cloud service providers, and the instructions further cause the computer to (i) deny access to the resources of the other cloud service providers if the record indicates that the verification has failed, and (ii) permit access to the resources of the other cloud service providers if the record indicates that the verification has been successful. Based on the record in the blockchain, control access to the resources of the other cloud resource providers. The program according to claim 6.

8. The command includes a command for registering the user, and the command further causes the computer to prompt the user to input biometric authentication coordinates using the mobile device, generate the biometric authentication secret key from the biometric authentication coordinates by the mobile device, submit the biometric authentication secret key for inclusion as an initial record block of the blockchain associated with the user and the mobile device. The program according to claim 6 or claim 7.

9. The command includes a command for generating the biometric authentication secret key, and the command further causes the computer to prompt the user to input biometric authentication coordinates using the mobile device, receive the biometric authentication coordinates from a biometric authentication input device of the mobile device, generate the biometric authentication secret key from the biometric authentication coordinates by the mobile device, The biometric authentication secret key is an Advanced Encryption Standard (AES) key or a Rivest-Shamir-Adleman (RSA) key. The program according to claim 6 or claim 7.

10. The federation ID provider functions as a peer, executes the verification of the biometric authentication secret key, adds a record of the result to the blockchain maintained within the ID provider, and propagates the record to the cloud service provider and the other cloud service providers for inclusion in a copy of the blockchain maintained by the cloud service provider and the other cloud service providers. The program according to claim 6 or claim 7.

11. A computing system, a processor, a memory operably connected to the processor, a non-transitory computer-readable medium operably connected to the processor and the memory and storing computer-executable instructions, wherein when the instructions are executed by at least the processor of the computer, the computing system is caused to send a request for a biometric authentication secret key to a mobile device associated with a user in response to a request for access to resources of a cloud service provider by a computing device In response to receiving the biometric authentication secret key, submitting the biometric authentication secret key for verification against a blockchain associated with the user and the mobile device; Adding a record of the result of the verification to the blockchain; A computing system that controls access to the resources of the cloud service provider based on the record in the blockchain by (i) denying access if the record indicates that the verification has failed and (ii) permitting access if the record indicates that the verification has succeeded.

12. The blockchain is maintained by each of the cloud service provider and one or more other cloud service providers, and by the instructions, the computing system further (i) denies access to the resources of the other cloud service providers if the record indicates that the verification has failed and (ii) permits access to the resources of the other cloud service providers if the record indicates that the verification has succeeded, thereby controlling access to the resources of the other cloud resource providers based on the record in the blockchain. The computing system according to claim 11.

13. The instructions include instructions for registering the user, and the instructions further cause the computing system to Prompt the user to input biometric authentication coordinates using the mobile device; Generate the biometric authentication secret key from the biometric authentication coordinates by the mobile device; Submit the biometric authentication secret key for inclusion as an initial record block of the blockchain associated with the user and the mobile device. The computing system according to claim 11 or claim 12.

14. The instructions include instructions for generating the biometric authentication secret key, and the instructions further cause the computing system to Prompt the user to input biometric authentication coordinates using the mobile device; Receive the biometric authentication coordinates from the biometric authentication input device of the mobile device; The computing system according to claim 11 or claim 12, causing the mobile device to generate the biometric authentication secret key from the biometric authentication coordinates.

15. The instructions further cause the computing system to store the blockchain in a key store of the cloud service provider, execute the verification of the biometric authentication secret key, add the record of the result to the blockchain of the key store, and propagate the record to the other cloud service provider for inclusion in a copy of the blockchain held in a key store of the other cloud service provider. The computing system according to claim 11 or claim 12.

Images