Systems and methods for liveness-verified, biometric-based encryption

Systems and methods for encryption/decryption based on liveness-verified biometric data that cannot be stolen/spoofed. In various embodiments, the disclosed systems and methods facilitate encryption/decryption of data through controlling access to keys via liveness-verified biometric data. Liveness-verified biometric data may, in various embodiments, be derived from facial features, fingerprints, voice recognition, DNA, etc. Generally, if the liveness and identity of the requesting individual cannot be verified, then the individual will not be permitted to encrypt/decrypt data using the disclosed systems and methods.

TECHNICAL FIELD

The present systems and methods relate generally to encryption and, more particularly, to encryption based on liveness-verified biometric data.

BACKGROUND

Access to sensitive electronic data is increasingly becoming a large and complex risk, financially and otherwise, for individuals, corporations, and governments alike. Malicious actors desiring to access that sensitive data employ a variety of creative methods to do so—intercepting the data in motion, impersonating authorized individuals to access the data at rest, brute-force hacking into the storage location of that data at rest, etc. Once data is encrypted, its security can be assured only so long as the access credentials for the key that decrypts the data remain secure. Access credentials (e.g., passwords, secured devices, etc.), however, regardless of the level of care taken, are almost always subject to a risk of being stolen/spoofed.

Therefore, there is a long-felt but unresolved need for a system or method that permits encryption/decryption based on liveness-verified biometric data that cannot be stolen/spoofed.

BRIEF SUMMARY OF THE DISCLOSURE

Briefly described, and according to one embodiment, aspects of the present disclosure generally relate to systems and methods for encryption/decryption based on liveness-verified biometric data that cannot be stolen/spoofed.

In various embodiments, the disclosed system facilitates encryption/decryption of data through controlling access to encryption/decryption keys via liveness-verified biometric data (e.g., data that has been verified as derived from the correct actual live individual to avoid bad actors spoofing the data to gain access to the encryption/decryption keys). Liveness-verified biometric data may, in various embodiments, be derived from facial features, fingerprints, voice recognition, DNA, etc. Generally, the disclosed system improves the robustness and security of encryption/decryption systems by ensuring that only the proper authorized individuals can access the system (with credentials that cannot be stolen or spoofed).

Generally, in one embodiment, the system requests that an individual who desires to encrypt/decrypt data take a photo/video of his/her face for liveness verification (e.g., determining whether the photo/video has been spoofed or is of an actual live individual). In various embodiments, the system may determine if a photo/video has been spoofed via techniques described in U.S. patent application Ser. No. 15/782,940, entitled “Systems and Methods for Passive-Subject Liveness Verification in Digital Media,” filed on Oct. 13, 2017, the entire disclosure of which is herein incorporated by reference. Once liveness of the photo/video is confirmed, in one embodiment, a biometric hash of the individual's face (e.g., a hash of the prominent facial features of the individual, generated by running a representation of the features through a cryptographic hashing algorithm, such as, but not limited to, SHA-1, MD-5, etc.) is generated for identity verification of the individual through a comparison to one or more stored biometric hashes corresponding to the individual. In one embodiment, if the identity of the individual is verified, then the individual is provided access to the relevant encryption/decryption keys. Generally, if the liveness and identity of the requesting individual cannot be verified, then the individual will not be permitted to encrypt/decrypt data using the system. In this manner, the disclosed system improves the security of the encrypted data by allowing access only to a live individual with authorized biometric features, resulting in access credentials that cannot be stolen/spoofed.

For example, consider a scenario where a user at a mobile phone is sending an email. Rather than allowing for the user to send the email simply because he/she has unlocked/logged-into the mobile phone, the systems and methods discussed herein may verify the user's identity prior to sending the email, thus preventing an unauthorized party from sending an email under the user's identity. Furthermore, the systems and methods discussed herein may encrypt the email prior to transmitting the email to the recipient, and the email may only be decrypted if the recipient's identity is also verified (via liveness verification). Accordingly, the systems and methods discussed herein allow for a trusted environment for sending data, such as emails, safely.

The system generally places no limitations on the types of data that may be encrypted/decrypted (e.g., data in motion, in rest, documents, images, videos, etc.). Further, the system places no limitations on the types of encryption/decryption that may be conducted on that data. Generally, encryption is performed by inputting the original data and a key into a cryptographic algorithm such as, but not limited to, Advanced Encryption Standard (AES), RSA, Blowfish, etc., to generate an encrypted output of the original data, generally in ciphertext. Decryption is generally performed by inputting the encrypted output and a key into the cryptographic algorithm to generate a decrypted version of the encrypted output, generally corresponding to the original data.

In various embodiments, the present disclosure describes a method for biometric-based encryption, including the steps of: receiving, at an electronic computing device, liveness media corresponding to a user at the electronic computing device, wherein the liveness media includes biometric data including a picture and/or video of the user captured via the mobile computing device; generating a biometric hash corresponding to the liveness media; transmitting the generated biometric hash to a server; comparing the generated biometric hash to one or more stored biometric hashes of the user at the server, wherein comparing the generated biometric hash to the one or more stored biometric hashes includes determining if the generated biometric hash and the one or more stored biometric hashes match within a predetermined threshold; and in response to determining a match within the predetermined threshold, transmitting encryption and/or decryption instructions to the electronic computing device.

In particular embodiments, the method further includes the steps of: prior to receiving the liveness media, receiving a user-initiated request for encryption and/or decryption at the electronic computing device; and generating a request for the liveness media at the electronic computing device for liveness verification of the user. In one embodiment, the predetermined threshold corresponds to a predetermined security level of the server. In certain embodiments, the one or more stored biometric hashes include initial hashes generated in response to the user establishing an account with the server. In at least one embodiment, the initial hashes are generated with initial liveness media. In various embodiments, two private keys are generated in association with the initial hashes, and wherein a first private key of the two private keys is stored at the server in a user device account, and a second private key of the two private keys is transmitted to the electronic computing device. In some embodiments, the encryption and/or decryption instructions include an authorization token for allowing the electronic computing device to perform the encryption and/or decryption via the second private key. In certain embodiments, the encryption and/or decryption are performed on an email, batch of files, or physical asset.

In one embodiment, the liveness media is unique to the user. In certain embodiments, the generated biometric hash and the one or more stored biometric hashes are generated by the SHA-1 and/or MD-5 cryptographic hashing algorithms. In a particular embodiment, the method further includes the step of verifying, at the electronic computing device, the liveness of the user via the liveness media. In at least one embodiment, prior to transmitting the generated biometric hash to the server, the generated biometric has is compared to one or more stored biometric hashes of the user at the electronic computing device.

In various embodiments, the present disclosure describes a system for biometric-based encryption: a server for encryption and decryption management; and an electronic computing device associated with a user, wherein the electronic computing device includes a processor operable to: receive liveness media corresponding to the user at the electronic computing device, wherein the liveness media includes biometric data including a picture and/or video of the user captured via the mobile computing device; generate a biometric hash corresponding to the liveness media; transmit the generated biometric hash to the server, wherein the generated biometric hash is compared to one or more stored biometric hashes of the user at the server, and wherein comparing the generated biometric hash to the one or more stored biometric hashes includes determining if the generated biometric hash and the one or more stored biometric hashes match within a predetermined threshold; and in response to determining a match within the predetermined threshold, receive encryption and/or decryption instructions from the server at the electronic computing device.

In one embodiment, the processor is further operable to: prior to receiving the liveness media, receive a user-initiated request for encryption and/or decryption at the electronic computing device; and generate a request for the liveness media at the electronic computing device for liveness verification of the user. In a particular embodiment, the predetermined threshold corresponds to a predetermined security level of the server. In certain embodiments, the one or more stored biometric hashes include initial hashes generated in response to the user establishing an account with the server. In at least one embodiment, the initial hashes are generated with initial liveness media.

According to various aspects of the present disclosure, two private keys are generated in association with the initial hashes, and wherein a first private key of the two private keys is stored at the server in a user device account, and a second private key of the two private keys is transmitted to the electronic computing device. In particular embodiments, the encryption and/or decryption instructions include an authorization token for allowing the electronic computing device to perform the encryption and/or decryption via the second private key. In certain embodiments, the encryption and/or decryption are performed on an email, batch of files, or physical asset.

In one embodiment, the liveness media is unique to the user. In various embodiments, the generated biometric hash and the one or more stored biometric hashes are generated by the SHA-1 and/or MD-5 cryptographic hashing algorithms. In certain embodiments, the processor is further operable to verify, at the electronic computing device, the liveness of the user via the liveness media. Furthermore, in particular embodiments, prior to transmitting the generated biometric hash to the server, the generated biometric has is compared to one or more stored biometric hashes of the user at the electronic computing device.

In at least one embodiment, the present disclosure describes a method for liveness-verified biometric-based encryption and decryption, including the steps of: receiving, at an electronic computing device, liveness media corresponding to a user at the electronic computing device, wherein the liveness media includes biometric data including a picture and/or video of the user captured via the mobile computing device; verifying the liveness of the user at the electronic computing device; generating a hash, at the electronic computing device, based on the received biometric data; comparing the generated hash to one or more stored hashes at the electronic computing device for verifying the identity of the user; in response to verifying the identity of the user, transmitting the generated hash to a server for encryption and decryption management; comparing the generated hash to one or more stored hashes at the server for determining encryption and/or decryption instructions; in response to determining a match between the generated hash and the one or more stored hashes at the server, generating the encryption and/or decryption instructions based on the match; and transmitting the encryption and/or decryption instructions to the electronic computing device, wherein the encryption and/or decryption instructions provide access to a protected item at the electronic computing device.

DETAILED DESCRIPTION

Whether a term is capitalized is not considered definitive or limiting of the meaning of a term. As used in this document, a capitalized term shall have the same meaning as an uncapitalized term, unless the context of the usage specifically indicates that a more restrictive meaning for the capitalized term is intended. However, the capitalization or lack thereof within the remainder of this document is not intended to be necessarily limiting unless the context clearly indicates that such limitation is intended.

Overview Aspects of the present disclosure generally relate to systems and methods for encryption/decryption based on liveness-verified biometric data that cannot be stolen/spoofed.

In various embodiments, the disclosed system facilitates encryption/decryption of data through controlling access to encryption/decryption keys via liveness-verified biometric data (e.g., data that has been verified as derived from the correct actual live individual to avoid bad actors spoofing the data to gain access to the encryption/decryption keys). Liveness-verified biometric data may, in various embodiments, be derived from facial features, fingerprints, voice recognition, DNA, etc.

Generally, the disclosed system improves the robustness and security of encryption/decryption systems by ensuring that only the proper authorized individuals can access the system (with credentials that cannot be stolen or spoofed).

Generally, in one embodiment, the system requests that an individual who desires to encrypt/decrypt data take a photo/video of his/her face for liveness verification (e.g., determining whether the photo/video has been spoofed or is of an actual live individual). In various embodiments, the system may determine if a photo/video has been spoofed via techniques described in U.S. patent application Ser. No. 15/782,940, entitled “Systems and Methods for Passive-Subject Liveness Verification in Digital Media,” filed on Oct. 13, 2017, the entire disclosure of which is herein incorporated by reference. Once liveness of the photo/video is confirmed, in one embodiment, a biometric hash of the individual's face (e.g., a hash of the prominent facial features of the individual, generated by running a representation of the features through a cryptographic hashing algorithm, such as, but not limited to, SHA-1, MD-5, etc.) is generated for identity verification of the individual through a comparison to one or more stored biometric hashes corresponding to the individual. In one embodiment, if the identity of the individual is verified, then the individual is provided access to the relevant encryption/decryption keys. Generally, if the liveness and identity of the requesting individual cannot be verified, then the individual will not be permitted to encrypt/decrypt data using the system. In this manner, the disclosed system improves the security of the encrypted data by allowing access only to a live individual with authorized biometric features, resulting in access credentials that cannot be stolen/spoofed.

For example, consider a scenario where a user at a mobile phone is sending an email. Rather than allowing for the user to send the email simply because he/she has unlocked/logged-into the mobile phone, the systems and methods discussed herein may verify the user's identity prior to sending the email, thus preventing an unauthorized party from sending an email under the user's identity. Furthermore, the systems and methods discussed herein may encrypt the email prior to transmitting the email to the recipient, and the email may only be decrypted if the recipient's identity is also verified (via liveness verification). Accordingly, the systems and methods discussed herein allow for a trusted environment for sending data, such as emails, safely.

The system generally places no limitations on the types of data that may be encrypted/decrypted (e.g., data in motion, in rest, documents, images, videos, etc.). Further, the system places no limitations on the types of encryption/decryption that may be conducted on that data. Generally, encryption is performed by inputting the original data and a key into a cryptographic algorithm such as, but not limited to, Advanced Encryption Standard (AES), RSA, Blowfish, etc., to generate an encrypted output of the original data, generally in ciphertext. Decryption is generally performed by inputting the encrypted output and a key into the cryptographic algorithm to generate a decrypted version of the encrypted output, generally corresponding to the original data.

EXEMPLARY EMBODIMENTS

Referring now to the figures, for the purposes of example and explanation of the fundamental processes and components of the disclosed systems and methods, reference is made toFIG. 1, which illustrates an exemplary architecture100of one embodiment of the present disclosure. As will be understood and appreciated, the exemplary architecture100shown inFIG. 1represents merely one approach or embodiment of the present system, and other aspects are used according to various embodiments of the present system. Generally, the disclosed system100facilitates encryption/decryption of data through controlling access to encryption/decryption keys via liveness-verified biometric data. Liveness-verified biometric data may, in various embodiments, be derived from facial features, fingerprints, voice recognition, DNA, or any other individual-specific/unique biometric data.

In various embodiments, the disclosed system100includes an electronic computing device101operatively connected to an encryption/decryption management system103(including a system database105) and a third party system107via a network109for encryption/decryption based on liveness-verified biometric data that cannot be stolen/spoofed.

For example, in one practical application and non-limiting embodiment, an individual wants to send an encrypted email using his/her cell phone101. Generally, the individual drafts the email and, when ready to send the drafted email, chooses to encrypt the email according to the techniques discussed in the present disclosure. In one embodiment, the phone101requests that that the individual take a photo/video of his/her face for liveness verification (e.g., determining whether the photo/video has been spoofed or is of a live individual). Once liveness of the photo/video is confirmed, in one embodiment, a biometric hash of the individual's face (e.g., a hash of the prominent facial features of the individual, generated by running a representation of the features through a cryptographic hashing algorithm) is generated by the phone101for identity verification of the individual through a comparison to one or more stored biometric hashes corresponding to the individual from the phone101and/or encryption/decryption management system103. In one embodiment, if the identity of the individual is verified, then the email is encrypted using an encryption key from the encryption/decryption management system103(in one embodiment, the public key of the intended recipient, also a user of the encryption/decryption management system103) and transmitted to the third party system107corresponding to the recipient of the email. Generally, if the liveness and identity of the sender cannot be verified, then the individual will not be permitted to encrypt the email, the attempt will be logged, etc. In this manner, the disclosed system improves the security of the encrypted email by allowing only a live individual with authorized biometric features to encrypt the email.

Similarly, in one non-limiting embodiment, the recipient of the encrypted email who wants to read it using his/her cell phone101will request decryption of the email. In one embodiment, the phone101requests that that the individual take a photo/video of his/her face for liveness verification (e.g., determining whether the photo/video has been spoofed or is of a live individual). Once liveness of the photo/video is confirmed, in one embodiment, a biometric hash of the individual's face (e.g., a hash of the prominent facial features of the individual, generated by running a representation of the features through a cryptographic hashing algorithm) is generated by the phone101for identity verification of the individual through a comparison to one or more stored biometric hashes corresponding to the individual from the phone101and/or the encryption/decryption management system103. In one embodiment, if the identity of the individual is verified, then the email is decrypted using a decryption key from the encryption/decryption management system103(in one embodiment, the private key corresponding to the recipient) so that the recipient can read the email on his/her phone101. Generally, if the liveness and identity of the recipient cannot be verified, then the individual will not be permitted to decrypt the email. In this manner, the disclosed system improves the security of the encrypted email by allowing access only to a live individual with authorized biometric features (e.g., the intended recipient), resulting in access credentials that cannot be stolen/spoofed.

The system generally places no limitations on the types of data that may be encrypted/decrypted (e.g., data in motion, in rest, documents, videos, images, etc.). Further, the system places no limitations on the types of encryption/decryption that may be conducted on that data. Generally, encryption is performed by inputting the original data and a key into a cryptographic algorithm such as, but not limited to, AES, RSA, Blowfish, etc., to generate an encrypted output of the original data, generally in ciphertext. Decryption is generally performed by inputting the encrypted output and a key into the cryptographic algorithm to generate a decrypted version of the encrypted output, generally corresponding to the original data.

Generally, the electronic computing device101is any device that is capable of performing the functionality disclosed herein (e.g., desktop computer, laptop computer, tablet computer, smartphone, smartwatch, camera, video camera, image capture device, etc.). In various embodiments, the electronic computing device101communicates via network109with the encryption/decryption management system103and the third party system107as part of the system process200(to be discussed herein). In one embodiment, the electronic computing device101is the device through which the user is attempting to encrypt/decrypt data and via which the image is taken for which liveness verification is requested and from which the liveness-verified biometric data is derived. In one embodiment, the electronic computing device101has a camera or other image capture device and takes the image in real time with the request to encrypt/decrypt data.

Generally, the encryption/decryption management system103may be any computing device (e.g., desktop computer, laptop, servers, tablets, etc.), combination of computing devices, software, hardware, or combination of software and hardware that is capable of performing the functionality disclosed herein. In various embodiments, the encryption/decryption management system103is operatively connected to the electronic computing device101via the network109to conduct the processes/analyses disclosed herein. In one embodiment, the encryption/decryption management system103further includes the system database105. Generally, the system database105may be any computing device (e.g., desktop computer, laptop, servers, tablets, etc.), combination of computing devices, software, hardware, combination of software and hardware, database (e.g., stored in the cloud or on premise, structured as relational, etc.), or combination of databases that is capable of performing the functionality disclosed herein. In one embodiment, the system database105is local to the encryption/decryption management system103(e.g., the encryption/decryption management system103includes the system database105, etc.). In other embodiments, the system database105is virtual or stored in the “cloud.” In one embodiment, the system database105includes biometric hashes and keys for encryption/decryption.

Generally, the third party system107may be any computing device (e.g., desktop computer, laptop, servers, tablets, etc.), combination of computing devices, software, hardware, or combination of software and hardware that is capable of performing the functionality disclosed herein. In various embodiments, the third party system107communicates via network109with the electronic computing device101as part of the system process200. In one embodiment, the third party system107receives encrypted data from the electronic computing device101. In one embodiment, the third party system107facilitates confirmation of the identity of the user of the electronic computing device101.

Generally, the network109may be any connection capable of transferring data between two or more computer systems (e.g., a secure or unsecured connection, Bluetooth, wireless or wired local-area networks (LANs), cell network, the Internet, etc.).

FIG. 2is a flowchart showing an exemplary system process200, according to one embodiment of the present disclosure. As will be understood by one having ordinary skill in the art, the steps and processes shown inFIG. 2(and those of all other flowcharts and sequence diagrams shown and described herein) may operate concurrently and continuously, are generally asynchronous and independent, and are not necessarily performed in the order shown. Generally, the exemplary system process200is the process by which encryption/decryption is performed on previously-generated data based on liveness-verified biometric data that cannot be stolen/spoofed.

In various embodiments, the exemplary system process200begins at step102, wherein the system requests an image/video for liveness verification after an individual has attempted to access the system. The user requesting encryption/decryption will take the requested image/video (e.g., using the electronic computing device101to take a photo/video of the user's face, moving the electronic computing device101as instructed to change the perspective of the photo/video, performing any other acts as instructed, etc.), wherein the system receives it at step104. Generally, the system conducts a liveness verification process201on the received image/video to determine whether it is of a live individual (e.g., hasn't been spoofed) using various algorithms (e.g., machine learning algorithms, etc.). Further details of the liveness verification process201are discussed in U.S. patent application Ser. No. 15/782,940, entitled “Systems and Methods for Passive-Subject Liveness Verification in Digital Media,” filed Oct. 13, 2017, the entire disclosure of which is herein incorporated by reference.

After the liveness verification process201, the system determines, at step106, whether the received image/video is of a live individual. If liveness is not verified, then the exemplary system process200ends thereafter. If, however, liveness is verified, then the system proceeds, at step108, to generate a biometric hash based on the received image/video (e.g., a hash of the prominent facial features of the individual, generated by running a representation of the features through a cryptographic hashing algorithm, such as, but not limited to, SHA-1, MD-5, etc.). In certain embodiments, if liveness is not verified at step106, rather than the process200ending, the system may perform other actions such as logging the liveness verification attempt, prompting the user to retake the picture or video, generating an alert corresponding to the failed liveness verification, etc.

In various embodiments, after generating the biometric hash at step108, the system determines, at step110, whether the biometric hash matches any known individual associated with the device that generated the received image/video (e.g., whether the individual in the photograph is an authorized user of the device and/or system) by comparing the generated biometric hash to any biometric hashes stored on the device. In one embodiment, the generated biometric hash is compared to any biometric hashes stored at the server or in the cloud. As will be appreciated by one having ordinary skill in the art, the generated biometric hash, generated from biometric features that may be slightly different due to the physical conditions of the photograph (e.g., lighting, resolution, etc.), may not be identical to the stored biometric hash. Thus, in one embodiment, the system may permit biometric hashes within a certain threshold to be considered a match (e.g., 90% likelihood of match, 80%, etc.), wherein the threshold depends on the level of security appropriate for the system. In one embodiment, if the threshold is not met, then the user may be prompted to take the photo/video again.

If the generated biometric hash does not match the stored biometric hash (e.g., the user is not authorized, the device has not been registered with the system so no biometric hashes are stored on the device, the user has not been registered with the system so no biometric hashes are stored on the device, etc.), then, in one embodiment, the system proceeds to the account creation/device association process300, wherein the identity of the user is confirmed and an account is created or the device that the user is operating is added to the user's account (further details of which will be discussed in association with the description ofFIG. 3). If the generated biometric hash does match the stored biometric hash (e.g., the user is authorized to encrypt/decrypt data using that device), then, in one embodiment, the system determines, at step112, if encryption or decryption of data has been requested.

Thus, in one embodiment, if encryption of data has been requested, then the system proceeds to the message encryption process400to encrypt the data (further details of which will be discussed in association with the description ofFIG. 4). If, however, in one embodiment, decryption of data has been requested, then the system proceeds to the message decryption process500to decrypt the data (further details of which will be discussed in association with the description ofFIG. 5). Generally, although processes400and500refer to encryption/decryption of messages, the system places no limitations on the types of data that may be encrypted/decrypted (e.g., data in motion, in rest, etc.) and messages are referred to herein for ease of discussion.

After the account creation/device association process300, the message encryption process400, or the message decryption process500is complete, the exemplary system process200ends thereafter.

FIG. 3(consisting ofFIGS. 3A and 3B) is a flowchart showing an exemplary account creation/device association process300, according to one embodiment of the present disclosure. Generally, because each device that a user uses should be registered with the system, the exemplary account creation/device association process300is the process by which the identity of the user is confirmed and an account is created or the device that the user is operating is added to the user's account. In various embodiments,FIG. 3Agenerally corresponds to the device perspective of the exemplary account creation/device association process300(e.g., steps occurring on the electronic computing device101, fromFIG. 1).FIG. 3B, in various embodiments, generally corresponds to the server perspective of the exemplary account creation/device association process300(e.g., steps occurring on the encryption/decryption management system103, fromFIG. 1). In various embodiments, the exemplary account creation/device association process300begins at step302, wherein the system optionally confirms the identity of the user by comparing the received photo/video to a government photo identification document (e.g., passport, driver's license, etc.) provided by the user. Generally, if identity confirmation is desired, the user is prompted to take a photograph of a government ID. The photograph is scanned to compare the individual in the received photo/video to the image in the government ID. In one embodiment, the system may be configured to only proceed to step304if identity is confirmed, instead terminating the exemplary account creation/device association process300if identity cannot be confirmed.

At step304, in one embodiment, the device transmits the generated biometric hash to the server for generation of an account or association of the device with a previously-generated account. Thus, at step306(shown inFIG. 3B), the server receives the generated biometric hash from the device and, at step308, compares the generated biometric hash with the biometric hashes associated with previously-generated accounts to determine whether an account already exists for the user. Generally, the server determines, at step310, whether a match has been found for the generated biometric hash. If a match is not found, then the server proceeds at step312to generate an account for the user (e.g., storing the individual's data, affiliating the individual with an appropriate entity, etc.). If a match was found at step310and after generating an account at step312, the server, at step314in various embodiments, generates at least two device private keys that will serve as private keys in a public-private key encryption/decryption infrastructure, wherein the generated biometric hash is the public key, as well as serving as identifiers for the user/device combination. Accordingly, at step316, the server stores one of the device private keys (e.g., in the system database105) in association with the user's account. In one embodiment, at step316, the server also stores the generated biometric hash in association with the user's account. At step318, the server transmits a different device private key to the device. As will occur to one of ordinary skill in the art, the server may generate more than two device private keys, storing half and transmitting half, to increase the security of the system by permitting key rotation.

Generally, at step320(shown inFIG. 3A), the device receives the different device private key from the server and, at step322, stores the different device private key and generated biometric hash on the device. Thus, the exemplary account creation/device association process300ends thereafter.

FIG. 4(consisting ofFIGS. 4A and 4B) is a flowchart showing an exemplary message encryption process400, according to one embodiment of the present disclosure. Generally, the exemplary message encryption process400is the process by which data is encrypted using the generated biometric hash. In various embodiments,FIG. 4Agenerally corresponds to the device perspective of the exemplary message encryption process400(e.g., steps occurring on the electronic computing device101, fromFIG. 1).FIG. 4B, in various embodiments, generally corresponds to the server perspective of the exemplary message encryption process400(e.g., steps occurring on the encryption/decryption management system103, fromFIG. 1). In one embodiment, the exemplary message encryption process400may be used to encrypt any data (e.g., documents, photos, songs, videos, files, etc.) or batches of data and not just messages.

In various embodiments, the exemplary message encryption process400begins at step402, wherein the device compares the generated biometric hash with the biometric hash stored on the device (e.g., at step322fromFIG. 3) to determine whether the user is authorized to encrypt data using the device. If the device determines, at step404in one embodiment, that the generated biometric hash does not match the stored biometric hash within a certain predefined threshold (e.g., depending on the level of certainty/security required, indicating the user is not authorized to encrypt data using the device), then the exemplary encryption process400ends thereafter. If, however, at step404in one embodiment, the device determines that the generated biometric hash matches the stored biometric hash within a certain predefined threshold (e.g., indicating that the user is authorized to encrypt data using the device), then, at step406, the device generally transmits the generated biometric hash to the server.

At step408(as shown inFIG. 4B), in various embodiments, the server receives the generated biometric hash from the device. In one embodiment, at step410, the server compares the generated biometric hash to the biometric hash stored on the server (e.g., at step316fromFIG. 3). If the server determines, at step412in one embodiment, that the generated biometric hash and the stored biometric hash match within a predetermined threshold (e.g., the user is authorized to encrypt data using the device), then the server proceeds to step414, wherein, in one embodiment, the server transmits an encryption authorization token (or other form of confirmation) to the device. If, however, the server determines, at step412in one embodiment, that the generated biometric hash and the stored biometric hash do not match (e.g., the user is not authorized to encrypt data using the device), then the server proceeds to step416, wherein, in one embodiment, the server transmits an encryption rejection message to the device, logs the rejection, otherwise denies access to the device, or take another action.

Thus, at step418(shown inFIG. 4A), the device generally receives the encryption authorization token or encryption rejection message from the server. If the device receives an encryption authorization token, then, in one embodiment, the device encrypts the requested data (e.g., email, file, batch of files, etc.) using the biometric hash stored on the device (or, as appropriate, the public key/biometric hash of the intended recipient of the data) and takes the appropriate action with the encrypted data (e.g., transmitting the email, storing the encrypted files, etc.). In one embodiment, the device may embed the ciphertext of the encrypted email in the email that it sends so that the recipient does not have to log into a separate system to access the mail. In various embodiments, after encrypting the data at step420or after receiving an encryption rejection message at step418, the exemplary message encryption process400ends thereafter.

FIG. 5(consisting ofFIGS. 5A and 5B) is a flowchart showing an exemplary message decryption process, according to one embodiment of the present disclosure. Generally, the exemplary message decryption process500is the process by which data is decrypted using the private key stored on the device. In various embodiments,FIG. 5Agenerally corresponds to the device perspective of the exemplary message decryption process500(e.g., steps occurring on the electronic computing device101, fromFIG. 1).FIG. 5B, in various embodiments, generally corresponds to the server perspective of the exemplary message decryption process500(e.g., steps occurring on the encryption/decryption management system103, fromFIG. 1).

In various embodiments, the exemplary message decryption process500begins at step502, wherein the device compares the generated biometric hash with the biometric hash stored on the device (e.g., at step322fromFIG. 3) to determine whether the user is authorized to decrypt data using the device. If the device determines, at step504in one embodiment, that the generated biometric hash does not match the stored biometric hash within a certain predefined threshold (e.g., depending on the level of certainty/security required, indicating the user is not authorized to decrypt data using the device, the user is not authorized to decrypt that data, etc.), then the exemplary decryption process500ends thereafter (or, in various embodiments, the system logged the denied decryption attempt, prompts the user to take another photo, etc.). If, however, at step504in one embodiment, the device determines that the generated biometric hash matches the stored biometric hash within a certain predefined threshold (e.g., indicating that the user is authorized to decrypt data using the device, the user is authorized to decrypt that data, etc.), then, at step506, the device generally transmits the generated biometric hash to the server.

At step508(shown inFIG. 5B), in various embodiments, the server receives the generated biometric hash from the device. In one embodiment, at step510, the server compares the generated biometric hash to the biometric hash stored on the server (e.g., at step316fromFIG. 3). If the server determines, at step512in one embodiment, that the generated biometric hash and the stored biometric hash match (e.g., the user is authorized to decrypt data using the device, the user is authorized to decrypt that data, etc.), then the server proceeds to step514, wherein, in one embodiment, the server transmits a decryption authorization token (or other form of confirmation) to the device. If, however, the server determines, at step512in one embodiment, that the generated biometric hash and the stored biometric hash do not match (e.g., the user is not authorized to decrypt data using the device, the user is not authorized to decrypt that data), then the server proceeds to step516, wherein, in one embodiment, the server transmits an decryption rejection message to the device.

Thus, at step518, the device generally receives the decryption authorization token or decryption rejection message from the server. If the device receives a decryption authorization token, then, in one embodiment, the device decrypts the requested data (e.g., email, file, batch of files, etc.) using the private key stored on the device (e.g., at step322fromFIG. 3) and takes the appropriate action with the decrypted data (e.g., displaying the email, etc.). In various embodiments, after decrypting the data at step520or after receiving a decryption rejection message at step518, the exemplary message decryption process500ends thereafter.

From the foregoing, it will be understood that various aspects of the processes described herein are software processes that execute on computer systems that form parts of the system. Accordingly, it will be understood that various embodiments of the system described herein are generally implemented as specially-configured computers including various computer hardware components and, in many cases, significant additional features as compared to conventional or known computers, processes, or the like, as discussed in greater detail herein. Embodiments within the scope of the present disclosure also include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media can be any available media which can be accessed by a computer, or downloadable through communication networks. By way of example, and not limitation, such computer-readable media can include various forms of data storage devices or media such as RAM, ROM, flash memory, EEPROM, CD-ROM, DVD, or other optical disk storage, magnetic disk storage, solid state drives (SSDs) or other data storage devices, any type of removable non-volatile memories such as secure digital (SD), flash memory, memory stick, etc., or any other medium which can be used to carry or store computer program code in the form of computer-executable instructions or data structures and which can be accessed by a computer.

When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a computer-readable medium. Thus, any such a connection is properly termed and considered a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions include, for example, instructions and data which cause a computer to perform one specific function or a group of functions.

Those skilled in the art will understand the features and aspects of a suitable computing environment in which aspects of the disclosure may be implemented. Although not required, some of the embodiments of the claimed inventions may be described in the context of computer-executable instructions, such as program modules or engines, as described earlier, being executed by computers in networked environments. Such program modules are often reflected and illustrated by flow charts, sequence diagrams, exemplary screen displays, and other techniques used by those skilled in the art to communicate how to make and use such computer program modules. Generally, program modules include routines, programs, functions, objects, components, data structures, application programming interface (API) calls to other computers whether local or remote, etc. that perform particular tasks or implement particular defined data types, within the computer. Computer-executable instructions, associated data structures and/or schemas, and program modules represent examples of the program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.

Those skilled in the art will also appreciate that the claimed and/or described systems and methods may be practiced in network computing environments with many types of computer system configurations, including personal computers, smartphones, tablets, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, networked PCs, minicomputers, mainframe computers, and the like. Embodiments of the claimed invention are practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

An exemplary system for implementing various aspects of the described operations, which is not illustrated, includes a computing device including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The computer will typically include one or more data storage devices for reading data from and writing data to. The data storage devices provide nonvolatile storage of computer-executable instructions, data structures, program modules, and other data for the computer.

Computer program code that implements the functionality described herein typically includes one or more program modules that may be stored on a data storage device. This program code, as is known to those skilled in the art, usually includes an operating system, one or more application programs, other program modules, and program data. A user may enter commands and information into the computer through keyboard, touch screen, pointing device, a script containing computer program code written in a scripting language or other input devices (not shown), such as a microphone, etc. These and other input devices are often connected to the processing unit through known electrical, optical, or wireless connections.

The computer that effects many aspects of the described processes will typically operate in a networked environment using logical connections to one or more remote computers or data sources, which are described further below. Remote computers may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically include many or all of the elements described above relative to the main computer system in which the inventions are embodied. The logical connections between computers include a local area network (LAN), a wide area network (WAN), virtual networks (WAN or LAN), and wireless LANs (WLAN) that are presented here by way of example and not limitation. Such networking environments are commonplace in office-wide or enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN or WLAN networking environment, a computer system implementing aspects of the invention is connected to the local network through a network interface or adapter. When used in a WAN or WLAN networking environment, the computer may include a modem, a wireless link, or other mechanisms for establishing communications over the wide area network, such as the Internet. In a networked environment, program modules depicted relative to the computer, or portions thereof, may be stored in a remote data storage device. It will be appreciated that the network connections described or shown are exemplary and other mechanisms of establishing communications over wide area networks or the Internet may be used.

While various aspects have been described in the context of a preferred embodiment, additional aspects, features, and methodologies of the claimed inventions will be readily discernible from the description herein, by those of ordinary skill in the art. Many embodiments and adaptations of the disclosure and claimed inventions other than those herein described, as well as many variations, modifications, and equivalent arrangements and methodologies, will be apparent from or reasonably suggested by the disclosure and the foregoing description thereof, without departing from the substance or scope of the claims. Furthermore, any sequence(s) and/or temporal order of steps of various processes described and claimed herein are those considered to be the best mode contemplated for carrying out the claimed inventions. It should also be understood that, although steps of various processes may be shown and described as being in a preferred sequence or temporal order, the steps of any such processes are not limited to being carried out in any particular sequence or order, absent a specific indication of such to achieve a particular intended result. In most cases, the steps of such processes may be carried out in a variety of different sequences and orders, while still falling within the scope of the claimed inventions. In addition, some steps may be carried out simultaneously, contemporaneously, or in synchronization with other steps.