Methods, systems, and devices for storing, encrypting, and replacing data

This application claims the benefit of U.S. Provisional Application No. 63/090,767 filed Oct. 13, 2020, the entire disclosure of which is incorporated by reference hereon as if set forth in full below.

The present disclosure relates generally to information technology security, and more particularly to managing and using data via encryption.

Companies and organizations collect various types of sensitive data. For example, contact information (e.g., email addresses) and other personal information are routinely collected and stored by various businesses. However, organizations are at a constant threat of being breached by malicious parties whose goal is to access and use an organization's collected data.

Related art approaches implement security measures to prevent system access by third parties (e.g., firewalls) as well as the use of data encryption. The related art suggests using encryption keys to secure data within an organization's servers. However, these approaches are insufficient. For example, poorly implemented security technology or decryption keys being held within the organization together with the encrypted data leaves companies open to breaches. Thus, once a hacker has breached an organization and can access encrypted data, they often can easily access decryption keys to decrypt the data as well.

Accordingly, there is needed improved methods and systems for preventing access to data in the event of a breach. This system can be applied to other data to allow secure, encrypted storage while allowing transparent usage of the data. Aspects of the present disclosure attempt to address these and other issues.

According to some embodiments, there is provided a system configured to: accept a data field from a calling service, application, or user; and generate a token or replacement data field for use by the caller instead of the actual data field.

According to some embodiments, there is provided a system configured to generate a token or replacement data field on demand.

According to some embodiments, there is provided a method of a device comprising: receiving, from a remote device, original data to be encrypted; generating a replacement token for the original data; sending, to the remote device, the replacement token; encrypting the original data; and storing the encrypted original data in association with the replacement token.

According to some embodiments, there is provided a method of a device comprising: receiving, from a remote device, a replacement token to be de-obfuscated; identifying an encrypted original data based on the replacement token; decrypting the original data; and sending, to the remote device, the original data.

According to some embodiments, there is provided a method of a device comprising: receiving, from a remote device, an email directed to a token email address; identifying an encrypted true email address based on the token email address; decrypting the true email address; and updating the email by replacing, within the email, the token email address with the email address; and forwarding the updated email to the true email address.

According to some embodiments, there is provided a method of a device comprising: receiving, from a remote device, an identifier to be de-obfuscated; identifying an encrypted token based on the identifier; decrypting the token; and sending, to the remote device, the unencrypted token.

Certain features of one or more example embodiments are described below with reference to one or more figures. It will be understood by one of ordinary skill that many alterations may be made to the described embodiments without departing from the scope of the present disclosure.

According to aspects of the present disclosure, there may be provided a method for securely encrypting and/or obfuscating data. For example, there may be provided an encryption server that receives an email address from an organization. The encryption server generates a token replacement email address and provides the token email address to the organization. The organization can use the token address instead of the email address (i.e., the organization can delete all records of the true email address), and swap out the token email address for the real email address as needed by communicating with the encryption server. The encryption server encrypts the real address and associates the encrypted address with the token address using a hash of the token address. The encryption server can then remove all instances of the token address and the unencrypted real address from its database. When the organization wants the true address, it provides the encryption server with the token address. The encryption server then hashes the token address to locate the encrypted address, decrypts the encrypted address, and provides the unencrypted address to the organization. By splitting the token address and the encryption, only infiltration of both the organization (e.g., knowing the token address) and the encryption server (e.g., having access to the database) could any records be compromised.

Reference will now be made to the figures to explain certain aspects of the present disclosure. Although examples are generally discussed with reference to email addresses, this is merely an example. One of ordinary skill would recognize, in light of the present disclosure, that various types of data could be protected utilizing aspects of the present disclosure.

illustrates an example environmentin which one or more aspects of the present disclosure may be implemented. The example environment includes an encryption server, an encryption database, and an organization device. One or more of encryption server, encryption database, and organization devicemay be implemented within one or more computer system architectures, for example, as described below with reference to.

Encryption serverand encryption databasemay provide a data token service (e.g., a Mirage Data™ Token Service or “MDTS”). Organization devicemay be associated with an organization that subscribes to use the MDTS.

Organization devicemay maintain or have access to data (e.g., personally identifiable information, which may contain an email address or other user information) that needs to be protected from being misused, stolen, or otherwise disclosed. This data may relate to the organization's customers, vendors, employees, or any other individual or group of individuals. Organization devicewould provide unencrypted forms of the data (e.g., original unencrypted data (“OUD”)) to the encryption server. For example, organization devicemay provide the OUD through an API, a spreadsheet, or some other method. The encryption serverwould then process each OUD (e.g., each email) in order to provide token encrypted data (“TED”) (e.g., a token email address) to replace the OUD in the organization device.

Encryption servercould generate the TED using a random, pseudo-random, or ordered process. For example, if the OUD was an email address <real@original.example.com> the TED may be <blue-plate-3851@token.example.com> or <56789@token.com>. Thus, there may be no obvious connection between the OUD and the TED.

Organization devicecan replace all instances of the OUD stored within the organization with the TED. Organization devicewould no longer hold the OUD and thus, even if the organization were ever breached by a malicious actor, the stored data would not correspond to the actual data. In the case of an email address, the email address would be TED address processable by encryption serverand not a consumer's email address.

In order to map the OUD and TED, encryption servermay use a hash function which to convert the TED. The hash function may convert the TED to a numeric or alphanumeric representation with a very low or zero probability of collisions. The hash function may be a one-way function (e.g., a function where the output of the function is relatively easy to compute but using the hash output to determine the original data is computationally difficult or impossible). The encryption serverstores a hash of the TED with an encrypted form of the OUD in encrypted databaseto identify the record to convert from the TED to the OUD for delivery. This allows for a record to be identified without the encrypted serverfrom knowing the TED.

Encryption servermay encrypt the OUD using, for example, a key that is either provided by the service subscriber using the service or is implicit within the request. For example, the TED may be used as the key for the encryption algorithm to encrypt the OUD. The TED may also be used to decrypt the OUD. In some cases, an IP address or some unique identifier of organization devicethat cannot be easily assumed by a malicious actor could be used to encrypt that data. In some cases, two or more pieces of unique data could be used to encrypt the data. Given a sufficiently strong encryption algorithm, it would be difficult (or impossible within a reasonable time-frame) to decrypt the data payload without the related key and because the TED is not stored within the encryption serveror the encryption databasein an unencrypted or unhashed form. Thus, the encryption databasecould not be decrypted if it was compromised by a malicious actor. In some cases, each record with the MDTS may be encrypted with a unique key, making the encryption databasemore secure.

In some cases, encryption servermay be an email server that accepts and sends emails. Organization devicemay send an email to the TED email address, which can be received by encryption server. Encryption servermay receive the email, identify the TED, and hash the TED to identify the encrypted OUD within encryption database. Utilizing the TED or some other key, encryption serverdecrypts the OUD, replaces the TED within the email with the OUD, and forwards the email to the user. All traces of the TED may be removed from the email prior to sending.

In some cases, encryption databasemay also store a hash of the OUD and an encrypted form of the TED. When an email is sent to the organization, it may be received by encryption server. Encryption servermay receive the email, identify the OUD, and hash the OUD to identify the encrypted TED within encryption database. Utilizing the OUD or some other key, encryption serverdecrypts the TED, replaces the OUD within the email with the TED, and forwards the email to the organization device. All traces of the OUD may be removed from the email prior to sending to the organization device.

Tables 1 and 2 illustrate example database structures for encrypted databaseaccording to some examples. As can be seen, Table 1 illustrates a structure with a one-way identifier of TED (using a hash) to encrypted OUD, while Table 2 illustrates a structure of one-way identifiers with both TED (using a hash) to encrypted OUD and OUD (using a hash) to encrypted TED. However, these are merely examples, and one of ordinary skill would recognize that various alternative data structures would be considered within the scope of the present disclosure.

is a timing diagramof a data encryption method according to an example embodiment. Organization devicesendsan OUD to encryption server. Encryption servergeneratesa TED for the OUD and sendsthe TED to organization device. Organization devicereplacesthe OUD with the TED in its systems. For example, once complete, organization devicemay not store any copies of the OUD.

Encryption servergeneratesa hash of the TED and encryptsthe OUD. The hash function may convert the TED to a numeric or alphanumeric representation with a very low or zero probability of collisions. The hash function may be a one-way function (e.g., a function where the output of the function is relatively easy to compute but using the hash output to determine the original data is computationally difficult or impossible). The encryption may be a two-way encryption using various keys. For example, the TED could be used as an encryption key of the OUD. In some cases, an IP address or unique identifier of organization devicethat cannot be easily assumed by a malicious actor could be used to encrypt that data. In some cases, two or more pieces of unique data could be used to encrypt the data. In some cases, the key may be specified by organization device. Thus, the encryption databasecould not be decrypted if it was compromised by a malicious actor.

The TED hash links the encrypted OUD with the TED without requiring persistent knowledge of the TED. Encryption serversendsthe TED hash and the encrypted OUD to the encryption database. Encryption database storesthe TED hash associated with the encrypted OUD (e.g., the TED hash serves as a data key for the encrypted OUD). Encryption database senda confirmation to encryption server, which deletesthe TED and unencrypted OUD.

is a timing diagramof a data access method according to an example embodiment. Organization devicesendsa TED to encryption server. Encryption servergeneratesa hash of the TED and sendsthe TED hash to encryption database. Encryption databaseuses the TED hash (e.g., as a database key) to identifyan encrypted OUD related to the TED. Encryption databasesendsthe encrypted OUD to encryption server.

Encryption serverdecryptsthe OUD. For example, the TED may serve as a decryption key for the encrypted OUD. Additionally or alternatively, an identifier of organization devicemay be used as an encryption key. For example, an IP address or unique identifier of organization devicethat cannot be easily assumed by a malicious actor could be used to decrypt that OUD.

Encryption serversendsthe OUD to organization device, which temporarily replacesthe TED with the OUD. Once it is no longer needed, organization device may again replace the OUD with the TED and delete all instances of the OUD. Similarly encryption servermay deleteall copies of the TED an unencrypted OUD from its systems.

is a timing diagramof a data encryption method according to an example embodiment. Organization devicesendsan OUD to encryption server. Encryption servergeneratesa TED for the OUD and sendsthe TED to organization device. Organization devicereplacesthe OUD with the TED in its systems. Encryption servergeneratesa hash of the TED and encryptsthe OUD. Encryption serversendsthe TED hash and the encrypted OUD to the encryption database. Encryption database storesthe TED hash associated with the encrypted OUD. The actions discussed with reference to reference numbers-may eb substantially similar to similar elements discussed above with reference to.

Further, encryption servergeneratesa hash of the OUD and encryptsthe TED. The hash function may convert the OUD to a numeric or alphanumeric representation with a very low or zero probability of collisions. The hash function may be a one-way function (e.g., a function where the output of the function is relatively easy to compute but using the hash output to determine the original data is computationally difficult or impossible). The hash function may be a same hash function as that used to hashthe TED. The encryption may be a two-way encryption using various keys. For example, the OUD could be used as an encryption key of the TED. In some cases, two or more pieces of unique data could be used to encrypt the data. Thus, the encryption databasecould not be decrypted if it was compromised by a malicious actor.

The OUD hash links the encrypted TED with the OUD without requiring persistent knowledge of the TED or OUD. Encryption serversendsthe OUD hash and the encrypted TED to the encryption database. Encryption database storesthe OUD hash associated with the encrypted TED (e.g., the OUD hash serves as a data key for the encrypted OUD). Encryption database sendsa confirmation to encryption server, which deletesthe TED and unencrypted OUD.

is a timing diagramof a data replacement method according to an example embodiment. A third party devicesendsdata including an OUD to encryption server. For example, encryption servermay be an email server and third party devicemay send an email to an address associated with encryption server(e.g., directed to organization device). Encryption servergeneratesa hash of the OUD and sendsthe OUD hash to encryption database. Encryption databaseuses the OUD hash (e.g., as a database key) to identifyan encrypted TED related to the OUD. Encryption databasesendsthe encrypted TED to encryption server.

Encryption serverdecryptsthe TED. For example, the OUD may serve as a decryption key for the encrypted TED. Encryption serverreplacesthe OUD in the data with the decrypted TED and sendsthe data to organization deviceEncryption serverthen may deleteall copies of the TED an unencrypted OUD from its systems.

is a flowchartof a data encryption method according to an example embodiment. As a non-limiting example, the method may be performed by encryption server. At, encryption serverreceives an OUD, e.g., receives <real@original.example.com> from organization device. At, encryption servergenerated a TED, e.g., generates <56789@token.com>. Atencryption serversends the TED (e.g., <56789@token.com>) to organization device.

At, encryption serverhashes the TED (e.g., <H><56789@token.com>-->“12365”). At, encryption serverencrypts the OUD (e.g., <E><real@original.example.com>-->“lod982njASD˜!”). At, encryption serverstores the TED hash (“12365”) in association with the encrypted OUD (“lod982njASD˜!”). For example, the TED can serve as a data key for the encrypted OUD on encryptions database. At, the encryption serverdeletes the TED and OUD from its systems.

Although examples have generally been described with reference to email addresses, one of ordinary skill will recognize that email addresses server merely as examples. The MDTS may be coupled with other services to provide seamless protection and usage of data. For example, the MDTS could be coupled with a phone system to create TEDs that protect phone numbers but still allow a system subscriber to continue using OUD phone numbers for customers. For example, an OUD phone number might be 212-832-2000. The MDTS could create a TED such as 760-530-5000,8645110320. In this case, a phone system attached to the phone number 760-530-5000 would accept the call and the MDTS would use all or some of the TED to find the relevant entry, using a one way hash function, and decrypt the entry in the database and forward the call to 212-832-2000.

For postal addresses, the MDTS service could be employed to protect the addresses of individual recipients. Addresses would be printed on mail that would be the TED (e.g., 725 Fifth Ave, New York, NY 10022) and a package handling service (e.g., USPS, FedEx, UPS, or others) that wants to access the OUD of the address would interface with the MDTS. The MDTS would translate the TED into the OUD (e.g., 13777 Air Expressway Blvd, Victorville, CA 92394) to allow the package handling service to correctly deliver packages to the intended recipient and location. The TED may or may not appear to be a validly configured address and may or may not map to a real world address.

is a timing diagramof a data access method according to an example embodiment. Organization devicesendsan identifier to encryption server. Encryption servergeneratesa hash of the identifier and sendsthe identifier hash to encryption database. Additionally or alternatively, a key (e.g., password) may be provided by organization devicewhich may be used as a hash key and/or combined with the identifier to generate the hash. Encryption databaseuses the identifier hash (e.g., as a database key) to identifyan encrypted token related to the identifier. Encryption databasesendsthe encrypted token to encryption server.

Encryption serverdecryptsthe token. For example, the identifier may serve as a decryption key for the encrypted token. Additionally or alternatively, an identifier of organization devicemay be used as an encryption key. For example, an IP address or unique identifier of organization devicethat cannot be easily assumed by a malicious actor could be used to decrypt that token. Additionally or alternatively, a key (e.g., password) may be provided by organization devicewhich may be used as an encryption key.

Encryption serversendsthe token to organization device, which can identify the record in its database related to the token, which is, in turn, related to the identifier. Once it is no longer needed, organization device may delete the token and all references to the token. Similarly encryption servermay deleteall copies of the token, the identifier, and/or the password from its systems.

As a non-limiting example, the identifier may be a username (e.g., “miragedatamaster”) associated with a user account of organization device. Organization devicepasses the username to encryption serverin order to locate the user data associated the username is in its database. Encryption serveruses this username (“miragedatamaster”) and, optionally, more data (such as a key or password) to add more entropy to the encryption/hash process. Encryption serverhashes this username and sends the hash to encryption databaseto find the record in encryption database. Encryption servercan then use the username, and, potentially a key/password, to decrypt the row in encryption databaseidentified by the hash. The decryption yields a token that is not logically related to the username (i.e., the token's assignment may be random or pseudorandom). The token is then passed to organization device. Organization deviceuses the token to find the relevant user information in its database. Accordingly, as there is no logical relationship between the username and the data location within the database, it limits the ability of directly leveraging user names to gain access to a user account.

In some cases, additional user information can be stored in encryption databasealong with the token. For example, user contact information, such as an email address or phone number, or other sensitive information, such as an account number, can be stored in encryption databaseso as to protect the data from malicious actors with access to the organization deviceor encryption server. Organization devicemay temporarily replace redacted fields within the user account with this additional user information provided from encryption database.

According to aspects of the present disclosure, the approach protects every record of data with its own independent key, making a breach more difficult to execute as each record would need to be independently brute forced.

illustrates an example environmentin which one or more aspects of the present disclosure may be implemented. The example environment includes user devicein addition to encryption server, encryption database, and organization device. One or more of encryption server, encryption database, organization device, and user devicemay be implemented within one or more computer system architectures, for example, as described below with reference to. Encryption server, encryption database, and organization devicemay generally function somewhat similarly as discussed above with reference to.

User devicemay communicate with organization deviceand/or encryption server. User devicemay be controlled by a user of organization device. For example, the user may have a user account associated with organization device. When the user desires to log into its account, it may submit a username and/or password to organization device. Organization devicemay provide the username and/or password to encryption serverin order to receive a token indicated where in organization device's databases the user account data associated with the user is located.

In some cases, user devicemay provide a key (e.g., password) to encryption server. Encryption servercan use the key (e.g., together with the username) to generate a hash to send to encryption database. Additionally and/or alternatively, the key may be used to decrypt an encrypted token received by encryption serverfrom encryption database.