Patent ID: 12238205

DETAILED DESCRIPTION

A lack of adoption for PKI-based data protection can be attributed to the fact that it can be cumbersome to use. In order to communicate with another person via PKI, a user generates his/her own public key and private key pair, storing the private key in a manner that ensures its safety and integrity. Then the user either shares his/her public key with another user or obtains the other user's public key. The public keys are managed in a data store that is commonly called a key ring. If the user wishes to use the same encryption key(s) on more than one device, the private key(s) are copied from a device where they already reside, onto one or more additional devices, in a way that ensures that the encryption key(s) cannot be captured in transit.

In order to facilitate adoption of PKI for person-to-person and person-to-group communications, the system and methods herein can, in some embodiments, accomplish one or more of at least four goals. First, they can provide for the creation and secure storage of a user's private key and the retrieval of public keys for any other people with whom the user communicates. Second, the systems and methods herein can provide for the secure transfer of the user's private key to other devices that the user wishes to use for such communications, without creating any point in the interaction where there is a “break” in the cryptography, such that a third party could intercept and copy the user's private key. Third, the systems and methods herein can allow a user to, from any enrolled device in the user's control, force the de-authorization of any other device that has been associated with the user's private key, such that if a device is stolen, lost, or otherwise rendered outside of the user's control, the device cannot be used to compromise the user's communications. Fourth, the systems and methods herein can provide an efficient workflow for the user while maintaining security.

FIG.1depicts an exemplary secure communications system100. The exemplary secure communications system100comprises a server140, which may comprise one or more physical or virtual machines deployed either on premises or in cloud infrastructure. The exemplary communications system100additionally comprises a key proxy server180, which may or may not reside on the same physical or virtual hardware as the server140, and one or more key proxy instances190. The one or more key proxy instances190may remain unconfigured until required, and may be destroyed immediately after use. Furthermore, when a key proxy instance is allocated for use, another key proxy instance may be automatically built so that the number of the one or more key proxy instances190remains constant.

One or more users, e.g., individuals who have registered for the secure communications service, may use the exemplary secure communications system100. The one or more users may use one or more user devices110,112, and114, e.g., computing devices associated with a user's secure communications service account. The one or more users may use the one or more user devices110,112, and114, to communication with each other via the secure communications service. Each of the one or more user devices has an installed secure communications application120appropriate for its architecture (Linux, Windows, MacOS, Android, IOS). The one or more users may use one or more accounts, e.g., accounts with data-sharing services including e-mail providers such as Gmail or Outlook.com, content-storage services such as Dropbox or SharePoint, collaboration-messaging services such as Slack, instant message services, or other methods of person-to-person or group communications, as well as a secure communications service account.

FIG.2depicts an exemplary authorized user device210that stores user private keys. When a user device210is first initialized, it creates a file230for key storage. All initial user private keys are stored to the file230. The file230is encrypted using a device public key. The device private key is stored in a file240that is protected by PIN, password, or biometric means. When the user opens a secure communications application220on the device, the user must prove his/her identity to the secure communications application220by providing the appropriate PIN, password, or biometric authentication. The secure communications application220uses the identity information, e.g., the PIN, the password, or the biometric authentication, to unlock the device private key. The secure communications application220uses the device private key to decrypt the file230containing the user private keys. When new user private keys are received, the user device210appends the new user private keys to the file230and re-encrypts the file230either with the current device public key, or with a newly-generated device public key. In this way, a user's historical keys are all available, so that the user may view messages and content that were encrypted using older keys, and all historical keys are protected using newly-generated device keys.

FIG.3is a diagram that depicts how a user of a secure communications system300creates a new secure communications application account. At302, the user, through a user device310downloads a secure communications application320from the internet330. After installing the secure communications application320, the user runs the secure communications application320and chooses to create a new secure communications application account. The user selects a username and password, and may, optionally, select biometric authentication (e.g. fingerprint) in order to access his/her account on devices with that capability. A user account entry is then created on a server340using HTTPS to protect the contents of the interaction because the user is deemed to be a trusted agent for the new account.

The secure communications application320generates two unique asymmetric key pairs: one pair that is specific to the device—a device key pair—and one pair that is specific to the user-a user key pair. Each pair contains a public key and a private key. The secure communications application320sends a cryptographic hash of the user's account name and device ID, along with the two public keys, i.e., a user public key and a device public key, at304and306, to a server340via HTTPS. The server340stores the user and device public keys in association with the cryptographic hashes in a data store350. Once a user device, e.g., the user device310, is authenticated with the user's secure communications application account, all communications with the server340are performed with cryptographic signatures so that the server340can be certain that a sending device is who it says it is.

FIG.4is a diagram that depicts an association of a third-party account with an existing secure communications application account. A user runs the secure communications application320on the user device310and chooses to associate a third party account with the user's secure communications application account. The secure communications application420generates a new asymmetric key pair for the third party account. At402, the secure communications application320sends a cryptographic hash of the user's third-party account name, along with the respective public key, to the server340. At404, the server340stores the public key for the new account in association with the cryptographic hash in the data store350.

FIG.5is a diagram that depicts a first part of an association of a new user device with an existing secure communications application account. At502, a user downloads a secure communications application520from the internet330onto the new user device, e.g., a user device510. After installing the secure communications application520, the user runs the secure communications application520and chooses to connect using an existing secure communications application account. The secure communications application520generates an asymmetric key pair, which is specific to the user device510. At504, the secure communications application520requests the public key associated with the cryptographic hash of the secure communications application account from the server340. At506, the server340requests the cryptographic hash from the data store350.

FIG.6is a diagram that depicts a second part of the association of the new user device with the existing secure communications application account. At602, the server340retrieves the appropriate public key from the data store350. At604, the server340sends the appropriate public key to the secure communications application520, if it is available.

FIG.7is a diagram that depicts a third part of the association of the new user device with the existing secure communications application account. The user device510creates and encrypts a message requesting the user's private keys and including a symmetric key. At702, the user device510encrypts the message and sends it to the server340, addressed to the user. At704, the server340forwards the message to all of the user's authorized user devices, e.g., the user device310. The user device310already has the user's private key, so it is able to decrypt the symmetric key and content of the request. The user device310presents a verification dialog to the user asking whether the user confirms that the user device510should be added to the existing secure communications application account. If the user confirms, the key transfer happens in accordance with the methods discussed with reference toFIGS.11-15.

FIG.8is a diagram that depicts self-removal/de-authorization of a user device, e.g., a user device810, from an existing secure communications application account. The user runs a secure communications application820and chooses to remove and de-authorize the user device810. At802, the secure communications application820sends, to the server340, a signed, encrypted message indicating that it should be removed from a user's list of authorized devices. The secure communications application820deletes all of the user's private keys and content stored on the user device810. At804, the server340removes the device requesting removal, i.e., the user device810, from the user's list of authorized devices in the data store350. At806, the server340sends a message encrypted with the user's public key to remaining devices, e.g., the user device310, indicating that the device requesting removal, i.e. user device810, has been removed.

FIG.9is a diagram that depicts remote removal/de-authorization of a user device e.g., a user device910, from an existing secure communications application account. The user runs a secure communications application320on the user device310and chooses to remove and de-authorize a different device, i.e., the user device910installed with a secure communications application920. At902, the secure communications application320sends, to the server340, a signed, encrypted message indicating that the user device910should be removed from the user's list of authorized devices. At904, the server340removes the user device910from the user's list of authorized devices in the data store350. At906, the server340sends a message encrypted with the user's public key to the user device910, indicating that that it has been de-authorized, and must remove all private keys and content. If the user device910receives the message, the secure communications application920removes keys and content as directed.

FIG.10is a diagram that depicts removal of all devices associated with a secure communications application account. The user runs the secure communications application320on the user device310and chooses to remove the secure communications application account. At1002, the secure communications application320sends, to the server340, a signed, encrypted message indicating that the secure communications application account is to be removed. At1004and1006, the server340sends a message encrypted with the user's public key to all user devices, e.g., the user device1010, including the requesting device, i.e., the user device310, directing each user device to remove all user private keys and content stored on each of the user devices. Each of the user devices that receive the message remove the private keys and content stored on the user device. At1008, the server340removes all of the user devices and the user's account from the data store350.

FIG.11is a diagram that depicts a first part of an automatic private key dissemination to an authorized device. At1102, the up-to-date device, i.e., user device1160, generates a new symmetric key. At1104, the user device1160encrypts the new symmetric key with the server's public key. At1106, the user device1160creates a message requesting a key proxy instance and comprising the public device key for all devices that need to be brought up-to-date. The user device1160encrypts the message using the symmetric key it just generated and signs the message using its own device private key. At1108, the user device1160sends the message to a server, e.g., a server1140.

The server1140checks the signature of the message, and if it correctly matches the public key it has on record for the device making the request, it decrypts the symmetric key using its own private key, and then uses the symmetric key to decrypt the message. At1110, the server1140directs a key proxy server, i.e., a key proxy server1180to allocate a key proxy instance for use, and specifies the requesting device's public key as the only device authorized to upload information to that instance. At1112, the key proxy server1180allocates a key proxy, e.g., a key proxy1190, from the pool of available proxies.

FIG.12is a diagram that depicts a second part of the automatic private key dissemination to authorized devices. At1202, the key proxy server1180provides the server1140with a unique URL for the key proxy instance1190. The server1140creates a response message comprising the unique URL, encrypts the message with the symmetric key sent by the requesting device, i.e., the user device1160, and signs the message with its own private key. At1204, the server1140sends the message to the requesting device, i.e., user device1160. At1206, the requesting device decrypts the unique URL.

FIG.13is a diagram that depicts a third part of the automatic private key dissemination to authorized devices. At1302, the user device1160generates another symmetric key, and encrypts all of its user private keys with the symmetric key. At1304, the user device1160then encrypts the symmetric key with each of the device public keys of any devices that need to be updated with the user's private keys. The user device1160generates a message comprising one or more encrypted symmetric keys (one for each device to which it is disseminating keys) and a private key bundle that has been encrypted with the symmetric key. The user device1160signs the message with its own device private key. At1306, the user device1160establishes an HTTPS connection to the key proxy instance1190, using the unique URL that was provided by the server1140, and sends the signed message. The key proxy instance1190receives the message and checks the signature to ensure that it matches the public key it was given by the key proxy server1180. If there is a match, the key proxy instance1190accepts the message and prepares to send the encrypted bundle to authorized requesters.

FIG.14is a diagram that depicts a fourth part of the automatic private key dissemination to authorized devices. At1402, the user device1160generates another symmetric key. At1404, the user device1160encrypts the symmetric key with each of the device public keys of any devices that need to be updated with the user's private keys. At1406, the user device1160creates a message containing the unique URL of the key proxy instance1190and encrypts that message using the symmetric key. At1408, the user device1160signs the message using its own device private key, and sends it to the server1140, addressed to all authorized devices for the user.

FIG.15is a diagram that depicts a fifth part of the automatic private key dissemination to authorized devices. At1502, the server1140cannot decrypt the message, but forwards it to all of other devices associated with the user's secure communications application account. Each user device, e.g., user device1110, checks the signature to ensure that it came from the user device it claims to have come from. If the signature is valid, each user device decrypts the symmetric key contained in the message using its own device private key, then decrypts the unique URL of the key proxy instance1190using the symmetric key. Each user device then generates a request for key download, signing the request with its own private key. At1504, each user device connects to the key proxy instance1190at the specified URL and sends the signed request. At1506, if the signature matches one of the device public keys that was provided to the key proxy instance1190, the key proxy instance1190sends the encrypted key bundle to each user device. Each user device then uses its own private key to decrypt the symmetric key in the bundle, then uses that symmetric key to decrypt the set of user private keys the bundle comprises.

FIG.16is a diagram that depicts re-initialization of keys associated with a secure communications application account and third party accounts. An initiating device, i.e., the user device1660, creates a new device key pair for itself. The initiating device creates a new user key pair for every account (both secure communications application account and third-party accounts) that the user has registered with the secure communications application1670. At1602, the user device1660stores its new keys locally in local storage1630, in accordance with the method described with reference toFIG.2. At1604, the user device1660sends, to the server1140, an encrypted signed message indicating that a key dissemination needs to occur. Key dissemination follows the method described with reference toFIGS.11-15.

FIG.17is a diagram that depicts a first part of sending data from a first user to a second user. The first user, using the secure communications application1720on one of his/her authorized devices, e.g., user device1710, indicates that the first user wants to send information to a second user (e.g. user device1760, by clicking on the second user's name in their friend list, or by other means appropriate). The secure communications application1720takes the second user's user ID, combines it with the a service name or a medium name into a string, and creates a cryptographic hash of the combined string. At1702, the secure communications application1720creates an encrypted, signed message requesting the user public key associated with that hash, and sends the message to the server1140.

FIG.18is a diagram that depicts a second part of sending data from the first user to the second user. At1802, the server1740retrieves the hash from a data store1750. If there is a key associated with that hash in the data store1750, the server1740creates an encrypted, signed message containing the key. At1804, the server1740sends the encrypted, signed message back to the secure communications application1720running on the user device1710. The secure communications application1720receives the key, and uses it, in conjunction with a newly-generated symmetric key, as well as the information the user wishes to communicate (e.g., a text message, a file, or other content) to create a bundle which contains: (1) the symmetric key, encrypted with the user public key of the desired recipient; (2) a cryptographic hash of the public key that was used to encrypt the symmetric key; (3) the actual user-supplied content to be sent.

FIG.19is a diagram that depicts a third part of sending data from the first user to the second user. The secure communications application1720signs the bundle with the user private key appropriate to the medium being used, and sends the bundle in a message to the server1740at1902, addressed to the appropriate user. The server1740cannot decrypt the message, but forwards the message at1904to every device on the second user's list of authorized devices, e.g., user device1760. Any or all of those devices, when they receive the message, check the signature of the message to ensure that it came from who it says it did, and (if it did) extract the cryptographic hash it contains, and use that to look up in their local key store which user private key to use to decrypt the symmetric key. The secure communications application1770then decrypts the symmetric key, and uses that, in turn, to decrypt the message contents and present them to the second user in whatever way is appropriate for the medium.

FIG.20is a diagram that depicts interacting with other users via a third-party website by posting content. A browser2030on a user device2010is configured to use the secure communications application2020as its web proxy. When the user wishes to share secure communications application-protected content on the third party website, e.g., chatboard.com2040, all the user must do is post that information. A request to post content2050is intercepted at2002by the secure communications application2020, which will determine if it is appropriate to encrypt content. If the content2052is to be encrypted, the secure communications application2020determines which secure communications application-registered site users are intended recipients of the content2052. At2004, the secure communications application2020constructs a message2054in a manner similar to the methods described with reference toFIGS.17-19. The message contains the content2052encrypted with a new symmetric key, and a copy or copies of that symmetric key each encrypted with the public keys of all intended recipients, including that of the sending user. At2006, the message will be converted to an alphanumeric text block2056via encoding such as Base64, and then will be wrapped in a fence of distinctive characters, e.g., fenced data block2058. The secure communications application2020replaces the content of the user's submission to the website with this fenced data block and submits the request to the third-party website at2008on the user's behalf.

FIG.21is a diagram that depicts interacting with other users via a third-party website by reading content on the website. At2102, the browser2030sends a request to the secure communications application2020for the page in question. The secure communications application2020sends the request to the web server on behalf of the user at2104. At2106, results are returned from the web server, and the secure communications application2020inspects the contents to determine if any properly-formatted text is present in the content. If the contents contain properly-formatted text, at2108, the secure communications application2020decodes the Base64 encoding of the block, locates the hash values for any keys present in the message, and compares the hashes with the locally-stored list of hash values. If the secure communications application2020finds a hash match, it uses the corresponding locally-stored user private key to decrypt the symmetric key from the message, decrypts the content of the message using the symmetric key, then replaces the entire message block, including the fences, with the contents of the decrypted message, before passing the response back to the browser2030at2110.

FIG.22is a flow diagram2200depicting a method for automatically disseminating a private key. At2210, a first message requesting a key proxy instance is received from a first user device. The first message comprises a first symmetric key. At2220, a key proxy server is directed to allocate a key proxy instance for communication with the first user device based on a first device public key that corresponds to the first user device. A unique URL corresponding to the key proxy instance is received from the key proxy server at2230. A second message comprising the unique URL is sent to the first user device at2240. The second message is encrypted using the first symmetric key and signed using a server private key. At2250, a third message comprising the URL of the key proxy instance is received from the first user device and forwarded to a second user device. The third message is encrypted using the second symmetric key and signed using a first device private key that corresponds to the first user device.

FIG.23is a flow diagram2300depicting a method for facilitating communication between users is presented. At2310, a first encrypted signed message requesting a user public key of a receiving user is received from a first user device. The user public key is associated with a first cryptographic hash of a combined string. The combined string comprises a user ID and a service name. At2320, whether the first cryptographic hash exists in storage is determined. A second encrypted signed message comprising the user public key associated with the first cryptographic hash is sent based on the determining at2330. At2340, a message comprising (i) a symmetric key encrypted with the user public key; (ii) a second cryptographic hash of the user public key; and (iii) user-supplied content is received. At2350, a list of authorized devices for the receiving user is determined. The message is forwarded, without decrypting, to a second user device at2360. The second user device is associated with the receiving user and appears in the list of authorized devices.

The systems and methods presented herein provide several advantageous features. Ephemeral, single-use-only platform as a service (PaaS) instances are used for key exchange in a way that guarantees that no user private key information traverses the primary system servers, is not commingled with any other user's private key information, and exists on a user's personally-controlled devices for the few moments it takes to ensure successful transfer to another device owned by the user.

The storing and retrieving users' various public keys by way of referencing a cryptographic hash of the user's account name and associated service ensures that there is no record on the system server of the names of accounts a user has associated with the service. Even if the system server becomes compromised, a hacker could not associate which third-party service accounts are associated with which secure communications application user accounts.

The combination of unique device key pairs with unique user-account key pairs allows private keys to be safely transferred from one device to another across the open internet without risk of compromise.

The use of familiar workflows such as “friend-request”-style interactions to facilitate key exchange between users allows for cryptographic integrity to be established without interfering with the user's ease-of-use.

Using a native application running on a device as a selective web proxy so that traffic being sent to publicly-accessible websites from the user's browser can be intercepted and encrypted prior to the traffic leaving the user's computer. Similarly, content being downloaded to the user's browser can be inspected for encrypted content and decrypted in-stream, so that the user's experience is the same as if no encryption were in use.

The use of a historical key-store, which retains previous versions of a user's private keys, but encrypted with the device's current key, allows a user to access old content that was encrypted using previous keys, while allowing keys to be updated and changed at any time to prevent compromise through loss. In addition, the use of cryptographic hashes of encryption keys in the key store, and accompanying transmitted/stored encrypted data, indicate which key out of a set of many should be used for decrypting a given data set.

Examples have been used to describe the invention herein, and the scope of the invention may include other examples.