System and method for improving search capabilities of privately encrypted data

Abstract

Techniques are provided to allow encrypted data to be fully searchable within a database. In some embodiments, the searchable data can be separated into different searchable tables within the database in a manner such that the encrypted data is stored as plain text, but without any available links to other data in the source database. In some embodiments, performing a query on specific user data can result in the retrieval of an encrypted identifier, which can then be decrypted by an encryption module. A second search based on the decrypted identifier can produce a set of relevant search results from the source table.

Description

[0001] This application is a divisional application of the Chinese patent application with the application date of February 11, 2016, application number 201680009675.X, and name “Improving the Search Capability of Special Encrypted Data”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is a continuation of and claims the benefit of U.S. Provisional Application No. 62 / 114,976, filed February 11, 2015, which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0004] The present invention relates generally to data processing and more particularly to protecting encrypted data while allowing searches of the data, such as using wildcards. Background Art

[0005] Storing encrypted or otherwise private data is often a potential security risk for any entity. Personally identifiable information is often valuable to fraudsters, making data stores containing personally identifiable information a target for hacking attempts. Such private data can be encrypted within a database to protect it from hackers. However, encrypted data within a database may not be easily searchable. In many implementations, data is stored within the database using a hash function, and any query against the data must be an exact match of the hash value. This often requires the user to enter the exact value of the string to be searched. This exact value can be hashed using the hash function, and an exact match found. This can conflict with business requirements that require searching for personally identifiable information using wildcards or other partial data searches.

[0006] Encryption of encrypted data (such as address lines, telephone numbers, and fax numbers) is important for protecting the privacy of those identified. One problem is that once encrypted, these fields are difficult to access through searches. Many applications that use encrypted data may be written so that they require full-text searches on these fields. For example, a customer service representative (CSR) application relies on being able to search customer data when assisting customers. As an example, a CSR may enter a telephone number (e.g., 123-456-7890) in a search field and submit a search query. If the data being searched were not encrypted, the application would only need to perform a direct comparison to identify the relevant database record.

[0007] However, if the data to be searched is stored in an encrypted format, it may not be searchable. A typical solution to this problem is to use a hash function. For example, one solution might be to use a one-way cryptographic hash function. A universal hash function is a function that maps digital data of any size to other digital data of a fixed size. Cryptographic hash functions allow verification that input data matches a stored hash value while making it difficult to construct any data that hashes to the same value or to find any two unique data segments that hash to the same value.

[0008] The system can perform hash operations on the plaintext encrypted data and store these hashes. When a user submits a search query for a specific piece of encrypted data (e.g., the phone number 123-456-7890), the same hash operation is performed on the phone number and compared to the stored hash to determine if the hash matches any records. This solution is generally feasible when using precise search terms (e.g., where the user enters the complete and accurate data they are searching for).

[0009] Unfortunately, in a more typical scenario, a user might not enter the entire data they are searching for, in this case 123-456-7890, but instead might enter 123-456* or similar, where * represents a wildcard character. The user in this scenario would be submitting a wildcard search that is intended to produce a set of relevant results. However, in a system that requires an exact match to equal the hash value, this use of wildcards is not permitted.

[0010] Embodiments of the present invention address these and other problems individually and collectively. Summary of the Invention

[0011] To address the above issues, embodiments of the present disclosure may use one or more separate searchable tables that include plaintext (e.g., fully searchable text). Each fragment of clear data may correspond to source data, which is stored separately in encrypted form (e.g., in a separate row or separate table). As an example, the various fields of a source record may be stored as plaintext in separate locations so that the plaintext fields cannot be easily correlated to obtain all of the private information in the source record. In this way, a hacker who obtains a portion of the data cannot link the obtained data to an individual record in the source data. For example, a telephone number record may be stored separately from a plaintext address record and / or a plaintext name record in plaintext form so that the data is not available to an unauthorized party who maliciously obtains it.

[0012] In some embodiments, the data may be separated into different searchable tables (or equivalently, into separate rows of a table) in a manner such that the encrypted data is stored as plaintext, but without available links to other data in the database. In some embodiments, a unique encrypted foreign key may be stored with each fragment of plaintext data. The foreign key may be used to reference back to the source table in order to identify one or more records associated with the search string. For example, a search for user data (e.g., using a wildcard) may retrieve an encryption identifier, which may then be input into a decryption module (engine) to obtain a foreign key for accessing the source table where the data is encrypted, and where the individual's complete data record may be stored together, e.g., as a field in a row. The foreign key may then be used to search the source table based on the decryption identifier to return the desired encrypted data, which may be sent to the decryption module to provide the desired data.

[0013] Other embodiments relate to systems, devices, and computer-readable media associated with the methods described herein.

[0014] A better understanding of the nature and advantages of embodiments of the present invention may be obtained by reference to the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0016] Figure 1 depicts a sample database table schema according to at least some embodiments provided herein;

[0017] Figure 2 depicts an illustrative example of a service provider computer capable of providing backend support for a database platform according to at least some embodiments;

[0018] Figure 3 depicts a flow chart of a method 300 for searching a database for data, according to at least some embodiments of the present invention;

[0019] Figure 4 depicts a system diagram illustrating devices and data flows according to at least some embodiments provided herein;

[0020] Figure 5 Depicted are exemplary processes for performing searches on a database including encrypted data, according to at least some embodiments;

[0021] Figure 6 Described are processes for updating a database including encrypted data, according to at least some embodiments; and

[0022] Figure 7Aspects are depicted of elements that may be present in a computer device and / or system configured to implement methods and / or processes according to some embodiments of the present invention.

[0023] the term

[0024] Before discussing specific embodiments of the present invention, some terms may be described in detail.

[0025] A "client computer" may include any suitable computing device. A client computer may be operated by a consumer, a user associated with a business entity, or any other individual. The client computer may use any suitable wired or wireless network (including the Internet) to communicate with other systems. For example, a consumer client computer may be used by a consumer to interact with a merchant Internet storefront to conduct a transaction. A user associated with a merchant may use a merchant client computer to interact with other merchant computer systems and the described platform. Examples of computers and consumer mobile devices include any device capable of accessing the Internet, such as a personal computer, a cellular or wireless telephone, a personal digital assistant (PDA), a tablet PC, and a handheld dedicated reader.

[0026] A "database" may include any hardware, software, firmware, or combination thereof for storing and facilitating information retrieval. Furthermore, a database may use any of a variety of data structures, arrangements, and compilations to store and facilitate information retrieval.

[0027] A "database record," also known as a row or tuple, can refer to a single, implicitly structured data item in a database. Each database record in a source table can be associated with a specific person or entity. Each database record in a search table can include encrypted foreign keys, primary keys, and plaintext search fields.

[0028] "Personally identifiable information" may refer to any information that can be used to distinguish or trace an individual and that, alone or when combined with other personal or identifying information, is linked or linkable to a specific individual. For example, personally identifiable information may include an address, telephone number, date of birth, social security number, date and place of birth, mother's maiden name, biometric records, or any other suitable individual-specific information. Various legal requirements exist for the storage and use of personally identifiable information. Personally identifiable information may also include information that is linked or linkable to an individual, such as medical, educational, financial, and employment information.

[0029] A "processor" may include hardware within a mobile device (or other electronic device) that executes instructions embodied as code in a computer-readable medium (e.g., a non-transitory computer-readable medium). An exemplary processor may be a central processing unit (CPU). As used herein, a processor may include a single-core processor, multiple single-core processors, a multi-core processor, multiple multi-core processors, or any other suitable combination of hardware configured to perform arithmetic operations, logical operations, and / or input / output operations of a computing device.

[0030] "Server computer" may include any suitable computer that can provide communications to other computers and receive communications from other computers. A server computer may include a cluster of computers or computers. For example, a server computer may be a mainframe, a cluster of small computers, or a group of servers that work as a unit. In one example, a server computer may be a database server that is coupled to a network server. The server computer may be coupled to a database and may include any hardware, software, other logic, or a combination of the foregoing for servicing requests from one or more client computers. The server computer may include one or more computing devices and may use any of a variety of computing structures, arrangements, and compilations to serve requests from one or more client computers. Data transfer and other communications between components such as computers may be carried out through any suitable wired or wireless network (such as the Internet or a private network).

[0031] A "service computer" or "service provider computer" may include any system associated with an entity that provides a resource or service. In some embodiments, a service provider computer may handle the functionality of a computer application associated with the entity that provides the resource or service. A service provider may provide any suitable service. For example, a service provider may be a merchant, a utility company, a payment processing network, a wallet provider, a merchant, a website operator, or a bank. For the purposes of this disclosure, a service provider computer refers to the provider of the disclosed platform.

[0032] An "update" can include additions, deletions, transformations, or any other changes to existing database records. An update can also refer to the creation of new database records or entries. For example, an update can be the addition or deletion of data to a field in a database record, and / or an update can be the addition or deletion of an entire database record from a database table. An update can also refer to changes to text fields in a database record.

[0033] "User" may refer to an individual or entity that can access the described platform using credentials (e.g., merchant ID, user ID, and password) that the individual or entity is authorized to use. As used herein, a user may also refer to an individual or entity that is not authorized to access the described platform, but that has access to authorized credentials that allow them to access the described platform. A user may submit a search query through the user interface or console commands. DETAILED DESCRIPTION

[0034] According to at least some embodiments, the present disclosure relates to a database platform that can provide efficient search capabilities for personally identifiable information (or other encrypted data). When storing encrypted data in a database at rest is a potential security risk, the solution to this risk is to encrypt the data. However, encrypted data cannot be easily searched. The typical approach is to apply a hash of the encrypted data, which only allows searches for entries that exactly match the hash value. However, a business may require that such encrypted data be fully searchable, for example using wildcards. An embodiment may separate the data into multiple tables in a certain manner so that the encrypted data is stored in a clear manner, but without available links to other data within the database.

[0035] Described herein is a platform that can manage encrypted and other sensitive data to make it fully searchable. For example, an embodiment can generate multiple searchable tables that contain plaintext versions of encrypted data columns in a source table. The plaintext values ​​in the searchable tables are associated with encrypted foreign keys, which, when decrypted, allow users to query the data from the source table. In this way, each piece of plaintext data is stored without any available links to any other data associated with the record. In this way, encrypted data can be made searchable without requiring an exact match of the search string.

[0036] A searchable encrypted database scheme is described, which can be implemented according to some embodiments of the present disclosure. In addition, an exemplary database system is described, which can implement the searchable encrypted database scheme according to at least some embodiments. The present disclosure also relates to searching and updating the described database system.

[0037] I. Searchable database with encrypted data

[0038] A database table typically consists of one or more columns and one or more rows. A database table's columns typically represent searchable fields. A database table's rows typically represent individual records. Each individual record can have values ​​filled in for each column on that row. To perform a query on a database, you typically specify the column (for example, the field to search, such as a phone number) and provide a search string, which often contains wildcard characters. Rows with values ​​that match the search string within the column are returned as a result set. However, to protect sensitive data, some columns of a database table may be encrypted, meaning they contain indecipherable data. To search these columns, you typically need to provide the exact string of characters to search for, i.e., without wildcard characters. This string is then encrypted and compared to the value in the column.

[0039] In order to provide a database system with fully searchable encrypted data without providing an exact string of characters to be searched, the present disclosure discusses a database table scheme that can be implemented in at least some embodiments. In this database table scheme, a source table can include multiple columns of data, some of which may contain encrypted data, and some of which may contain plaintext data. One or more searchable tables (separate from the source table) can be generated for each encrypted column of the source table. The generated searchable tables can include plaintext columns that represent decrypted data from the corresponding encrypted columns of the source table. Figure 1 Describe the database table schema in more detail.

[0040] Figure 1 A sample database table schema 100 is depicted according to at least some embodiments provided herein. A database may contain one or more source tables containing a decrypted unique identifier (ID), one or more encrypted data items, and possibly additional plaintext or encrypted data fields. Figure 1 , source table 110 is depicted as including a unique ID primary identifier (MID) field 111 stored in plain text, an encrypted email address field 112, an encrypted phone number field 113, a first name field 114, and a last name field 115. The underlying data in the encrypted email address field 112 and the encrypted phone number field 113 can be considered private information (e.g., encrypted data). In some embodiments, other fields, such as the first name field 114 and / or the last name field 115, can also be encrypted.

[0041] Figure 1Also depicted are two searchable tables 120 and 130, each containing an encryption ID (122 and 132), plaintext encrypted data segments (121 and 131), and a table index ID (also referred to as primary keys 123 and 133). Search email table 120 is depicted as containing a plaintext email address column 121, with each plaintext email address located in a separate row of search email table 120. For example, search email table 120 may include a plaintext version of each encrypted value from the email address column of source table 110. Each email address may be stored as a separate row in search email table 120, with each row having a corresponding primary key and a corresponding encrypted unique ID. This allows the system to search for an email address, in whole or in part, to retrieve the associated encrypted identifier 122 (also referred to as MID).

[0042] Similarly, search phone number table 130 contains plaintext phone numbers 131, which allows the system to search for phone numbers in whole or in part to retrieve the associated encrypted identifier 132. The database table scheme may have a separate searchable table for each type of encrypted data stored in the database (e.g., a separate searchable table for each column of encrypted data in source table 110).

[0043] As shown, each MID 122 and 132 in the searchable table can be associated with MID 111 in the source table. However, the MIDs of the searchable table can be encrypted so that the MIDs cannot be easily linked to the corresponding source data. In some embodiments, MID 122 and / or MID 132 can be encrypted versions of MID 111. Using a decryption engine, the system can obtain a decrypted version of the retrieved MID and then use the decrypted version of the MID to search source table 110 to obtain encrypted information data, such as fields 112 and 113. The encrypted information data can then be decrypted.

[0044] In at least some embodiments, database system 100 provides for separation of personally identifiable information, wherein one type of encrypted data is stored in a searchable table so that the personally identifiable information is not directly associated with other encrypted data. For example, the phone number 123-456-7890 can be stored as plaintext in the phone number column of table searchable phone number 130, and the phone number plaintext data can be the only column of plaintext encrypted data included in the searchable table. Similarly, other pieces of encrypted data can also be stored as separate plaintext columns in separate searchable tables (e.g., without any other columns of encrypted data), making them worthless to fraudsters because fraudsters cannot link one piece of personal data to other pieces of data.

[0045] A searchable table, such as the email table 120, contains a column of plaintext encrypted data, in this case, the email field. In the example shown, the only other column of plaintext information in the searchable table, alongside the email address, may be a column containing an encrypted identifier. This identifier may be unreadable in the sense of being encrypted (e.g., an encrypted foreign key). In the depicted example, the encrypted identifier may be MID 122. Looking up a particular email address or portion of an email address in this table may return a list of zero or more encrypted MIDs. The resulting list of MIDs may be subjected to a decryption engine to identify a list of decrypted MIDs.

[0046] In some embodiments, the decrypted MID list can be used in a second query against the source table 110 to retrieve additional related encrypted data. Thus, once the encrypted foreign key is retrieved, it can be sent through the decryption engine to obtain the foreign key in plain text. Once the foreign key is obtained, it can then be used to perform a query on an additional table (e.g., the source table 110) that contains encrypted data related to the search string being queried. In some embodiments, the foreign key can correspond to an MID 111 (e.g., a record ID), which can be used to identify a record in the source table. However, a plain text match to the query or a portion thereof is required in order to first retrieve the encrypted foreign key before any data from the source table 110 can be retrieved. The query can return the corresponding first and last name, as well as an additional fragment of encrypted data corresponding to the email address originally searched. This additional encrypted data can be in encrypted or ciphertext format.

[0047] Thus, embodiments of the present disclosure may allow a system to perform full-text searches on encrypted data. Each of these types of encrypted data may be stored as plaintext within its own table, e.g. Figure 1 A searchable email table and a searchable phone number table are also available. Other example tables include, but are not limited to, mailing or business addresses, Social Security numbers, date and place of birth, mother's maiden name, biometric records, medical, education, financial, and employment information. Each of these searchable tables contains an encrypted foreign key ID column and a column for a specific type of plaintext data, where the encrypted foreign key ID for a given piece of plaintext data can be used to identify the record in the source table containing the plaintext data. Storing plaintext encrypted data in this manner allows for additional encryption without compromising the plaintext stored in the database, as it is not linked to other sensitive data.

[0048] II. Database System

[0049] To provide the above-described searchable database solution, the present disclosure discusses an exemplary database system (service provider computer) capable of implementing at least some embodiments of such a solution. The described service provider computer may include one or more databases and logic for providing encryption and decryption. The database system is relative to the following Figure 2 Describe in more detail.

[0050] Figure 2 Depicted are illustrative examples of a service provider computer capable of providing backend support for a database platform, according to at least some embodiments.

[0051] The service provider computer can be any type of computing device, including a remotely located server computer. Additionally, it should be noted that in some embodiments, the service computer 200 can be embodied by multiple virtual machines implemented in a hosted computing environment. A hosted computing environment can include one or more rapidly provisioned and released computing resources, which may include computing devices, network devices, and / or storage devices. A hosted computing environment can also be referred to as a cloud computing environment.

[0052] In one illustrative configuration, the service computer 200 may include at least one memory 202 and one or more processing units (or processors) 204. The processor 204 may be suitably implemented in hardware, computer-executable instructions, firmware, or a combination thereof. The computer-executable instructions or firmware implementation of the processor 204 may include computer-executable instructions or machine-executable instructions written in any suitable programming language for performing the various functions described.

[0053] Memory 202 can store program instructions that are loadable and executable on processor 204, as well as data generated during the execution of these programs. Depending on the configuration and type of service computer 200, memory 202 can be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). Service computer 200 can also include additional memory 206, such as removable or non-removable memory, including but not limited to magnetic storage, optical disks, and / or tape storage. Disk drives and their associated computer-readable media can provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computing devices. In some embodiments, memory 202 can include multiple different types of memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), or ROM. Turning to the contents of memory 202 in more detail, memory 202 can include an operating system 208 and one or more applications or services for implementing the features disclosed herein, including at least a module for encrypting or decrypting identifiers (encryption / decryption engine 210). Memory 202 may also include a database 212 that stores personally identifiable information and other data.

[0054] Removable and non-removable memory 202 and additional memory 206 are examples of computer-readable storage media. For example, computer-readable storage media can include volatile or non-volatile, removable or non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. As used herein, a module or engine can refer to a programming module executed by a computing system (e.g., a processor) that is stored on and executed by a user device or service computer 200. The service computer 200 can also include a communication connection 214 that allows the service computer 200 to communicate with one or more stored databases 212, another computing device or server, a user terminal and / or other devices over a network. The service computer 200 can also include input / output (I / O) devices and / or ports 216, such as for implementing connections with a keyboard, mouse, pen, voice input device, touch input device, display, speaker, printer, etc.

[0055] Turning to the contents of memory 202 in more detail, memory 202 may include an operating system 208. A database containing at least some encrypted data is shown, and the database may also be incorporated into memory 202 or a different memory. One or more applications or services for implementing the features disclosed herein, including encryption / decryption engine 210, may also be stored in memory 202. Encryption / decryption engine 210 may include separate sub-engines for encryption and decryption, which may share a common communication interface and / or a common library. Database 212 may include any suitable persistent data storage system. In some embodiments, database 212 may be stored in a database. The information stored in database 212 may be accessed by encryption / decryption engine 210 via a database query or any other suitable data retrieval device.

[0056] In some embodiments, the encryption / decryption engine 210 can be configured in conjunction with the processor 204 to encrypt and / or decrypt data provided to it. For example, the encryption / decryption engine 210 can be configured to decrypt encrypted foreign keys provided to it and encrypted data from a source table. In some embodiments, the encryption / decryption engine 210 can execute when it receives a request command (e.g., a call to an encryption or decryption function) that provides data to be encrypted or decrypted. In some embodiments, the data to be decrypted can be passed to the encryption / decryption engine 210 as a parameter of the function call. The encryption / decryption engine 210 can be provided with an encryption and / or decryption key as a parameter of the function call.

[0057] In some embodiments, the encryption / decryption engine 210 may perform a database lookup to identify the key. In some embodiments, the encryption / decryption engine 210 may utilize hard-coded encryption / decryption keys and / or encryption algorithms. The encryption / decryption engine 210 may utilize any suitable encryption or decryption algorithm to encode the data within the database 212. In some embodiments, the encryption / decryption engine 210 may include a hardware security module (HSM) that is capable of protecting and managing digital keys for strong authentication and cryptographic processing. The hardware security module may be a physical computing device configured to protect and manage digital keys for strong authentication. The hardware security module may also be configured to provide cryptographic processing.

[0058] In some embodiments, database 212 may include information to be associated with various individuals. Database 212 may include a source table and one or more searchable tables, each associated with a piece of identifiable information about an individual. In some embodiments, database 212 may include at least some ciphertext data and at least some plaintext data. In some embodiments, both ciphertext and plaintext versions of the same data may be stored in database 212. For example, the primary identifier of a searchable table may be a ciphertext version of the plaintext primary identifier of a source table. In some embodiments, all data in one or more columns of a table may be encrypted. In some embodiments, data encrypted in one table may utilize a different encryption / decryption key than data encrypted in a second table.

[0059] III. Searching Databases with Encrypted Data

[0060] To utilize the above scheme, the database system can initiate a database query. In some embodiments, a user can provide an indication of a field or column to be searched and a search string (e.g., an alphanumeric string for which matching data should be found). The database system can be configured to identify an appropriate searchable table (e.g., based on the indicated field or column), identify a foreign key associated with matching data within the searchable table, and query a source table to obtain information related to the identified foreign key. In the present disclosure, a method for searching a database having encrypted data, a data flow associated with a database search, and an exemplary process for performing a search on a database including encrypted data are described below.

[0061] A. Method

[0062] Figure 3 Depicted is a flow chart of a method 300 for searching a database for data, in accordance with at least some embodiments of the present invention. The method 300 may be performed by a search system executable by a computer database system and a search machine.

[0063] At block 310, the computer database system receives a query for a requested field value. The requested field value may include an indication of the field or column from which the value is to be returned. For example, the query may include the phrase "select last_name," indicating that the value in the last name field is to be returned for any record in the result set. The query may also include a search string. The search string may include wildcard characters to specify only a portion of the desired string that matches the desired data. For example, if searching for a telephone number, the search string may be 123-456-*, where * is a wildcard character.

[0064] In some embodiments, a query may specify one or more fields or columns to search. For example, a query may include the language "where phone_number = '123-456*'", which indicates that the phone number field of the source table is to be searched for the search string. In some embodiments, multiple fields and search strings may be provided. For example, a query may include the language "where phone_number = '123-456*' and city = 'Houston'. In this example, the query may return a result set that includes all records that match both conditions.

[0065] At block 320, a first table of a computer database system is searched using the search string to identify one or more matching values. The first table can be identified based on a field indicated in the query. For example, the field in the query can refer to an encrypted column of a source table. The first table can be a searchable table having a plaintext column with data corresponding to the encrypted column of the source table. The database system can compare the search string with the values ​​stored in the plaintext column to identify one or more values ​​that match the provided search string. For example, the value 123-456-7890 and the value 123-456-1234 are both matches for the search string 123-456*. In this example, both records of the first table will be returned as having matching values.

[0066] At block 330, the search of the first table results in one or more encrypted foreign keys corresponding to the obtained matching values ​​of the search string. Once the database system identifies one or more matching values ​​from the plaintext column of the first table at block 320, the database system identifies the values ​​from the foreign key fields of the records containing the matching values. For example, if the first table is Figure 1 The search of the telephone number table 130 will return the corresponding encrypted foreign keys for any records associated with telephone numbers that match the search string.

[0067] At block 340, the encrypted foreign key is sent to a decryption engine for decryption. The decryption engine may apply one or more decryption algorithms to the encrypted foreign key to decrypt the foreign key. In some embodiments, the one or more decryption algorithms may utilize a decryption key. In some embodiments, the decryption key used by the decryption engine may depend on the searchable table from which the encrypted foreign key was obtained. For example, each searchable table may be associated with a different decryption key. Decryption of the foreign key by the decryption engine may result in a plaintext version of the foreign key. The decryption engine may correspond to Figure 2 The encryption / decryption engine 210.

[0068] At block 350, the decrypted foreign key is received back from the encryption / decryption engine. At this block, the foreign key may be provided to the database system in a response message. In some embodiments, the decrypted foreign key may be returned by a function.

[0069] At block 360, a second table of the database is searched for one or more encrypted field values ​​corresponding to the decrypted foreign key obtained in block 350. For example, the second table may be Figure 1 The encrypted email and phone number corresponding to the decrypted foreign key can be retrieved from the database. Additionally, if plaintext data exists in the second table, it can also be retrieved. For example, in source table 110, first and last names are stored in plaintext, and a search can also retrieve these field values. In some embodiments, specific field values ​​can be requested in a query. For example, a query can specify the fields for which values ​​are returned from the source table relative to the search string.

[0070] At block 370, any encrypted field values ​​retrieved in block 360 may be sent to a decryption engine for decryption. At this block, the decryption engine may subject the encrypted field values ​​to one or more decryption algorithms to obtain a decrypted version of the field value. In some embodiments, each field of the source table may be associated with a separate decryption key.

[0071] The decrypted user data is received from the decryption engine at block 380. Once decrypted, it may be sent back to the requestor, possibly along with any plaintext data that was retrieved.

[0072] The system can separate the storage of different pieces of encrypted data, including but not limited to phone numbers, email addresses, and mailing addresses. Because they are all stored together, someone with access to the database could easily obtain all of an individual's related encrypted data. However, if each one appears only in plaintext in a separate table and within the encrypted portion of the same table, it becomes much more difficult to link those encrypted data items to the same entity and the same person without access to the decryption engine. Even if the database is stolen or accessed without permission, the data is unavailable because the tables are not connected.

[0073] Once the system has a foreign key to a specific piece of encrypted data, it can use that foreign key to retrieve additional, related encrypted data from other database tables. It can then perform additional queries to retrieve the data from the database. The user issuing the query will never see the foreign key, as it doesn't need to be returned to the user, but internal systems can use it to retrieve additional encrypted data. System users will never actually retrieve the external encryption key; instead, the system will use it for subsequent steps, but the system will never need to send the external encryption key back to the system user.

[0074] B. Data Flow

[0075] Figure 4A system diagram illustrating devices and data flows according to at least some embodiments provided herein is depicted. The service computer 400 has software that allows users to enter the search data they wish to obtain. In some embodiments, the service computer 400 may be Figure 2 An exemplary service computer 200 is shown.

[0076] When a search string is entered into the search interface, the database 430 is queried using the search string, e.g., Figure 3 The query may include a service computer 400 sending a search string 401 to a database 430 in an attempt to find data corresponding to the search string 401. The search interface may be executed from a client device in communication with the service computer 400 via a network interface. The search interface may be a browser application (e.g., a web browser) installed on and executed from a remotely located client device.

[0077] In some embodiments, the search interface can be a graphical user interface (GUI) implemented on and executed from a client device. The GUI can be associated with an application or program that communicates with the database system. For example, a plurality of searchable fields can be presented to a user via a GUI implemented on a remote client device. The user can enter a search string into any of the presented searchable fields. Upon detecting that the user has entered one or more search strings into one or more of the searchable fields, the GUI can send the entered search strings to the database system with an indication of the searchable fields in which they were entered.

[0078] At 402, the database 430 returns a result set of one or more encrypted foreign keys corresponding to the search string. If an encrypted foreign key is included in a foreign key field of a record or row in which the value of the plaintext field matches the search string, the encrypted foreign key may correspond to (be related to) the search string. In other words, once a plaintext value is identified as matching the search string, the foreign key value in the same row of the searchable table is appended to the result set to be returned as the plaintext value. In some embodiments, multiple plaintext values ​​within a plaintext value column may be identified as matching the search string. In this case, each encrypted foreign key for each row containing the identified plaintext value may be appended to the result set.

[0079] The service computer 400 sends the external encryption key from the result set to the decryption engine 420 for decryption. The decryption engine will know how to decrypt the foreign key using the external encryption key, the table name, and possibly a cryptographic nonce. Once decrypted, the decryption engine 420 will send the decrypted foreign key 403 to the service computer 400. The method 300 can use the encryption / decryption engine 420 to decrypt the encrypted data obtained and used in the search.

[0080] The service computer 400 then sends another search query including the decrypted foreign key 403 to the database 430 . The database 430 then searches for data corresponding to the decrypted foreign key 403 and returns the encrypted user data 404 to the service computer 400 .

[0081] The service computer 400 then sends the encrypted user data 404 to the decryption engine 420 for decryption. Once the encrypted user data 404 is decrypted, the decrypted user data 405 is sent to the service computer 400. The service computer 400 may then provide a response to the query, for example, via a search interface.

[0082] C. Exemplary Process

[0083] To utilize the disclosed invention, a database system may be configured to execute one or more processes on the described database solution. Some or all (or variations and / or combinations thereof) of any of the processes described herein may be executed under the control of one or more computer systems configured with executable instructions, and may be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications). According to at least one embodiment, one or more processes may be performed by at least Figure 1 The code may be stored on a computer-readable storage medium, for example, in the form of a computer program comprising a plurality of instructions executable by one or more processors. The computer-readable storage medium may be non-transitory. The following description highlights an exemplary process for identifying and returning a set of decrypted source data that may be initiated by a database system when it receives an information request.

[0084] Figure 5 Depicted is an exemplary process for performing a search on a database including encrypted data, according to at least some embodiments. Process 500 is illustrated as a logical flow diagram, each operation of which represents a series of operations that can be implemented by hardware, computer instructions, or a combination thereof. In the context of computer instructions, an operation represents a computer-executable instruction stored on one or more computer-readable storage media that, when executed by one or more processors, performs the operation. Generally speaking, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a specific function or implement a specific data type. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be omitted or combined in any order and / or in parallel to perform this process and any other process described herein.

[0085] At 502, a query (request information) is received. The query may include a search string and an indication of a column. In some embodiments, each column of a source table may be associated with a different searchable table. Each different searchable table may have a decrypted version of the column, an encrypted version of the primary identifier, and an index.

[0086] At 504, when determining which column is associated with the search string, a searchable table associated with the search string can be identified. For example, if the indicated column is a "phone_number" column, the searchable table can be a "phone_number" table, which includes a column of plaintext phone number data. In some embodiments, a query can be mapped to a specific searchable table via a graphical user interface (GUI). For example, a plurality of searchable fields can be presented to a user via a GUI implemented on a client device. The user can enter the search string into any of the presented searchable fields. In this example, each searchable field can be associated with a searchable table. As an illustration, a user can enter a search string into a searchable field labeled "First Name," which can be associated with a "first_name" searchable table. In this illustrative example, the "first_name" searchable table can be identified, and the search string can be queried for a plaintext column within the searchable table.

[0087] At 506, the searchable table can be queried to determine a set of rows related to the search string based on the values ​​from the decrypted version of the column data that matches the search string in each row. In some embodiments, the query can return a 0-N result set, where N is the total number of rows in the searchable table. Each returned result in the result set can include multiple encrypted identifiers. In some embodiments, the result set can include a single encrypted identifier.

[0088] At 508, process 500 may generate a set of decrypted identifiers by decrypting each encrypted identifier in the search result set. In some embodiments, each encrypted identifier in the search result set may be sent separately to a decryption engine. The decryption engine may decrypt each encrypted identifier and append the decrypted identifier to the set of decrypted identifiers. In some embodiments, the entire search result set may be provided to the decryption engine, which may then generate a set of decrypted identifiers from the set of encrypted identifiers.

[0089] At 510, when a set of decryption identifiers is generated, a source table may be queried to identify a set of encrypted data corresponding to each decryption identifier. In this step, encrypted data for one or more records associated with each decryption identifier may be returned. For example, a source table may be queried to identify records in which a primary identifier matches one of the set of decryption identifiers. For each of these records, one or more fragments of the encrypted source data may be retrieved from the source table. In some embodiments, one or more fragments of the encrypted source data may be specified in the received query. For example, a query may specify "select first_name and last_name," in which case the encrypted values ​​in the first name and last name fields may be appended to a set of encrypted source data. The returned encrypted source data may be decrypted to identify one or more personally identifiable information data.

[0090] At 512, once the set of encrypted source data has been identified, the encrypted data can be decrypted. In some embodiments, the decrypted data can be filtered or otherwise narrowed based on other criteria. For example, the decrypted data can consist of multiple rows that are relevant to the provided search string. In this example, the most appropriate row can be determined based on the second search string. As an illustration, after searching a database for a set of customer records based on phone number, the set of customer records can be narrowed based on name or address. A customer record can include a set of data associated with a particular user (e.g., the value of each column in the database row associated with the user).

[0091] At 514, the set of decrypted source data may be provided in response to the submitted query. In some embodiments, the set of decrypted source data may be provided to the user who submitted the query. In some embodiments, the set of decrypted source data may be provided to a database system so that further action may be taken with respect to the information in the set of decrypted source data. For example, the set of decrypted source data may be provided in a database system such as the one referenced below. Figure 6 Used during the update process as described.

[0092] As an illustration, consider a scenario in which a user attempts to retrieve information related to a particular user based on a phone number. The user may submit a query related to an individual by querying a database for the phone number. To do so, a source table column associated with the phone number may be identified. In some embodiments, the user may specify a column associated with a piece of personally identifiable information. In some embodiments, the personally identifiable information may be entered into a field associated with a particular table column via a user interface.

[0093] In the above example, a user may enter at least a portion of an individual's phone number into a phone number input field of a graphical user interface. Upon submitting a query, a searchable table associated with the phone number column may be queried to locate the entered phone number or portion of the phone number. Upon identifying one or more rows of the phone number search table that match the entered phone number, a set of encrypted identifiers may be returned. The encrypted identifiers may be decrypted to determine a set of rows associated with the phone number. Additional information from the identified rows may be returned to the user. For example, a list of names of individuals whose phone numbers matched may be provided to the user. In some embodiments, specific column values ​​or field values ​​may be retrieved relative to a search string. For example, values ​​in a name column may be provided in response to a query for a phone number search string.

[0094] IV. Update the database

[0095] The described database solution includes a source table with encrypted and plaintext columns, and multiple searchable database tables, each associated with the encrypted columns of the source table. In some cases, it may be necessary to update one or more field values ​​in one or more database tables. For example, when the system receives new information, it may be necessary to change or update the data stored in the database system. In some embodiments, updates are made to a single table (the source table), and these changes are propagated to the remaining database tables.

[0096] Figure 6 Depicted is a process 600 for updating a database including encrypted data, according to at least some embodiments. In some cases, it may be necessary to update or edit data stored in accordance with the present disclosure.

[0097] At block 602, a user may identify one or more rows in a source table that are associated with a data segment to be updated. According to at least some embodiments, process 600 may be performed by first querying a searchable table to identify an encryption identifier and then querying the source table to find the data to be updated. Figure 5 Describes the process of identifying one or more rows to update.

[0098] At block 604, upon identifying one or more rows to update, the rows to be updated may be determined by comparing other information within the row with additional information associated with the individual. In some embodiments, the update request may include additional information that may be used to determine which row to update. For example, the update request may include the statement "where phone_number = '123-456*' and name = 'John Smith'." In this example, multiple rows may be identified based on the search string '123-456*', and the multiple rows may be filtered to include only those rows that are also associated with a name value equal to "John Smith."

[0099] At block 606, once the appropriate row in which the data is to be updated is identified, the new data may be encrypted using an encryption algorithm / encryption key appropriate for that row and column. In some embodiments, the new data may be provided to an encryption engine for encryption. The encryption engine may be Figure 2 An exemplary encryption / decryption engine 210 of .

[0100] At block 608, the old data to be replaced in the source table can then be updated with the encrypted version of the new data. In some embodiments, changes to the source table can be published to one or more searchable tables. For example, after detecting a change in data in a column of a source table, the searchable table associated with the column can be updated to incorporate the change.

[0101] At block 610, once data is updated in the source table, the changes can be published to the searchable table. For example, the database system can determine which columns of the source table have been updated. In this example, the searchable table associated with these columns can be updated to incorporate the new information. In another example, one or more searchable tables can be regenerated on a periodic basis. In this example, a new version of the searchable table can be generated to replace the old version, where the new version contains the updated information.

[0102] As an illustration, consider a scenario where a user wishes to update the phone number associated with a recorded individual. In this scenario, if the user wants to change the individual's phone number from 123-456-7890 to 987-654-3210, where the individual's name is John Smith, the searchable phone number table is first queried for the phone number 123-456-7890, and a result set can be returned. The result set can include a set of encrypted foreign keys linking to the source table. After decrypting the foreign keys using the returned set of encryption keys, the source table can be queried. In the above example, the row associated with the phone number 123-456-7890 can be identified in the source table by querying the unencrypted foreign keys returned from the searchable table. The information in the row can then be compared with the name John Smith to identify the correct row to update. Once the correct row is identified, the phone number 987-654-3210 can be encrypted. The phone number field of the identified row is then updated with the encrypted new phone number. This new phone number can then be published to one or more searchable tables.

[0103] V. Exemplary Computer Systems

[0104] According to at least some embodiments, the systems, apparatuses, methods, processes and / or operations of a database platform capable of providing efficient search capabilities for personally identifiable information (or other encrypted data) may be implemented, in whole or in part, in the form of a set of instructions executed by one or more programmed computer processors, such as central processing units (CPUs) or microprocessors. Such processors may be incorporated into an apparatus, server, client, or other computing device that is operated by or communicates with other components of the system. As an example, Figure 7 Aspects are depicted of elements that may be present in a computer device and / or system 700 configured to implement methods and / or processes according to some embodiments of the present invention. Figure 7 The subsystems shown in FIG. 7 are interconnected via a system bus 702. Additional subsystems include a printer 704, a keyboard 706, a fixed disk 708, and a monitor 710, which is coupled to a display adapter 712. Peripheral devices and input / output (I / O) devices coupled to an I / O controller 714 can be connected to the computer system by any of a number of means known in the art, such as a serial port 716. For example, a serial port 716 or an external interface 718 can be used to connect the computer device 700 to a computer system. Figure 7 Other devices and / or systems not shown include a wide area network such as the Internet, a mouse input device, and / or a scanner. The interconnection via the system bus 702 allows one or more processors 720 to communicate with each subsystem and control the execution of instructions that may be stored in the system memory 722 and / or the fixed disk 708, as well as the exchange of information between the subsystems. The system memory 722 and / or the fixed disk 708 may contain tangible computer-readable media.

[0105] A computer system can include multiple identical components or subsystems connected together, for example, via external or internal interfaces. In some embodiments, the computer system, subsystem, or device can communicate via a network. In this case, one computer can be considered a client and another computer can be considered a server, where each computer can be part of the same computer system. The client and server can each include multiple systems, subsystems, or components.

[0106] Embodiments of the present invention provide numerous technical advantages. For example, embodiments of the present invention enable users to efficiently query databases containing encrypted data using wildcard characters or portions of text strings. Furthermore, the present invention can separate personally identifiable information into separate, unlinkable tables, so that even if a portion of the data were obtained by a fraudster, the obtained information would be useless to the fraudster because he or she would not be able to obtain additional information.

[0107] It should be understood that any embodiment of the present invention can be implemented in a modular or integrated manner using hardware (e.g., an application specific integrated circuit or a field programmable gate array) and / or computer software in the form of control logic with the aid of a general-purpose programmable processor. As described herein, the processor includes a single-core processor on the same integrated chip, a multi-core processor, or a plurality of processing units on a single circuit board or networked. Based on the disclosure and teachings provided herein, those skilled in the art will know and appreciate other ways and / or methods of implementing embodiments of the present invention using hardware and combinations of hardware and software.

[0108] Any software components or functions described in this application can be implemented as software code executed by a processor using any suitable computer language (for example, Java, C, C++, C#, Objective-C, Swift) or scripting language (such as Perl or Python), using, for example, traditional or object-oriented techniques. The software code can be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission, suitable media including random access memory (RAM), read-only memory (ROM), magnetic media such as hard drives or floppy disks, or optical media such as compact disks (CDs) or DVDs (digital versatile disks), flash memory, etc. The computer-readable medium can be any combination of these storage or transmission devices.

[0109] Carrier signal encoding and transmission these programs can also be used, and carrier signal is suitable for transmitting via the wired, optical and / or wireless network that meets various protocols (comprising the Internet).Therefore, the computer-readable medium according to at least some embodiments of the present invention can use the data signal with these program encodings to create.The computer-readable medium with program code encoding can be packed together with compatible devices or provide (such as downloading by the Internet) individually from other equipment.Any such computer-readable medium can reside on or within a single computer product (such as hard disk, CD or whole computer system), and can appear on or within the different computer products in a system or network.Computer system can comprise monitor, printer or other suitable displays for providing any result mentioned herein to the user.

[0110] The above description is illustrative and not restrictive. After reading this disclosure, those skilled in the art will understand many variations of the present invention. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the appended claims together with their full scope or equivalents.

[0111] One or more features of any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.

[0112] Unless clearly indicated to the contrary, references to "a", "an", "the" or "said" are intended to mean "one or more".

[0113] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference for all purposes. No admission is made that they are prior art.

Claims

1. A method for storing sensitive data, comprising: Receiving, by a computer database system, an update request including a plurality of sensitive data; encrypting the plurality of sensitive data by the computer database system to obtain encrypted versions of the plurality of sensitive data; generating a source database record in a source table to include an unencrypted version of the identifier and the encrypted versions of the plurality of pieces of sensitive data; identifying a set of searchable tables associated with the plurality of sensitive data, each searchable table corresponding to a single type of sensitive data recorded in the source database; as well as A search database record is generated in each of the set of searchable tables, the search database record including an encrypted version of the identifier and a plaintext version of a single piece of sensitive data from the plurality of pieces of sensitive data, wherein the encrypted version of the identifier for each searchable table is encrypted using an encryption key that is different for each searchable table in the set of searchable tables.

2. The method of claim 1, wherein the encrypted version of the identifier of each searchable table is encrypted using a hardware security module (HSM). 3 . The method of claim 1 , wherein each row in the source table represents different account information, and wherein the account information is received via a request to generate a new account associated with the account information. 4 . The method of claim 1 , wherein the set of searchable tables associated with the plurality of pieces of sensitive data are identified based on a type of sensitive data included in the plurality of pieces of sensitive data.

5. The method according to claim 1 also includes updating the corresponding encrypted version of the single sensitive data among the multiple sensitive data in the searchable table after detecting that the plaintext version of the single sensitive data among the multiple sensitive data has been modified in the source table. 6 . The method according to claim 1 , wherein the encrypted version of the identifier and the plaintext version of the single sensitive data among the multiple sensitive data recorded in the search database are generated in the same row of the searchable table. The method of claim 1 , wherein each searchable table comprises an encrypted identifier column, a plaintext data column, and / or an index column. The method of claim 1 , wherein the source table comprises a plaintext identifier column and a plurality of encrypted data columns.

9. The method of claim 1, wherein the source database record is a row of the source table.

10. A database system comprising: processor; as well as a memory element comprising code that, when executed by the processor, causes the database system to at least: receiving an update request including multiple pieces of sensitive data; encrypting the multiple pieces of sensitive data to obtain encrypted versions of the multiple pieces of sensitive data; generating a source database record in a source table to include an unencrypted version of the identifier and the encrypted versions of the plurality of pieces of sensitive data; identifying a set of searchable tables associated with the plurality of sensitive data, each searchable table corresponding to a single type of sensitive data recorded in the source database; as well as A search database record is generated in each of the set of searchable tables, the search database record including an encrypted version of the identifier and a plaintext version of a single piece of sensitive data from the plurality of pieces of sensitive data, wherein the encrypted version of the identifier for each searchable table is encrypted using an encryption key that is different for each searchable table in the set of searchable tables.

11. The database system of claim 10, wherein the encrypted version of the identifier of each searchable table is encrypted using a hardware security module (HSM).

12. The database system of claim 10, wherein each row in the source table represents different account information, and wherein the account information is received via a request to generate a new account associated with the account information.

13. The database system of claim 10, wherein the set of searchable tables associated with the plurality of pieces of sensitive data are identified based on a type of sensitive data included in the plurality of pieces of sensitive data.

14. The database system according to claim 10 further includes updating the corresponding encrypted version of the single sensitive data among the multiple sensitive data in the searchable table after detecting that the plaintext version of the single sensitive data among the multiple sensitive data has been modified in the source table. 15 . The database system according to claim 10 , wherein the encrypted version of the identifier and the plaintext version of the single sensitive data among the multiple sensitive data of the search database record are generated in the same row of the searchable table.

16. The database system according to claim 10, wherein each searchable table comprises an encrypted identifier column, a plaintext data column and / or an index column. The database system according to claim 10 , wherein the source table comprises a plaintext identifier column and a plurality of encrypted data columns. The database system of claim 10 , wherein the source database record is a row of the source table.

Images