US20210334808A1 - Identity management service using a blockchain providing certifying transactions between devices - Google Patents

Abstract

Logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device. The first transaction number was received from a distributed public database in response to a transmission, from the second remote device, of a signed hash value and a first public key associated with a first private key on the second remote device. The signed hash value was created by signing a hash value with the first private key and the hash value was generated by hashing the personal data with a hashing algorithm on the second remote device. The logic uses the first transaction number to retrieve the signed hash value and the first public key from the distributed public database. The logic hashes the personal data using the hashing algorithm to create a generated hash value and verifies the signed hash value against the generated hash value.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application is a continuation of U.S. patent application Ser. No. 16/870,927, filed May 9, 2020, entitled “Identity Management Service Using a Blockchain Providing Certifying Transactions Between Devices,” which is a continuation of U.S. patent application Ser. No. 15/640,795, filed Jul. 3, 2017, entitled “Identity Management Service Using a Blockchain Providing Certifying Transactions Between Devices,” now U.S. Pat. No. 10,657,532, which is a continuation of U.S. patent application Ser. No. 15/146,881, filed May 4, 2016, entitled “Identity Management Service Using a Blockchain Providing Certifying Transactions Between Devices,” now U.S. Pat. No. 9,722,790, which claims priority to and the benefit of U.S. Provisional Patent Application No. 62/157,256, filed May 5, 2015, entitled “User Identification Management System and Method,” and which claims priority to and the benefit of U.S. Provisional Patent Application No. 62/304,934, filed Mar. 7, 2016, entitled “Identity Management Service Using a Blockchain,” each of which is herein incorporated by reference in its entirety.
BACKGROUND
• The present invention generally relates to systems and methods for managing the identity of users and of identifying those users to third parties. Identity theft causes tens of billions of dollars in losses every year.
• In an effort to combat identity theft, systems and methods for identifying users to third parties have been developed. In a common two factor application, a user presents a bank card or credit card in addition to the personal identification number (“PIN”) corresponding to the card. In other systems, a user provides a password to identify himself/herself and may be given a Short Message Service (SMS) text message with a unique code that the user must recite for access. In still other systems, a user may be given challenge questions to verify his/her identity. Each of these systems, however, is subject to attack and ultimate defeat from a basic security breach.
• It would be advantageous to have a more secure system and method for managing the identity of users and of identifying users to third parties.
SUMMARY
• In an example embodiment, a method is described. According to the method, logic on a first remote device receives a first transaction number and personal data transmitted from a second remote device. The first transaction number was received from a distributed public database in response to a transmission, from the second remote device, of a signed hash value and a first public key associated with a first private key on the second remote device. The signed hash value was created by signing a hash value with the first private key and the hash value was generated by hashing the personal data with a hashing algorithm on the second remote device. The logic on the first remote device uses the first transaction number to retrieve the signed hash value and the first public key from the distributed public database. The logic hashes the personal data using the hashing algorithm to create a generated hash value. The logic then verifies that the hash value in the retrieved signed hash value is the same as the generated hash value and verifies that the retrieved signed hash value was signed with the first private key. Then the logic creates a certification.
• In another example embodiment, another method is described. According to the method, logic on a first smartphone receives a first transaction number and personal data transmitted from a second smartphone. The first transaction number was received from a block chain database in response to a transmission, from the second smartphone, of a signed hash value and a first public key associated with a first private key on the second smartphone. The signed hash value was created by signing a hash value with the first private key and the hash value was generated by hashing the personal data with a hashing algorithm on the second smartphone. The logic on the first smartphone uses the first transaction number to retrieve the signed hash value and the first public key from the block chain database. The logic hashes the personal data using the hashing algorithm to create a generated hash value. The logic then verifies that the hash value in the retrieved signed hash value is the same as the generated hash value and verifies that the retrieved signed hash value was signed with the first private key. Then the logic creates a certification.
• In another example embodiment, another method is described. According to the method, logic on a first smartphone receives a first transaction number and personal data transmitted from a second smartphone. The receiving involves scanning a barcode or QR code. The first transaction number was received from a block chain database in response to a transmission, from the second smartphone, of a signed hash value and a first public key associated with a first private key on the second smartphone. The signed hash value was created by signing a hash value with the first private key and the hash value was generated by hashing the personal data with a hashing algorithm on the second smartphone. The logic on the first smartphone uses the first transaction number to retrieve the signed hash value and the first public key from the block chain database. The logic hashes the personal data using the hashing algorithm to create a generated hash value. The logic then verifies that the hash value in the retrieved signed hash value is the same as the generated hash value and verifies that the retrieved signed hash value was signed with the first private key. Then the logic creates a certification.
• Other aspects and advantages of the inventions will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate by way of example the principles of the inventions.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1A shows a simplified block diagram of a system and method for sealing an identity of a person in a public storage facility.
• FIG. 1B also shows a simplified block diagram of a system and method for sealing an identity of a person in a public storage facility.
• FIG. 1C shows a simplified block diagram of a system and method for sealing any input data in a public storage facility.
• FIG. 2A shows a simplified block diagram of a system and method for certifying an identity of a person.
• FIGS. 2B-1 and 2B-2 show a process for verifying hashed input data and a digital signature.
• FIG. 2C shows a simplified block diagram for recording an acknowledgement.
• FIG. 3A shows a simplified block diagram of a system and method for verifying an acknowledgement record.
• FIG. 3B shows a flowchart diagram for a method for verifying an acknowledgement record and its underlying certification record.
• Corresponding reference characters indicate corresponding parts throughout the drawings.
DETAILED DESCRIPTION
• In the following description, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments. However, it will be apparent to one skilled in the art that the example embodiments may be practiced without some of these specific details. In other instances, process operations and implementation details have not been described in detail, if already well known.
• FIG. 1A shows a simplified block diagram for asystem100 and method for managing the identity of a user by way of making verifiable transactions with apublic storage facility128. By way of example, anidentification card102 may be used. In other embodiments, other forms of identification, which may be digital or non-digital may be used. In the example of theidentification card102,personal data104 is contained thereon, which identifies the user. The personal data can include aphoto106 of the user; the user's name, address anddriver license number108, and/or abar code110 or similar computer code for storing, scanning and/or retrieving additional data. Such coding can include PDF417 codes, QR codes, and other such codes. However, it is not necessary to have such code and the identification card may only have human-readable text strings. As noted above, theidentification card102 may also take a physical or a digital form and the information can be retrieved either through scanning a code as described, performing Optical Character Recognition (OCR) on text strings, digitally transferring a digital identification card from one system to another, manually inputting the information using a keyboard, manually inputting the information using voice recognition, etc., in example embodiments.
• Theidentification card102 can be a government issued form of identification such as a driver license, passport, employee badge, military identification, political documentation, or the like. Theidentification card102 can also be a privately issued form of identification such as a student ID, library card, social club card, or any other form of identification issued by a third party.
• In one embodiment, as indicated bytriangle114, aninput device112 may be used to input such personal data from theidentification card102 to provide input data.Input device112 can take many forms. For example,input device112 can be a digital scanner, digital camera, or smartphone (e.g., with the camera commonly found in smartphones) for reading data from theidentification card102, including any codes appearing on thecard102. Theinput device112 can also be a device for manually inputting personal data such as a keyboard, touchscreen, voice recognition device, handwriting recognition device, or other manual input device.
• As shown inFIG. 1A, the input data can be optionally encrypted byencryption logic118 and securely stored inoperation119b. In one implementation, the input data is transferred directly to hashinglogic120, without passing throughencryption logic118. For ease of understanding, the operations of theoptional encryption logic118 will be discussed first, and then the operations processed by the hashinglogic120. As such, the process may proceed directly from receiving the user information via112 to the hashinglogic120.
• The input data collected from the input device112 (e.g., a user's smartphone) is passed toencryption logic118 oninput device112. In an example embodiment,encryption logic118 might include software, firmware, hardware, or any combination thereof, and consist of one or more encryption algorithms, e.g., an RSA encryption algorithm.Encryption logic118 encrypts the input data with a public key to provide encrypted data. The public key is paired with an associated private key as is conventional when generating such keys using an RSA encryption algorithm, an Elliptic Curve Digital Signature Algorithm (ECDSA), or other encryption algorithm known to those skilled in the art. As shown inoperation119b, this encrypted data can then be stored locally on theinput device112 for added security. It can then only be accessed with the private key of the user on theinput device112, which might be stored in a more secure part ofinput device112, e.g., “the Keychain”, inoperation119a, ifinput device112 is an iOS (e.g., operating system used by devices made by Apple, Inc.) smartphone. If the device is of a different type, e.g., one using an Android OS (e.g., operating system by Google, Inc.), similar secure device storage methods may be used. In this manner, for added security, the private key is not compromised and is kept safely on theinput device112. It should be understood that the private key may be stored on another device, but similar or additional security should be processed to ensure that the private key is not compromised.
• As noted above, the operations to be performed by the hashinglogic120 can proceed directly after receiving the input data from theinput device112. In this embodiment, the hashinglogic120 is used for hashing the input data (e.g., personal information collected) to provide or generate a hash value. The hash value is sometimes referred to as “hash data,” that is generated by an algorithm. In an example embodiment, hashinglogic120 might be software, firmware, hardware, or any combination thereof, and consist of one or more hashing algorithms, e.g., a Secure Hash Algorithm (SHA) algorithm. Hashinglogic120 passes the hash value to digital-signature logic121, which performs a digital signature on the hash value, using the private key on theinput device112. In an example embodiment, digital-signature logic121 might be a component (or module) ofencryption logic118. In other embodiments, the digital-signature logic121 may be defined by separate code, firmware, and/or hardware.
• In one embodiment, the digital-signature logic121 then passes the signed hash value and the public key to a user accessible interface126 (e.g., a graphical user interface or GUI), which might be other software running on theinput device112. In an example embodiment, the useraccessible interface126 might be part of an application or app that includesencryption logic118, hashinglogic120, and digital-signature logic121, and/or other modules or code. The useraccessible interface126 might be used by the user to transmit the digitally signed hash value and the public key to apublic storage facility128 via aline130, and receive back from the public storage facility128 atransaction number132 corresponding to the transmitted hash value and public key. As used in this disclosure, a “line” might be part of a wired and/or wireless connection or network, including a bus, an intranet, an internet, an extranet, a public computer network, a private computer network, etc., in an example embodiment. In an alternative example embodiment, only the signed hash value might be transmitted topublic storage facility128 by the user and persons retrieving the signed hash value might obtain the public key from elsewhere (e.g., the user, a public database, an Internet repository, a website, etc.). As is well known, there is no need to keep public keys secure, and in fact, the algorithms using public/private key pairs are designed to enable full sharing of public keys. The private key, on the other hand, must be kept secure, as noted above.
• In one embodiment, thepublic storage facility128 can take the form of a block chain (e.g., in a bitcoin online payment system) or any other public or private distributed database. Thepublic storage facility128 is connected to a communication link via a line and can be adapted to communicate over a public computer network, the internet, an intranet, an extranet, or any private communication network. Broadly speaking, thepublic storage facility128 is accessible by any device that has an Internet connection over a network. A block chain, as is known in the art, is a system that enables users' access to securely store data in a public place. The data is deemed secure, as each time data is written, the written data is dependent on previously written data, which includes performing cryptographic hash operations. A benefit of using a block chain is that once data is written to the block chain and a block chain transaction is created, that transaction remains intact, and can be verified in the future. The reason for this, is that data is continually written to the block chain, e.g., after a particular transaction is made, and that later data is dependent on an earlier particular transaction. Consequently, by writing data to a public storage facility that implements a public block chain, later verification of that data is practically ensured to be correct.
• As indicated above, in an example embodiment, the input data might be hashed and the resulting hash value might be signed with a digital signature, created using a private key paired with a public key, before transmission, optionally along with the public key, from the input device (e.g., a user's smartphone)112 to thepublic storage facility128 for storage. The useraccessible interface126 is thus adapted to “seal” the signed hash value and the public key in thepublic storage facility128. In one embodiment, once the hash value, and optionally the public key of the user is written to the block chain in a transaction, a later verification may be made if another party is able to hash the same input data.
• As depicted inFIG. 1B, user accessible interface126 (e.g., a GUI) can be controllable by the user of theinput device112 to encrypt and provide thetransaction number132, the input data, and, optionally, the public key of the user, to an input device142 (e.g., a smartphone) of a third party (e.g., a financial institution or other entity engaging in a commercial, private transaction, or other transaction with the user) to, for example, establish the identity of the user. In one embodiment, the third party will access the block chain using thetransaction number132 to retrieve the digitally signed hash value, and optionally, the public key if the public key has not been previously obtained by the third party from another source/location, and enable comparison with a hash value that is generated by the third party using the input data and the same hashing algorithm. In one embodiment, a distributed public database is a block chain, which receives data for storage from a plurality of entities. The entities need not be related, and the type of data need not be the same. In general, entities storing the block chain are unrelated, and the type of data can vary to almost any type of digital data, e.g., not limited to identity data, commercial data, bitcoin data, etc. Thus, the data received for storage is configured to be processed to generate a transaction record that is dependent on previous data stored to the block chain. The transaction record being dependent on previous data stored to the block chain ensures that data stored to the block chain is not modifiable, as each later data stored to the block chain continues to be dependent on previous data stored to the block chain.
• In an example embodiment, the encryption of thetransaction number132, the input data, and, optionally, the public key of the user might be performed by theencryption logic118 using a public key of a third party paired with a private key of the third party. Then, codinglogic150 on theinput device112 might code the encrypted items into a barcode or QR code and the third party might useinput device142 to scan the barcode or QR code and decode it to gain access to the encrypted items. Thereafter, the third party might decrypt the encrypted items using the private key of the third party to perform a verification operation. In one embodiment, the verification may use an RSA algorithm as explained in further detail below. Other verification algorithms may also be used, depending on the configured implementation.
• FIG. 1C shows a simplified block diagram of a system and method for sealing any input data in a public storage facility. As noted above, the operations to be performed by the hashinglogic120 can proceed directly after receiving the user information from theinput device112. In this embodiment, the hashinglogic120 is used for hashing the input data (e.g., personal information collected) to provide or generate a hash value. The hash value is sometimes referred to as “hash data,” that is generated by an algorithm. In an example embodiment, hashinglogic120 might be software, firmware, hardware, or any combination thereof, and consist of one or more hashing algorithms, e.g., a Secure Hash Algorithm (SHA) algorithm. Hashinglogic120 passes the hash value to digital-signature logic121, which performs a digital signature on the hash value, using the private key on theinput device112. In an example embodiment, digital-signature logic121 might be a component (or module) ofencryption logic118. In other embodiments, the digital-signature logic121 may be defined by separate code, firmware, and/or hardware.
• In one embodiment, the digital-signature logic121 then passes the signed hash value and the public key to a user accessible interface126 (e.g., a graphical user interface or GUI), which might be other software running on theinput device112. In an example embodiment, the useraccessible interface126 might be part of an application or app that includesencryption logic118, hashinglogic120, and digital-signature logic121, and/or other modules or code. The useraccessible interface126 might be used by the user to transmit the digitally signed hash value and the public key to apublic storage facility128 via aline130, and receives back from the public storage facility128 atransaction number132 corresponding to the transmitted hash value and public key. In an alternative example embodiment, only the signed hash value might be transmitted topublic storage facility128 by the user and persons retrieving the signed hash value might obtain the public key from elsewhere (e.g., the user, a public database, an Internet repository, a website, etc.). As is well known, there is no need to keep public keys secure, and in fact, the algorithms using public/private key pairs are design to enable full sharing of public keys. The private key, on the other hand, must be kept secure, as noted above.
• In one embodiment, thepublic storage facility128 can take the form of a block chain (e.g., in a bitcoin online payment system) or any other public or private distributed database. Thepublic storage facility128 is connected to a communication link via a line and can be adapted to communicate over a public computer network, the internet, an intranet, an extranet, or any private communication network. Broadly speaking, thepublic storage facility128 is accessible by any device that has an Internet connection over a network.
• As indicated above, in an example embodiment, the input data might be hashed and the resulting hash value might be signed with a digital signature, created using a private key paired with a public key, before transmission, optionally along with the public key, from the input device (e.g., a user's smartphone)112 to thepublic storage facility128 for storage. The useraccessible interface126 is thus adapted to “seal” the signed hash value and the public key in thepublic storage facility128. In one embodiment, once the hash value, and, optionally, the public key of the user is written to the block chain in a transaction, a later verification may be made if another party is able to hash the same input data.
• FIG. 2A shows a simplified block diagram for a certification method for managing the identity of a user in apublic storage facility228. By way of example, anidentification card202 may be used. In other embodiments, other forms of identification, which may be digital or non-digital may be used. In the example of theidentification card202,personal data204 is contained thereon, which identifies the user. The input data can include aphoto206 of the user; the user's name, address anddriver license number208, and/or abar code210 or similar computer code for storing, scanning and/or retrieving additional data. Such coding can include PDF417 codes, QR codes, and other such codes. However, it is not necessary to have such code and the identification card may only have human-readable text strings. As noted above, theidentification card202 may also take a physical or a digital form and the information can be retrieved either through scanning a code as described, performing Optical Character Recognition (OCR) on text strings, digitally transferring a digital identification card from one system to another, manually inputting the information using a keyboard, manually inputting the information using voice recognition, etc., in example embodiments.
• Theidentification card202 can be a government issued form of identification such as a driver license, passport, employee badge, military identification, political documentation, or the like. Theidentification card202 can also be a privately issued form of identification such as a student ID, library card, social club card, or any other form of identification issued by a third party.
• In one embodiment, as indicated by triangle214, aninput device212 may be used to input such personal data from theidentification card202 to provide input data.Input device212 can take many forms. For example,input device212 can be a digital scanner, digital camera, or smartphone (e.g., with the camera commonly found in smartphones) for reading data from theidentification card202, including any codes appearing on thecard202. Theinput device212 can also be a device for manually inputting personal data such as a keyboard, touchscreen, voice recognition device, handwriting recognition device, or other manual input device.
• As shown inFIG. 2A, the input data can be optionally encrypted byencryption logic218 and securely stored. In one implementation, the input data is transferred directly to hashinglogic220, without passing throughencryption logic218. For ease of understanding, the operations of theoptional encryption logic218 will be discussed first, and then the operations processed by the hashinglogic220. As such, the process may proceed directly from receiving the user information via212 to the hashinglogic220.
• The input data collected from the input device212 (e.g., a user's smartphone) is passed toencryption logic218 oninput device212. In an example embodiment,encryption logic218 might include software, firmware, hardware, or any combination thereof, and consist of one or more encryption algorithms, e.g., an RSA encryption algorithm.Encryption logic218 encrypts the input data with a public key to provide encrypted data. The public key is paired with an associated private key as is conventional when generating such keys using an RSA encryption algorithm, an Elliptic Curve Digital Signature Algorithm (ECDSA), or other encryption algorithm known to those skilled in the art. This encrypted data can then be stored locally on theinput device212 for added security. It can then only be accessed with the private key of the user on theinput device212, which might be stored in a more secure part ofinput device212, e.g., “the Keychain”, ifinput device212 is an iOS (e.g., operating system used by devices made by Apple, Inc.) smartphone. If the device is of a different type, e.g., one using an Android OS (e.g., operating system by Google, Inc.), similar secure device storage methods may be used. In this manner, for added security, the private key is not compromised and is kept safely on theinput device212. It should be understood that the private key may be stored on another device, but similar or additional security should be processed to ensure that the private key is not compromised.
• As noted above, the operations to be performed by the hashinglogic220 can proceed directly after receiving the input data from theinput device212. In this embodiment, the hashinglogic220 is used for hashing the input data (or selected fields of the input data or personal data) to provide or generate a hash value. The hash value is sometimes referred to as “hash data,” that is generated by an algorithm. In an example embodiment, hashinglogic220 might be software, firmware, hardware, or any combination thereof, and consist of one or more hashing algorithms, e.g., a Secure Hash Algorithm (SHA) algorithm. Hashinglogic220 passes the hash value to digital-signature logic221, which performs a digital signature on the hash value, using the private key on theinput device212. In an example embodiment, digital-signature logic221 might be a component (or module) ofencryption logic218. In other embodiments, the digital-signature logic221 may be defined by separate code, firmware, and/or hardware.
• In one embodiment, the digital-signature logic221 then passes the signed hash value and the public key to a user accessible interface226 (e.g., a graphical user interface or GUI), which might be other software running on theinput device212. In an example embodiment, the useraccessible interface226 might be part of an application or app that includesencryption logic218, hashinglogic220, and digital-signature logic221, and/or other modules or code. The useraccessible interface226 might be used by the user to transmit the digitally signed hash value and, optionally, the public key to apublic storage facility228 via aline230, and receive back from the public storage facility228 atransaction number232 corresponding to the transmitted hash value and public key.
• In one embodiment, thepublic storage facility228 can take the form of a block chain (e.g., in a bitcoin online payment system) or any other public or private distributed database. Thepublic storage facility228 is connected to a communication link via a line and can be adapted to communicate over a public computer network, the internet, an intranet, an extranet, or any private communication network. Broadly speaking, thepublic storage facility228 is accessible by any device that has an Internet connection over a network.
• As indicated above, in an example embodiment, the input data (or selected fields of the input data) might be hashed and the resulting hash value might be signed with a digital signature, created using a private key paired with a public key, before transmission, along with, optionally, the public key, from the input device (e.g., a user's smartphone)212 to thepublic storage facility228 for storage. The useraccessible interface226 is thus adapted to “seal” the signed hash value and the public key in thepublic storage facility228. In one embodiment, once the hash value, and, optionally, the public key of the user is written to the block chain in a transaction, a later verification may be made if another party is able to hash the same input data.
• The user accessible interface226 (e.g., a GUI) can be controllable by the user of theinput device212 to encrypt and provide thetransaction number232, the input data (or selected fields of the input data), and, optionally, the public key to an input device242 (e.g., a smartphone) of a certifier. In an example embodiment, the encryption might be performed by theencryption logic218 using a public key of a certifier paired with a private key of the certifier. Then, coding logic on theinput device212 might code theencrypted transaction number232, the input data (or selected fields of the input data), and, optionally, the public key into a barcode or QR code and the certifier might useinput device242 to scan the barcode or QR code and decode it to gain access to the encrypted items. Thereafter, the certifier might decrypt the encrypted items using the private key of the certifier and verify them, e.g., using a “verify” function call to an RSA algorithm as explained in further detail below.
• Once the certifier'sinput device242 receives the barcode or QR code, decoding logic on the certifier'sinput device212 might decode the barcode or QR code anddecryption logic270 on the certifier'sinput device242 might use the certifier's private key to decrypt the encrypted items. In an example embodiment,decryption logic270 might be a component (or module) of more general encryption logic. In one embodiment, the decrypted input data (or selected fields of the input data) might be hashed into a hash value by hashinglogic272 on the certifier'sinput device242, using the same hashing algorithm that was used to create the hash value that was digitally signed by the user. And the decryptedtransaction number232 might be used by a user accessible interface280 (e.g., a GUI) to access the public storage facility228 (e.g., the block chain) and retrieve the signed hash value and public key of the user. The retrieved signed hash value, the generated hash value, and the retrieved or obtained public key might then be input to verifyinglogic273 for verification (e.g., through a “verify” function call to an RSA algorithm), which outputs a “true” value if the two hash values are the same and the public key is associated with the signature or a “false” value if the two hash values are not the same or the public key is not associated with the signature. In an example embodiment, verifyinglogic273 might be a component (or module) ofdecryption logic270. In another embodiment, the verifyinglogic273 may be a separate module, software, firmware and/or hardware. As indicated above, in an example embodiment, the public key of the user might be obtained from some other source than the public storage facility228 (e.g., from the user), in an example embodiment.
• This verification process is depicted inFIGS. 2B-1 and 2B-2.FIG. 2B-1 shows how a digitally signed hash value is created from input data. The input data (or selected fields of the input data) is hashed into a hash value “ABC” by hashinglogic220 on the user'sinput device112, inoperation1. Then the hash value “ABC” is digitally signed with the user's private key using digital-signature logic121 to create digitally signed hash value “XYZ”, inoperation2.
• FIG. 2B-2 shows how a digitally signed hash value is verified after being retrieved along with the public key of the user from thepublic storage facility228. The input data (or selected fields of the input data) is received from the user'sinput device212 at the certifier'sinput device242 and is hashed into a generated hash value “ABC” usinghashing logic272, inoperation3. Then the signed hash value “XYZ”, the generated hash value “ABC”, and the user's public key are input toverification logic273 inoperation4. Theverification logic273 might include a RSA verification algorithm, in an example embodiment. If the hash value in the digitally signed hash value “XYZ” is the same as the generated hash value “ABC” and the digital signature was signed with a private key that is associated with the user's public key, theverification logic273 returns a value of “true”. Otherwise theverification logic273 returns a value of “false”. It should be understood that theverification logic273 may be executed on any device (e.g., a user's device, a certifier's device, a verifier's device, a third party's device, a commercial entity's device, a private entity's device, etc.), that needs to perform a verification operation.
• Upon receipt of a “true” value fromencryption logic270, the certifier might create a certification record that refers to the verification. In an example embodiment, the certification record might include thetransaction number232, the input data (or selected fields of the input data), received from the user, and, optionally, a timestamp, and the certification record might be hashed and digitally signed by the certifier using a private key of the certifier associated with a public key. Then the certifier might use user accessible interface280 (e.g., a GUI) to transmit the signed certification record to thepublic storage facility228 for storage and receive inreturn transaction number282 from thepublic storage facility228. In an example embodiment, the certifier might encrypt the certification record with the certifier's public key before transmission to thepublic storage facility228, in order to keep the certification record private.
• It will be appreciated that the verification process shown inFIGS. 2B-1 and 2B-2 might be used to verify the digital signature on items of data other than the input data (or selected fields of the input data) received byinput device212. In an example embodiment, the item of data that is digitally signed might not be hashed before being digitally signed. In an example embodiment, the verification process shown inFIGS. 2B-1 and 2B-2 might be used to verify a digitally-signed hash of a document other than an identification card, e.g., a digitally-signed certification as described above or a digitally-signed acknowledgement as described below. Or, the same verification process might be used to verify a digitally-signed token (e.g., random number) that is sent by a sender using a secure-envelope process. A secure-envelope process, as described below, might be used instead of, or in addition to, public-key encryption when transmitting data from a user to a certifier, verifier, third party, etc., and vice versa.
• In an example embodiment, when using a secure envelope process, a sender might hash a real-time token (e.g., a random number generated by the user's remote device) and digitally sign the hashed token using the sender's private key. In an example embodiment, a timestamp might be optionally included with the token. Then the sender might transmit the signed hashed token and, optionally, the public key associated with the sender's private key to a distributed public database for storage, receiving a transaction number in return from the distributed public database. Thereafter, the sender might transmit the transaction number and the token to a receiver, e.g., a certifier, a verifier, a third party, etc., optionally, after encrypting the transaction number and the token with the receiver's public key. In an example embodiment, the receiver might receive the transaction number and token (optionally including the timestamp), decrypt them using the receiver's private key, if necessary, and then use the transaction number to retrieve the digitally signed hashed and, optionally, the sender's public key from the distributed public database. The receiver might generate a hash of the token using the same hashing algorithm the sender used. Then the receiver might verify, e.g., using an RSA verify call as described above, that the token in the generated hash is the same as the token in the digitally signed hash token and verify that the digital signature was created with the sender's private key. An RSA verify call may be, for example, processed by verifyinglogic273, e.g., to execute a verify operation. In an example embodiment, the token (optionally including the timestamp) might not be hashed before being signed.
• In one configuration, as depicted inFIG. 2C, the certifier might encrypt the certification record and transaction number282 (e.g., the transaction number the certifier received from the public storage facility228) with the user's public key and transmit in281 the encrypted certification record to the user, using user accessible interface280 (e.g., a GUI). Upon receiving the encrypted certification record, the user might decrypt it using the user's private key and then create an acknowledgement record that refers to or includes the certification record, and optionally includes a timestamp, in order to link the two records in thepublic storage facility228 to facilitate convenient lookup by a third party, if the certification record is verified. Here again, to verify the certification record, the user might hash the certification record using the same hashing algorithm that the certifier used prior to digital signature by the certifier. The user might usetransaction number282 to retrieve the signed certification record and the certifier's public key from thepublic storage facility228. Then the user might verify that the certification record in the generated hash is the same as the certification record in the digitally signed certification record and verify that the digital signature was created with the certifier's private key, e.g., using an RSA verify call as described above.
• In an example embodiment, the acknowledgement record might include the certification record, thetransaction number282, and optionally, a timestamp, and the user might digitally sign the acknowledgement record with the user's private key. Then the user might use user accessible interface228 (e.g., a GUI) to transmit the signed acknowledgement record and the user's public key to thepublic storage facility228 for storage and receive atransaction number229 in response from thepublic storage facility228. In an example embodiment, the user might encrypt the signed acknowledgement record with the user's public key before transmission to thepublic storage facility228 in order to keep the acknowledgement record private.
• FIG. 3A shows a simplified block diagram for a system and method for certifying a pending transaction. By way of example, anidentification card302 may be used. In other embodiments, other forms of identification, which may be digital or non-digital may be used. In the example of theidentification card302,personal data304 is contained thereon, which identifies the user. The personal data can include aphoto306 of the user; the user's name, address anddriver license number308, and/or abar code310 or similar computer code for storing, scanning and/or retrieving additional data. Such coding can include PDF417 codes, QR codes, and other such codes. However, it is not necessary to have such code and the identification card may only have human-readable text strings. As noted above, theidentification card302 may also take a physical or a digital form and the information can be retrieved either through scanning a code as described, performing Optical Character Recognition (OCR) on text strings, digitally transferring a digital identification card from one system to another, manually inputting the information using a keyboard, manually inputting the information using voice recognition, etc., in example embodiments.
• Theidentification card302 can be a government issued form of identification such as a driver license, passport, employee badge, military identification, political documentation, or the like. Theidentification card302 can also be a privately issued form of identification such as a student ID, library card, social club card, or any other form of identification issued by a third party.
• In one embodiment, as indicated bytriangle314, aninput device312 may be used to input such personal data from theidentification card302 to provide input data.Input device312 can take many forms. For example,input device312 can be a digital scanner, digital camera, or smartphone (e.g., with the camera commonly found in smartphones) for reading data from theidentification card302, including any codes appearing on thecard302. Theinput device312 can also be a device for manually inputting personal data such as a keyboard, touchscreen, voice recognition device, handwriting recognition device, or other manual input device.
• As shown inFIG. 3A, the input data can be optionally encrypted byencryption logic318 and securely stored. In one implementation, the input data is transferred directly to hashinglogic320, without passing throughencryption logic318. For ease of understanding, the operations of theoptional encryption logic318 will be discussed first, and then the operations processed by the hashinglogic320. As such, the process may proceed directly from receiving the user information via312 to the hashinglogic320.
• The input data collected from the input device312 (e.g., a user's smartphone) is passed toencryption logic318 oninput device312. In an example embodiment,encryption logic318 might include software, firmware, hardware, or any combination thereof, and consist of one or more encryption algorithms, e.g., an RSA encryption algorithm.Encryption logic318 encrypts the input data with a public key to provide encrypted data. The public key is paired with an associated private key as is conventional when generating such keys using an RSA encryption algorithm, an Elliptic Curve Digital Signature Algorithm (ECDSA), or other encryption algorithm known to those skilled in the art. This encrypted data can then be stored locally on theinput device312 for added security. It can then only be accessed with the private key of the user on theinput device312, which might be stored in a more secure part ofinput device312, e.g., “the Keychain”, ifinput device312 is an iOS (e.g., operating system used by devices made by Apple, Inc.) smartphone. If the device is of a different type, e.g., one using an Android OS (e.g., operating system by Google, Inc.), similar secure device storage methods may be used. In this manner, for added security, the private key is not compromised and is kept safely on theinput device312. It should be understood that the private key may be stored on another device, but similar or additional security should be processed to ensure that the private key is not compromised.
• As noted above, the operations to be performed by the hashinglogic320 can proceed directly after receiving the user information from theinput device312. In this embodiment, the hashinglogic320 is used for hashing the input data (or selected fields of the input data or personal data) to provide or generate a hash value. The hash value is sometimes referred to as “hash data,” that is generated by an algorithm. In an example embodiment, hashinglogic320 might be software, firmware, hardware, or any combination thereof, and consist of one or more hashing algorithms, e.g., a Secure Hash Algorithm (SHA) algorithm. Hashinglogic320 passes the hash value to digital-signature logic321, which performs a digital signature on the hash value, using the private key on theinput device312. In an example embodiment, digital-signature logic321 might be a component (or module) ofencryption logic318. In other embodiments, the digital-signature logic321 may be defined by separate code, firmware, and/or hardware.
• In one embodiment, the digital-signature logic321 then passes the signed hash value and, optionally, the public key to a user accessible interface326 (e.g., a graphical user interface or GUI), which might be other software running on theinput device312. In an example embodiment, the useraccessible interface326 might be part of an application or app that includesencryption logic318, hashinglogic320, and digital-signature logic321, and/or other modules or code. The useraccessible interface326 might be used by the user to transmit the digitally signed hash value and, optionally, the public key to apublic storage facility328 via aline330, and receive back from the public storage facility328 atransaction number332 corresponding to the transmitted hash value and public key.
• In one embodiment, thepublic storage facility328 can take the form of a block chain (e.g., in a bitcoin online payment system) or any other public or private distributed database. Thepublic storage facility328 is connected to a communication link via a line and can be adapted to communicate over a public computer network, the internet, an intranet, an extranet, or any private communication network. Broadly speaking, thepublic storage facility328 is accessible by any device that has an Internet connection over a network.
• As indicated above, in an example embodiment, the input data might be hashed and the resulting hash value might be signed with a digital signature, created using a private key paired with a public key, before transmission, optionally along with the public key, from the input device (e.g., a user's smartphone)312 to thepublic storage facility328 for storage. The useraccessible interface326 is thus adapted to “seal” the signed hash value and the public key in thepublic storage facility328. In one embodiment, once the hash value, and, optionally, the public key of the user is written to the block chain in a transaction, a later verification may be made if another party is able to hash the same input data.
• The user accessible interface326 (e.g., a GUI) can be controllable by the user of theinput device312 to transmit, in350, an acknowledgement record, a transaction number for a signed acknowledgement record, and optionally the user's public key to averifier342. In an example embodiment,transaction number332 for the signed input data and the input data might also be transmitted toverifier342, for verification using the verification process used by the certifier, as described above. As used herein, to provide broad understanding of the functions or operation ofverifier342, an example use case of a bank, being the verifier is provided. It should be understood that the verifier can be any entity that needs to verify identity, data, or transaction(s). Additionally, the certifier may be any entity that has certified identity, data, or transaction(s). Thus, in this use case example, the bank is not necessarily the same entity as the certifier, but in other circumstances, the bank may also be the certifier. By way of example, the bank may verify a certification made by another entity, e.g., a credit card company, a car company, a government agency, a private entity, etc. Acknowledgement records and transaction numbers for signed acknowledgement records were discussed in detail above with respect toFIG. 2C. As noted indicated above, the user might use encryption with the verifier's public key and/or a secure-envelope process fortransmission350.
• Once the verifier receives the acknowledgement record and the transaction number for the signed acknowledgement record, the verifier might use the process shown inFIG. 3B to verify the acknowledgement record and its underlying certification record. Inoperation1, the verifier uses the transaction number to retrieve the signed acknowledgement record and, optionally, the user's public key frompublic storage facility328. Then, inoperation2, the verifier hashes the acknowledgement record with the same hashing algorithm that was used by the user and verifies the acknowledgement record and the user's signature, using a verification algorithm as discussed in detail above. If the verification is successful, the verifier uses the transaction number for the signed certification record to retrieve the signed certification record and the certifier's public key frompublic storage facility328, inoperation3. Then, inoperation4, the verifier hashes the certification record with the same hashing algorithm that was used by the certifier and verifies the certification record and the certifier's signature, using a verification algorithm as discussed in detail above. If this verification is also successful, the verifier might create another certification record as discussed above and transmit it topublic storage facility328, receiving, in response, another transaction number, which might be transmitted along with the verifier's certification record to the user for another acknowledgement record.
• In the event the certification record and/or the acknowledgement record are optionally encrypted before transmission to the block chain, the user transmits an unencrypted acknowledgment record to the verifier and the verifier performs its verifications using the data in the unencrypted acknowledgement record. In an example embodiment, these verifications include checking that an acknowledgment record in fact exists in the block chain with the transaction number for the signed acknowledgement record. Also, in an example embodiment, the unencrypted acknowledgment record includes the transaction number of the signed certification record along with other unencrypted data from the certification record. Using the transaction number for the signed certification and the unencrypted data from the certification record, the verifier can confirm that the certification record in fact exists on the block chain and can process the unencrypted data in the certification record to verify the certifier's signature, even if the certification record was also encrypted before transmission to the block chain.
• It should be understood that the embodiments and described use cases herein are only by way of example. Many new use cases can be encompassed and facilitated by the functionality described herein. For instance, identity verification can be integrated into various commercial applications, as well as private applications. Commercial applications may include those that require commercial entities to verify a user's identity. Verifying a user's identity can be required for achieving any number of functions, such as traveling, making transactions, banking, communication, loan verification, credit verification, purchase verification, and other uses. Private identity verification can also be facilitated using the methods, apparatus, computer readable media, and systems described herein. Private identity verification may be useful when a user wishes to prove to another user their identity, in a fast and efficient manner. The systems described herein, as described above, utilize methods that write data to the block chain database, which is non-rewritable and permanently maintains the record without compromise. This enables writing of information to the block chain in a manner that can be verified by one or more transactions executed by methods of the present inventions.
• Additionally, the method operations described herein may be executed with any number of computer systems. By way of example, the computer systems may include user devices, such as mobile phones, tablets, desktop computers, watch computers, head attached computers, eyeglasses computers, or combinations thereof. Server operations may also be performed and communicated between client devices, to facilitate transactions with the block chain database, server storage, and the like. By way of example, these computer devices can communicate over networks, such as the Internet. The networks enable individual devices to transact with each other, such as by way of sending, receiving, and processing exchanged information. The exchanged information can include different types of encrypted data, hashed data, envelopes, codes, QR codes, messages, notifications, and other types of data.
• The messaging and communication functions are provided to enable users to exchange data in order to verify identity, or enable or provide access to users to services, goods, or commercial transactions. In the case of banking operations, the verification process can be utilized by banks, as well as users of the bank or third parties that require certified information from the banks regarding users. In the case of travel type verifications, different travel entities can require identification of users, and that the identification be verified by themselves or by other third parties that are trusted. These operations can be facilitated using the systems, methods, computer readable media, and code that execute the verification processes. Broadly speaking, verification of a user identity can be useful in any type of industry, or private setting. The use of verification is simply facilitated by using the verifying infrastructure, programs code, applications, and combinations thereof, to ensure that verification is secure.
• In some embodiments, the verification systems can be embodied in an application, such as those that can be installed on mobile devices (e.g., Apps). By way of example, users wishing to have their identity verified can use an App to seal information regarding their identity. Once the data has been sealed, and encrypted data has been stored to the block chain, this data can be used for later certification by another party. The other party may also be utilizing a corresponding App, which enables efficient reading of the data, code, QR code, message, or notification, to validate the identity of the user.
• In still other embodiments, code plug-ins can be integrated into commercial websites, which may use identity verification for different reasons or functions. For example, banks can install plug-in applications, code, or programs that can execute part or all of the verification processing to seal information and/or to certify information regarding identity. In view of the foregoing, it should be understood that the verifying processes described herein and the various use cases are only by way of example, and additional use cases will be evident to those skilled in the art.
• The various embodiments defined herein may define individual implementations or can define implementations that rely on combinations of one or more of the defined embodiments. Further, embodiments of the present invention may be practiced with various computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a wire-based or wireless network.
• Any of the operations described herein that form part of the invention are useful machine operations. The invention also relates to a device or an apparatus for performing these operations. The apparatus can be specially constructed for the required purpose, or the apparatus can be a general-purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general-purpose machines can be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
• The invention can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can thereafter be read by a computer system. The computer readable medium can also be distributed over a network-coupled computer system so that the computer readable code is stored and executed in a distributed fashion.
• Having provided this detailed description, it will be apparent that modifications and variations are possible without departing from the scope of the invention defined in the appended claims. When introducing elements of the present invention or the preferred embodiments(s) thereof, the articles “a”, “an”, “the” and “said” are intended to mean that there are one or more of the elements. The terms “comprising”, “including” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements. In view of the above, it will be seen that the several objects of the invention are achieved and other advantageous results attained. As various changes could be made in the above systems without departing from the scope of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
• With the above embodiments in mind, it should be understood that the inventions might employ various computer-implemented operations involving data stored in computer systems. Any of the operations described herein that form part of the inventions are useful machine operations. The inventions also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for the required purposes, such as the carrier network discussed above, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.
• The inventions can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data, which can thereafter be read by a computer system. Examples of the computer readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, DVDs, Flash, magnetic tapes, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.
• Although example embodiments of the inventions have been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications can be practiced within the scope of the following claims. For example, the website might host an online retailer or an online publication, instead of a connected-television service. Moreover, the operations described above can be ordered, modularized, and/or distributed in any suitable way. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the inventions are not to be limited to the details given herein, but may be modified within the scope and equivalents of the following claims. In the following claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims or implicitly required by the disclosure.

Claims (21)

1.-8. (canceled)

9. A non-transitory processor-readable medium storing code representing instructions to be executed by a processor, the instructions comprising code to cause the processor to:

receive, at a user device, data associated with a credential of a user;

generate a first hash value by hashing the data using a hashing method;

send, to a distributed database, the first hash value such that the first hash value is stored in the distributed database as associated with a transaction identifier;

receive, from the distributed database, the transaction identifier;

encrypt the data and the transaction identifier to produce an encrypted package; and

send, to a certifier device, the encrypted package such that the certifier device (1) decrypts the encrypted package to obtain the data and the transaction identifier, (2) obtains the first hash value from the distributed database using the transaction identifier, (3) generates a second hash value by hashing the data using the hashing method, and (4) certifies the credential of the user based on comparing the first hash value with the second hash value.

10. The non-transitory processor-readable medium ofclaim 9, wherein the credential of the user is at least one of a driver's license, a passport, an employee badge, a military identification, a political identification, a student identifier, a library card or a social club card.

11. The non-transitory processor-readable medium ofclaim 9, further comprising code to cause the processor to:

digitally sign the first hash value to define a signed first hash value, the code to cause the processor to send the first hash value includes code to cause the processor to send the first hash value as the signed first hash value.

12. The non-transitory processor-readable medium ofclaim 9, further comprising code to cause the processor to:

digitally sign the first hash value to define a signed first hash value, the code to cause the processor to send the first hash value includes code to cause the processor to send the first hash value as the signed first hash value,

the code to cause the processor to send the encrypted package includes code to cause the processor to send the encrypted package such that the certifier device verifies the signed first hash value using a public key associated with the user device.

13. The non-transitory processor-readable medium ofclaim 9, wherein the code to cause the processor to encrypt the data and the transaction identifier includes code to cause the processor to encrypt the data and the transaction identifier using a public key associated with the certifier device such that the certifier device decrypts the encrypted package using a private key associated with the public key.

14. The non-transitory processor-readable medium ofclaim 9, further comprising code to cause the processor to:

generate a barcode based on the encrypted package, the code to cause the processor to send the encrypted package includes code to cause the processor to send the encrypted package to the certifier device using the barcode.

15. The non-transitory processor-readable medium ofclaim 9, further comprising code to cause the processor to:

receive, from the certifier device, a certification record based on the certifier device certifying the credential of the user.

16. The non-transitory processor-readable medium ofclaim 9, further comprising code to cause the processor to:

receive, from the certifier device, a certification record based on the certifier device certifying the credential of the user;

define an acknowledgement record based on the certification record; and

send the acknowledgement record to the distributed database such that the acknowledgement record is stored in the distributed database.

17. A method, comprising:

receiving, at a user device, data of a user;

generating a first hash value by hashing the data using a hashing method;

digitally signing the first hash value to produce a signed first hash value;

storing the signed first hash value in a distributed database;

receiving, from the distributed database, a transaction identifier associated with the signed first hash value stored in the distributed database; and

sending, to a certifier device, the data and the transaction identifier such that the certifier device (1) obtains the signed first hash value from the distributed database using the transaction identifier, (2) generates a second hash value by hashing the data using the hashing method, and (3) certifies the data of the user based on verifying a digital signature of the signed first hash value and comparing the first hash value with the second hash value.

18. The method ofclaim 17, wherein the digitally signing includes digitally signing the first hash value using a private key associated with the user device to produce the signed first hash value, the certifier device verifying the digital signature using a public key associated with the private key.

19. The method ofclaim 17, further comprising:

receiving a certification record from the certifier device;

defining an acknowledgement record based on the certification record; and

storing the acknowledgement record in the distributed database.

20. The method ofclaim 17, further comprising:

encrypting, using a public key of the certifier device, the data and the transaction identifier prior to sending the data and the transaction identifier to the certifier device such that the certifier device decrypts the data and the transaction identifier using a private key associated with the public key.

21. The method ofclaim 17, wherein the data is from a credential of the user, the credential is at least one of a driver's license, a passport, an employee badge, a military identification, a political identification, a student identifier, a library card or a social club card.

22. The method ofclaim 17, further comprising:

generating a barcode based on the data and the transaction identifier, the sending the data and the transaction identifier includes sending the data and the transaction identifier to the certifier device using the barcode.

23. An apparatus, comprising:

a memory; and

a processor operatively coupled to the memory, the processor configured to:

receive, at a user device, data of a user;

generate a first hash value by hashing the data;

store the first hash value in a distributed database;

receive, from the distributed database, a first transaction identifier, the first transaction identifier associated with the first hash value stored in the distributed database;

send, to a certifier device, the data and the first transaction identifier such that the certifier device (1) obtains the first hash value from the distributed database using the first transaction identifier, (2) generates a second hash value by hashing the data, and (3) defines a certification record based on comparing the first hash value with the second hash value;

receive, from the certifier device, the certification record and a second transaction identifier, the second transaction identifier associated with a third hash value in the distributed database;

retrieve the third hash value from the distributed database using the second transaction identifier;

generate a fourth hash value by hashing the certification record; and

define an acknowledgement record associated with the certification record based on comparing the third hash value with the fourth hash value.

24. The apparatus ofclaim 23, wherein the certification record and the second transaction identifier are digitally signed by the certifier device using a private key of the certifier device, the processor configured to define the acknowledgement record based on verifying a digital signature of the certification record and the second transaction identifier using a public key associated with the private key.

25. The apparatus ofclaim 23, wherein the processor is configured to:

encrypt, using a public key of the certifier device, the data and the first transaction identifier prior to sending the data and the first transaction identifier to the certifier device such that the certifier device decrypts the data and the first transaction identifier using a private key associated with the public key.

26. The apparatus ofclaim 23, wherein the acknowledgement record includes the certification record and the second transaction identifier.

27. The apparatus ofclaim 23, wherein the processor is configured to store the acknowledgement record in the distributed database.

28. The apparatus ofclaim 23, wherein the data is from a credential of the user, the credential is at least one of a driver's license, a passport, an employee badge, a military identification, a political identification, a student identifier, a library card or a social club card.

Images