Patent Description:
There are, however, some security, functionality, and efficiency challenges associated with client-side encryption, particularly with respect to the abilities to provide data searches. For example, a client that encrypts its data and transmits the encrypted data to a data storage service for storage may later wish to use the data storage service to perform a search (e.g., a search for customers who are located within a particular region, a search for customers having a certain name, etc.). The data storage service should therefore provide the ability to search for particular text or content as requested by a client. However, because the data storage service only has access to the encrypted customer data (i.e., unreadable data), the data storage service may not be able to carry out meaningful searches for the client. As a result, technological problems arise because the goals of data security and searchability directly conflict.

There are thus needs for technological solutions to provide, facilitate, and process search requests in data storage services that support client-side encryption without requiring decryption of the encrypted data, accessing the client's data in plaintext, or otherwise compromising the integrity of client-side encryption. As discussed below, technological solutions should be secure, efficient, and promote usability by clients who have encrypted certain data for storage.

Document <CIT> discloses an encrypted search index for performing searches on encrypted documents. Document <CIT> as well as document "<NPL>ET AL also disclose methods for searching on encrypted data.

The embodiments described below relate to implementing, as a microservice at a client, a searchable-encryption service. For example, a computer-implemented method for dynamically changing an encryption technique for encrypted data to be stored in a searchable database is disclosed. The method comprises: receiving encrypted data for storage in the searchable database, the encrypted data having been encrypted by a client using a cryptographic key based on an encryption alteration scheme; receiving a search query from the client, the search query comprising a plurality of search strings including at least: an encrypted version of a plaintext string that was encrypted by the client using the cryptographic key, and one or more encrypted versions of the plaintext string that were encrypted by the client using one or more other cryptographic keys; processing the search query to generate a response to the search query; and returning the response to the search query to the client.

The cryptographic key may be created by the client or obtained by the client from an external key resource.

Different portions of the received encrypted data for storage in the searchable database may have been encrypted using at least two of: the cryptographic key and the one or more other cryptographic keys.

The response returned to the client may include encrypted data stored in the searchable database matching at least a portion of the search query.

The response returned to the client may be configured to be decrypted using at least one of: the cryptographic key or the one or more other cryptographic keys.

The encryption alteration scheme may comprise selecting the cryptographic key from among a set of cryptographic keys including the one or more other cryptographic keys.

The cryptographic key may be chosen randomly among the set of cryptographic keys.

The encryption alteration scheme may comprise encrypting the plaintext string with each of the cryptographic key and the one or more other cryptographic keys.

The search query from the client may include versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys.

Processing the search query may comprise querying the searchable database based on each of the versions.

Also disclosed is another computer-implemented method for dynamically changing an encryption technique for encrypted data to be stored in a searchable database. The method comprises: sending encrypted data for storage in the searchable database, the encrypted data having been encrypted by a client using a cryptographic key based on an encryption alteration scheme; formulating a search query, the search query comprising a plurality of search strings including at least: an encrypted version of a plaintext string that was encrypted by the client using the cryptographic key, and one or more encrypted versions of the plaintext string that were encrypted by the client using one or more other cryptographic keys; sending the search query to the searchable database; and receiving a response to the search query from the searchable database.

The search query may include versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys.

The searchable database may be configured to perform a query based on each of the versions.

Different portions of the encrypted data sent to the searchable database may have been encrypted using at least two of: the cryptographic key and the one or more other cryptographic keys.

The client may be configured to decrypt the response to the search query using at least one of: the cryptographic key or the one or more other cryptographic keys.

Also disclosed is a computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform any of the computer-implemented methods referenced above.

In an example embodiment there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for implementing, as a microservice at a client, a searchable-encryption service. The operations may comprise executing the microservice at the client to perform operations including: encrypting data based on a cryptographic key accessible to the client; sending the encrypted data to a network storage resource; identifying, at the microservice, a search query in plaintext; encrypting the search query according to the cryptographic key; sending the encrypted search query to the network storage resource; and receiving a response to the encrypted search query from the network storage resource.

According to some embodiments, the microservice operates in a stateless manner on the client.

According to some embodiments, the microservice is deployed at the client as part of a virtualized environment scaling process.

According to some embodiments, the client has exclusive control over the data.

According to some embodiments, the client has exclusive control over destruction of the data, e.g., by destructing the encryption key that only the client has.

According to some embodiments, the data is a concatenation of a plurality of database elements.

According to some embodiments, encrypting the data based on the cryptographic key includes separately encrypting the plurality of database elements.

According to some embodiments, encrypting the data based on the cryptographic key includes encrypting, as a group, the plurality of database elements.

According to some embodiments, the client creates the cryptographic key.

According to some embodiments, the client obtains the cryptographic key from an external key resource. For example, the client may obtain the cryptographic key from an encryption service on the client side that has the capability to generate cryptographic keys.

Additional embodiments relate to a computer-implemented method for implementing, as a microservice at a client, a searchable-encryption service. The method may comprise executing the microservice at the client to perform operations including: encrypting data based on a cryptographic key accessible to the client; sending the encrypted data to a network storage resource; identifying, at the microservice, a search query in plaintext; encrypting the search query according to the cryptographic key; sending the encrypted search query to the network storage resource; and receiving a response to the encrypted search query from the network storage resource.

According to some embodiments, the network storage resource does not have access to the cryptographic key.

According to some embodiments, the network storage resource is configured to query stored encrypted data based on the encrypted search query.

According to some embodiments, the client has exclusive control over destruction of the data.

According to some embodiments, the client obtains the cryptographic key from an external key resource.

Additional disclosed embodiments relate to dynamically changing an encryption technique for encrypted data to be stored in a searchable database. For example, in an example embodiment there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for dynamically changing an encryption technique for encrypted data to be stored in a searchable database. The operations may comprise receiving encrypted data for storage in the searchable database, the encrypted data having been encrypted by a client using a cryptographic key based on an encryption alteration scheme; receiving a search query from the client, the search query comprising a plurality of search strings including at least: an encrypted version of a plaintext string that was encrypted by the client using the cryptographic key, and one or more encrypted versions of the plaintext string that were encrypted by the client using one or more other cryptographic keys; processing the search query; and returning a response to the search query to the client.

According to some embodiments, the encryption alteration scheme comprises selecting the cryptographic key from among a set of cryptographic keys including the one or more other cryptographic keys.

According to some embodiments, the cryptographic key was chosen randomly among the set of cryptographic keys.

According to some embodiments, the encryption alteration scheme comprises encrypting the plaintext string with each of the cryptographic key and the one or more other cryptographic keys.

According to some embodiments, the search query from the client includes versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys.

According to some embodiments, processing the search query comprises querying the searchable database based on each of the versions.

Additional embodiments relate to dynamically changing an encryption technique for encrypted data to be stored in a searchable database. For example, in some embodiments there may be a computer-implemented method for dynamically changing an encryption technique for encrypted data to be stored in a searchable database, the method comprising: receiving encrypted data for storage in the searchable database, the encrypted data having been encrypted by a client using a cryptographic key based on an encryption alteration scheme; receiving a search query from the client, the search query comprising a plurality of search strings including at least: an encrypted version of a plaintext string that was encrypted by the client using the cryptographic key, and one or more encrypted versions of the plaintext string that were encrypted by the client using one or more other cryptographic keys; processing the search query; and returning a response to the search query to the client.

According to some embodiments, different portions of the received encrypted data for storage in the searchable database have been encrypted using at least two of: the cryptographic key and the one or more other cryptographic keys.

According to some embodiments, the response returned to the client includes encrypted data stored in the searchable database matching at least a portion of the search query.

According to some embodiments, the client is configured to decrypt the response returned to the client using at least one of: the cryptographic key or the one or more other cryptographic keys.

Additional disclosed embodiments relate to dynamically changing an encryption technique for encrypted data to be stored in a searchable database. For example, in some embodiments there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for dynamically changing an encryption technique for encrypted data to be stored in a searchable database, the operations comprising: sending encrypted data for storage in the searchable database, the encrypted data having been encrypted by a client using a cryptographic key based on an encryption alteration scheme; formulating a search query, the search query comprising a plurality of search strings including at least: an encrypted version of a plaintext string that was encrypted by the client using the cryptographic key, and one or more encrypted versions of the plaintext string that were encrypted by the client using one or more other cryptographic keys; sending the search query to the searchable database; and receiving a response to the search query from the searchable database.

According to some embodiments, the search query includes versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys.

According to some embodiments, the searchable database is configured to perform a query based on each of the versions.

According to some embodiments, different portions of the encrypted data sent to the searchable database have been encrypted using at least two of: the cryptographic key and the one or more other cryptographic keys.

According to some embodiments, the client is configured to decrypt the response to the search query using at least one of: the cryptographic key or the one or more other cryptographic keys.

According to additional disclosed embodiments, techniques are described for performing secure and flexible searches of encrypted data. For example, according to some embodiments, there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for performing secure and flexible searches of encrypted data. The operations may comprise maintaining a database of a plurality of sets of encrypted data; receiving a transformed search query for the database, the transformed search query having undergone a transformation process at a client including: identifying a plaintext string in a search query at the client, applying the plaintext string to a language dictionary accessible to the client, receiving, based on the language dictionary, one or more plaintext search strings, and encrypting, at the client, the one or more plaintext search strings; and returning a result based on the transformed search query, the result being based on the encrypted one or more plaintext search strings.

According to some embodiments, the plaintext string applied to the client-side language dictionary is a search prefix.

According to some embodiments, the applying of the plaintext string to the client-side language dictionary is a similarity-based search.

According to some embodiments, the receiving includes receiving a plurality of plaintext search strings and the encrypting includes encrypting each of the plurality of plaintext search strings.

According to some embodiments, the language dictionary is at least one of: a definitional dictionary, a synonym dictionary, or a database schema dictionary.

According to some embodiments, the receiving includes receiving a plurality of plaintext search strings based on the plaintext string in the search query.

According to some embodiments, the plurality of plaintext search strings is presented to a user as selectable recommendations.

Additional disclosed embodiments relate to performing secure and flexible searches of encrypted data. For example, according to some embodiments there may be a computer-implemented method for performing secure and flexible searches of encrypted data. The method may comprise maintaining a database of a plurality of sets of encrypted data; receiving a transformed search query for the database, the transformed search query having undergone a transformation process at a client including: identifying a plaintext string in a search query at the client, applying the plaintext string to a language dictionary accessible to the client, receiving, based on the language dictionary, one or more plaintext search strings, and encrypting, at the client, the one or more plaintext search strings; and returning a result based on the transformed search query, the result being based on the encrypted one or more plaintext search strings.

According to some embodiments, the encrypting includes individually encrypting each of the one or more plaintext search strings.

According to some embodiments, the method further comprises concatenating database schema information together with at least one of the plaintext search strings.

According to some embodiments, the method further comprises returning a plurality of results based on the transformed search query.

Additional disclosed embodiments relate to performing secure and flexible searches of encrypted data. For example, according to some disclosed embodiments there may be a non-transitory computer readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform operations for performing secure and flexible searches of encrypted data. The operations may comprise sending encrypted data from a client to a database for storage at the database; formulating a transformed search query for the database, the formulating including: identifying a plaintext string in a search query, applying the plaintext string to a language dictionary accessible to the client, receiving, based on the language dictionary, one or more plaintext search strings, and encrypting, at the client, the one or more plaintext search strings; sending the transformed search query to the database for querying; and receiving a result based on the transformed search query.

According to some embodiments, the operations further comprise receiving a plurality of plaintext search strings based on the language dictionary.

According to some embodiments, the operations further comprise encrypting each of the plurality of plaintext search strings.

According to some embodiments, the transformed search query includes each of the encrypted plurality of plaintext search strings.

According to some embodiments, the operations further comprise receiving a plurality of results from the database based on the encrypted plurality of plaintext search strings.

According to some embodiments, the operations further comprise concatenating database schema information together with at least one of the plaintext search strings.

According to some embodiments, the operations further comprise encrypting the concatenated database schema information and the at least one of the plaintext search strings.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and, together with the description, serve to explain the disclosed embodiments. In the drawings:.

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosed example embodiments. However, it will be understood by those skilled in the art that the principles of the example embodiments may be practiced without every specific detail. Well-known methods, procedures, and components have not been described in detail so as not to obscure the principles of the example embodiments. Unless explicitly stated, the example methods and processes described herein are not constrained to a particular order or sequence, or constrained to a particular system configuration. Additionally, some of the described embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings.

<FIG> is a block diagram of an example system <NUM> in accordance with disclosed embodiments. As shown, system <NUM> includes a network storage resource <NUM>, e.g., a cloud-based data storage service, configured to provide data storage solutions for one or more clients <NUM>-<NUM>. For example, network storage resource <NUM> may operate as a storage-as-a-service (SaaS) environment (e.g., AWS Cloud Drive™, Box™, Carbonite™ Microsoft OneDrive™, etc.), a web server environment, a database server environment, or others. In some embodiments, each client <NUM>-<NUM> may communicate with network storage resource <NUM> through one or more computing devices, each of which may host one or more client applications that use network storage resource <NUM> for data storage. Each computing device may be in communication with network storage resource <NUM> via one or more communication channels <NUM>. A communication channel <NUM> may include a bus, a cable, a wireless communication channel, a radio-based communication channel, the Internet, a local area network (LAN), a wireless local area network (WLAN), a wide area network (WAN), a cellular communication network, or any Internet Protocol (IP), Secure Shell (SSH), HyperText Transfer Protocol (HTTP), or Representational State Transfer (REST) based communication network and the like. In some embodiments, communication channel <NUM> may be based on public cloud infrastructure, private cloud infrastructure, hybrid public/private cloud infrastructure, or no cloud infrastructure. In such differing embodiments, network storage resource <NUM> and clients <NUM>-<NUM> may each be in the same, or in different, networks or network segments. In some embodiments, clients <NUM>-<NUM> may be equipped with one or more compatible communication interfaces configured to support communications with network storage resource <NUM> via communication channels <NUM>. The communication interfaces are not shown in <FIG> for illustrative simplicity.

In some embodiments, network storage resource <NUM> may provide one or more application programming interfaces (APIs) <NUM> to support communications between network storage resource <NUM> and clients <NUM>-<NUM>. In some embodiments, API <NUM> may provide clients <NUM>-<NUM> with access to various types of services <NUM> or applications <NUM> provided by network storage resource <NUM>. In some embodiments, API <NUM> may also provide clients <NUM>-<NUM> with access to one or more databases <NUM> of network storage resource <NUM>.

In some embodiments, network storage resource <NUM> may be configured to support client-side encryption. For example, network storage resource <NUM> may allow a client, e.g., client <NUM>, to encrypt its data using a cryptographic key before sending the encrypted data to network storage resource <NUM>. Clients <NUM>-<NUM> may want to do this when sending sensitive or private data to network storage resource <NUM> (e.g., personal data, medical data, financial data, business data, etc.). In such embodiments, network storage resource <NUM> may store the encrypted data received from client <NUM> in database <NUM>, but network storage resource <NUM> may not have the ability to decrypt the stored data. In particular, network storage resource <NUM> may lack a cryptographic key the same as, or corresponding to, the client <NUM>'s cryptographic key used to encrypt the data. In this manner, network storage resource <NUM> may allow client <NUM> to handle data encryption and decryption on the client-side, which may reduce risks of data leakage from network storage resource <NUM>, mitigate eavesdropping, and improve data security and integrity. Similarly, even if an attacker is able to compromise network storage resource <NUM>, the attacker will not thereby gain access to the client <NUM>'s stored data in plaintext.

Client <NUM> may utilize various types of processes to encrypt and decrypt its data. For example, client <NUM> may configure a computer program referred to as a database driver (not shown in <FIG>) to implement both a protocol for database connection and to handle data encryption and decryption for client <NUM>. In another example, client <NUM> may send data to a proxy (not shown in <FIG>), which may act as an intermediary for handling data encryption and decryption for client <NUM>. In still another example, client <NUM> may deploy and manage a microservice <NUM> on the client-side to manage all required encryption and decryption services. The encryption by client <NUM> may be performed according to various techniques, such as asymmetric or symmetric encryption. Examples of asymmetric encryption techniques include RSA™, Diffie-Hellman, DSS, YAK, and various others. Examples of symmetric encryption techniques include AES, Blowfish, Twofish, DES, 3DES, and various others.

In some embodiments, client <NUM> may implement microservice <NUM> as an independently deployable service deployed for the discrete purpose of providing the required encryption and decryption services to client <NUM>. For example, client <NUM> may deploy and manage microservice <NUM> on the same computing device that hosts the client application that uses network storage resource <NUM> for data storage. In this manner, client <NUM> may retain full control over microservice <NUM> and may allow the computing device to continue using its original communication channel <NUM> to communicate with network storage resource <NUM>.

It is contemplated that using microservice <NUM> in this manner can enhance data security compared to using an intermediary service such as a proxy because the proxy may gain knowledge of the data types being communicated and may potentially be misused by malicious parties to impersonate client <NUM> and conduct attacks. Using microservice <NUM> in this manner also provides client <NUM> complete control over data that may go through encryption services, the control of which is lacking when using a proxy. For example, in a solution where not all data must be encrypted, client <NUM> may wish to only encrypt data that is sensitive and leave the rest unencrypted. If microservice <NUM> is used, client <NUM> may decide to not send certain data to microservice <NUM> for encryption. On the other hand, if a proxy is used, client <NUM> may be required to send all data through the proxy and the proxy has the knowledge of what to encrypt and what not to encrypt. Therefore, using microservice <NUM> may be more advantageous compared to using a proxy in such solutions because microservice <NUM> allows client <NUM> to send data that does not need to be encrypted directly to network storage resource <NUM>, thereby improving performance. Furthermore, microservice <NUM> allows each client to keep and maintain control over their data and the abilities to make decisions on treatment of their own data, which may be appreciated by various clients for various reasons.

Furthermore, microservice <NUM> may be more robust compared to database drivers. Specifically, because microservice <NUM> can be deployed and managed by client <NUM>, who also has knowledge of the client application that uses network storage resource <NUM> for data storage, client <NUM> can deploy microservice <NUM> in a manner that further enhances data integrity (e.g., to enhance the integrity of an entire row, or several joined rows, in a relational database). Client <NUM> can also deploy microservice <NUM> to use blind-indexing to build indices that are more robust against information leakage, including, e.g., concatenating tables, fields, and value names to form hashed indices that are more difficult for attackers to decipher and allow more precise searching.

Alternatively, as depicted in <FIG>, if one or more clients, e.g., clients <NUM>-<NUM>, belong to the same organization or user group, the organization may deploy and manage microservice <NUM> on a computing device or a hardware security module (HSM) <NUM> and make microservice <NUM> accessible to clients <NUM>-<NUM>. The organization may also exclude computing devices outside of the organization from accessing microservice <NUM>. In this manner, clients <NUM>-<NUM> may utilize the encryption services provided by microservice <NUM> as described above, and clients <NUM>-<NUM> may still retain control over microservice <NUM> through the organization. Therefore, microservice <NUM> deployed in this manner may continue to allow clients <NUM>-<NUM> to use their original communication channels <NUM> to communicate with network storage resource <NUM>, and may also provide benefits such as enhanced data security and robustness in the same manner described above.

Furthermore, in some embodiments, microservice <NUM> may be deployed to operate in a stateless manner. In contrast to a stateful application (e.g., using HTTP cookies, Java™ cookies, etc.), which refers to an application that saves client data from the activities of one session for use in the next session, a stateless microservice does not save client data generated in one session for use in the next. In other words, microservice <NUM> may be deployed to operate for the discrete purpose of encrypting or decrypting data provided to microservice <NUM> without the need to save any client data (e.g., in cookies) to facilitate its execution. Therefore, such a stateless microservice <NUM> can be deployed in a scalable setup, which can be better equipped to handle load increases. Moreover, in some embodiments, microservice <NUM> may be deployed on the client-side on one or more computing devices as a part of a virtualized environment scaling process (e.g., replicating instances of a virtualized machine or application).

<FIG> illustrates a block diagram of a computing device <NUM>, which can be utilized to host one or more client applications or one or more microservices, in accordance with disclosed embodiments. Referring to <FIG>, the computing device <NUM> may include a communication interface <NUM>, a processor <NUM>, and a memory <NUM>, among potentially various other components.

The communication interface <NUM> may facilitate communications between computing device <NUM> and other computing devices or resources, including, e.g., network storage resource <NUM> (shown in <FIG>). In some embodiments, communication interface <NUM> may be configured to support one or more communication standards, such as an Internet standard or protocol, an Integrated Services Digital Network (ISDN) standard, and the like. In some embodiments, communication interface <NUM> may include one or more of a LAN card, a cable modem, a satellite modem, a data bus, a cable, a wireless communication channel, a radio-based communication channel, a cellular communication channel, an Internet Protocol, a SSH, a HTTP, or a REST based communication device, or other communication devices for wired and/or wireless communications. In some embodiments, communication interface <NUM> may be based on public cloud infrastructure, private cloud infrastructure, or hybrid public/private cloud infrastructure.

Processor <NUM> may include one or more dedicated processing units, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or various other types of processors or processing units. Processor <NUM> may be coupled with memory <NUM> and configured to execute instructions stored in memory <NUM>.

Memory <NUM> may store processor-executable instructions and data. Memory <NUM> may include any type of volatile or non-volatile memory devices, or a combination thereof, such as a static random-access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, or a magnetic or optical disk. When the instructions in memory <NUM> are executed by processor <NUM>, computing device <NUM> may perform operations for implementing an encryption service that can be used to facilitate data storage and data searches. The encryption service may be implemented in a database driver, a proxy, or a microservice.

Continuing with the example above, where network storage resource <NUM> is configured to support client-side encryption and may therefore allow a client, e.g., client <NUM>, to encrypt its data before sending the encrypted data to network storage resource <NUM> for storage. If client <NUM> wants to store data, e.g., customer data {id:"<NUM>"; name:"Jon"; country:"United States"} on network storage resource <NUM>, client <NUM> may utilize the encryption service (e.g., part of microservice <NUM>) to encrypt the data based on a cryptographic key accessible to client <NUM> to produce encrypted data {id:U4sOetRzC-M2F6DxqQ; name:nPIQ5mSGYzppywqSx; country:P0r-cOwTu6szXokZHW} and send the encrypted data to network storage resource <NUM> for storage. Network storage resource <NUM>, upon receiving the encrypted data, may store the encrypted data in database <NUM>. In some embodiments, only the raw encrypted data may be stored. In further embodiments, the encrypted data may be stored in associated with an identifier of the client <NUM> (e.g., a user identifier, application identifier, account name, IP address, MAC address, etc.). Further, in some embodiments the encrypted data may be stored according to the types of encrypted data being stored (e.g., in the above example, "id," "name," and "country"). In this manner, while the actual data contents may be encrypted, the type or category of data may be known to the network storage resource <NUM> to facilitate more particularized searching later by client <NUM>.

If client <NUM> later wishes to use network storage resource <NUM> to search for customers who are located in the United States, for example, client <NUM> may define a search query in plaintext (e.g., SELECT * FROM customer WHERE country = "United States") and utilize the encryption service (e.g., of microservice <NUM>) to encrypt the search query based on the same cryptographic key. In this manner, the encryption service can generate an encrypted search query to search for customers whose country matches the encrypted value of "United States," which corresponds to "P0r-cOwTu6szXokZHW" in the above example. Client <NUM> may then send the encrypted search query (e.g., SELECT * FROM customer WHERE country = "P0r-cOwTu6szXokZHW") to network storage resource <NUM> and expect to receive a response from network storage resource <NUM> containing encrypted data representing customers whose country matches "P0r-cOwTu6szXokZHW. " In this manner, network storage resource <NUM> can successfully process search queries submitted by client <NUM> without needing to decrypt the encrypted data, access the client's data in plaintext, or otherwise compromise the integrity of client-side encryption. Upon receiving the response, client <NUM> may decrypt the encrypted data contained in the response on the client-side to obtain the data in plaintext.

It is to be understood that the data and the search query described above are merely exemplary and are not meant to be limiting. It is contemplated that client <NUM> may store various types of data in network storage resource <NUM>, and in some embodiments, client <NUM> may store the various types of data in one or more database tables as one or more database elements. In some embodiments, if the data to be stored contains multiple database elements or is a concatenation of multiple database elements, the encryption service may be configured to separately encrypt the database elements based on the cryptographic key. Alternatively, the encryption service may be configured to encrypt multiple database elements based on the cryptographic key as a group.

Client <NUM> may continue to have control over its data stored in network storage resource <NUM>. For example, client <NUM> may control the insertion, modification, and removal of its data stored in network storage resource <NUM>. Client <NUM> may also control whether other users have permission to query its data. In some embodiments, client <NUM> may have exclusive control over its data, including destruction of its data. Client <NUM> may destroy its data by permanently removing it from network storage resource <NUM>. Client <NUM> may also destroy its data by modifying it so that it cannot be decrypted or is no longer meaningful.

Referring now to <FIG>, an exemplary flowchart showing a process <NUM> for implementing a searchable-encryption service is shown. In accordance with above embodiments, process <NUM> may be implemented in system <NUM> depicted in <FIG>. For example, process <NUM> may be performed by a microservice, e.g., microservice <NUM>, at a client, e.g., client <NUM>.

At step <NUM>, process <NUM> executes the microservice to encrypt data based on a cryptographic key accessible to the client. As discussed above, the client's cryptographic key may be an asymmetric key or a symmetric key, for example. As a further example, the cryptographic key may in some embodiments be generated based on biometric (e.g., fingerprint) or biological (e.g., hair follicle) data of a user of client <NUM>. At step <NUM>, process <NUM> executes the microservice to send the encrypted data to a network storage resource, e.g., network storage resource <NUM>, for storage. As discussed above, in some embodiments all of the data transmitted to network storage resource <NUM> is encrypted. Alternatively, in some embodiments at least some data (e.g., data classifications, types, categories, field names, etc.) may be kept in plaintext as transmitted to network storage resource <NUM>, to enable more efficient and precise searching at network storage resource <NUM>. At step <NUM>, process <NUM> executes the microservice to identify, at the microservice, a search query in plaintext. The search query may be provided by the client (e.g., by a user) to search for data stored in the network storage resource <NUM>. In some embodiments the search may be a simple plaintext search string. Alternatively, the search may include parameters for enabling more efficient and precise searching as well (e.g., data classifications, types, categories, field names, etc.). At step <NUM>, process <NUM> may execute the microservice to encrypt the search query according to the cryptographic key. As discussed above, in some embodiments all of the search query may be encrypted. Alternatively, in some embodiments, certain fields (e.g., data classifications, types, categories, field names, etc.) may remain in plaintext while the search content itself may be encrypted. At step <NUM>, process <NUM> executes the microservice to send the encrypted search query to the network storage resource <NUM>. Consistent with above embodiments, the encrypted search query may be transmitted over communications path <NUM> (e.g., from microservice <NUM> itself, or from a client <NUM>-<NUM> itself). The network storage resource <NUM> may query stored encrypted data it maintains (e.g., in database <NUM>) based on the encrypted search query. As discussed above, if certain fields (e.g., data classifications, types, categories, field names, etc.) are unencrypted in the search query, they may be used to facilitate the search at database <NUM> and make the search more precise and efficient. At step <NUM>, process <NUM> may execute the microservice to receive a response to the encrypted search query from the network storage resource <NUM>. For example, the network storage resource <NUM> may return the encrypted data it stores that matches the client <NUM>'s search query.

In some embodiments, the network storage resource <NUM> is configured to have no access to the cryptographic key used by the client <NUM>. In this manner, the network storage resource <NUM> can process encrypted search queries without compromising the integrity of client-side encryption. In some embodiments, the client <NUM> may create its own cryptographic key, according to the techniques noted above (e.g., asymmetric, symmetric, biometric, biological, etc.), which may be used by the microservice <NUM> to encrypt data and search queries provided by the client <NUM>. Alternatively, in some embodiments, the client <NUM> may obtain its cryptographic key from one or more external key resources. Furthermore, in some embodiments, different clients <NUM>-<NUM> may use different cryptographic keys. However, if one or more clients <NUM>-<NUM> belong to the same organization or user group, the organization may create or obtain a cryptographic key, which may be shared by one or more clients <NUM>-<NUM>.

In some embodiments, once a client <NUM> creates or obtains its cryptographic key (which may be obtained, e.g., from an external key resource or from an organization the client belongs to), that client <NUM> may use the same cryptographic key to encrypt all of its data and search queries. Using the same cryptographic key in this manner ensures that a given plaintext value will always encrypt to the same encrypted value, making the encryption deterministic, which in turn reduces the complexity of the searchable-encryption service described above.

There are, however, some potential shortcomings associated with basic deterministic encryption. One shortcoming is the possibility that a malicious party may be able to observe the behaviors of the deterministic encryption occurring in the database (e.g., database <NUM>), or on the communication channel (e.g., channel <NUM>), which may allow the malicious party to deduce knowledge on the client <NUM>'s business. For example, if the malicious party knows that a client <NUM> usually stays late at work, and if the malicious party has access to view the database <NUM>, the malicious party may watch the database <NUM> at late hours and deduce that the changing database rows relate to activities associated with the client <NUM>. This potential shortcoming can be mitigated utilizing one or more processes described below.

Referring now to <FIG>, these figures are illustrations depicting a process for dynamically changing an encryption technique for encrypted data to be stored in a searchable database, e.g., database <NUM> (shown in <FIG>), in accordance with disclosed embodiments. As shown in <FIG>, a client <NUM> (e.g., similar to any of clients <NUM>-<NUM>) may create or obtain a set of cryptographic keys <NUM> that can be used to encrypt data and search queries. As discussed above, the cryptographic keys in the set <NUM> may be generated according to various cryptographic techniques (e.g., asymmetric keys, symmetric keys, biometric-based keys, biological-based keys, etc.). If client <NUM> wants to store data, e.g., customer data {id:"<NUM>"; name:"Jon"; country:"United States"} on the network storage resource <NUM>, client <NUM> may select a key, e.g., Key <NUM>, from the set of cryptographic keys <NUM>, utilize Key <NUM> to encrypt some or all of the data, and send the encrypted data to network storage resource <NUM> for storage. As discussed above, either all of the data may be encrypted using Key <NUM>, or only portions thereof (e.g., encrypting the data contents but not certain field names, categories, classifications, types, headers, etc.). In some embodiments, client <NUM> may randomly select a key from among the set of cryptographic keys <NUM>.

As shown in <FIG>, if client <NUM> later wishes to use network storage resource <NUM> to search for customers who are located in the United States, for example, client <NUM> may define a search query in plaintext (e.g., SELECT * FROM customer WHERE country = "United States") and utilize the encryption service to encrypt the search query using all keys contained in the set of cryptographic keys <NUM>. In this manner, the encryption service can generate a corresponding encrypted search query based on each key contained in the set of cryptographic keys <NUM>. Client <NUM> may then send all such encrypted search queries to network storage resource <NUM> for processing. Of note is that only one of such encrypted search queries (i.e., the search query encrypted using the same key used to encrypt the data, or Key <NUM> in the example above) will produce matching results. In this manner, network storage resource <NUM> can successfully process search queries submitted by client <NUM> and provide a response to the client <NUM>. The response may include encrypted data stored in network storage resource <NUM> that matches at least a portion of the encrypted search query. Upon receiving the response, client <NUM> may decrypt the encrypted data contained in the response on client-side using the keys contained in the set of cryptographic keys <NUM> to obtain the data in plaintext.

It is contemplated that the process described above may be utilized to handle not only insertion of new data, but also updates, removals, as well as other types of data processes. It is also contemplated that the process may be executed independently each time a data request is received. Continuing with the example above, if client <NUM> wants to store data, e.g., customer data {id:"<NUM>"; name:"Jon"; country:"United States"} on network storage resource <NUM>, client <NUM> may randomly select a first key, e.g., Key <NUM>, from the set of cryptographic keys <NUM>, to encrypt the data for insertion. If client <NUM> later wishes to update the data associated with "Jon" to indicate that "Jon" has moved to "Canada," client <NUM> may submit an update request (e.g., UPDATE customer SET country = "Canada" WHERE name = "Jon"), which may be encrypted using a second key randomly selected from the set of cryptographic keys <NUM>. The first and second keys may or may not be the same.

It is noted that the purpose of changing the encryption technique for encrypted data is to mitigate the risks associated with deterministic encryption, which include the possibility that a malicious party may be able to observe the behaviors of the deterministic encryption occurring in the database or a communications channel between the client and the database. By changing the encryption techniques used to encrypt data, it may become more difficult for the malicious party to observe behaviors that can be used to carry out attacks, therefore further improving data security. Moreover, in some embodiments, keys contained in the set of cryptographic keys <NUM> may be subject to random rotations at random times, making it even more difficult or impossible for malicious parties to observe any behaviors that can be used to carry out attacks.

Furthermore, in some embodiments, client <NUM> may randomly select multiple keys from the set of cryptographic keys <NUM> to encrypt multiple portions of the data. For example, if client <NUM> wants to store data, e.g., customer data {id:"<NUM>"; name:"Jon"; country:"United States"} on network storage resource <NUM>, client <NUM> may randomly select a first key from the set of cryptographic keys <NUM> to encrypt "<NUM>. " Client <NUM> may also randomly select a second key from the set of cryptographic keys <NUM> to encrypt "Jon. " Client <NUM> may further randomly select a third key from the set of cryptographic keys <NUM> to encrypt "United States. " The first, second, and third keys may or may not be the same, according to their random selection.

It is to be understood that the processes for changing the encryption technique for encrypted data described above are merely exemplary and are not meant to be limiting. It is contemplated that other processes may be utilized to facilitate changing of encryption techniques for encrypted data without departing from the scope of the present disclosure. For instance, <FIG> is an illustration depicting another process for dynamically changing the encryption technique for encrypted data. As shown in <FIG>, multiple users <NUM>-<NUM> may belong to the same organization or user group <NUM>. In such a case, organization <NUM> may create or obtain a set of cryptographic keys <NUM> at the organization level, eliminating the need for each user <NUM>-<NUM> to independently spend resources to create, obtain, and maintain separate sets of cryptographic keys. Organization <NUM> may allow users <NUM>-<NUM> to use the keys contained in the set of cryptographic keys <NUM>. Alternatively, organization <NUM> may allocate different subsets of cryptographic keys to different users <NUM>-<NUM>, enabling each user <NUM>-<NUM> to use their corresponding subset of cryptographic keys in manners similar to that described above.

Referring now to <FIG>, an exemplary flowchart showing a process <NUM> for dynamically changing an encryption technique for encrypted data to be stored in a searchable database is shown. In accordance with above embodiments, process <NUM> may be implemented in system <NUM> depicted in <FIG>. For example, process <NUM> may be performed by network storage resource <NUM> or a searchable database, e.g., database <NUM>, of network storage resource <NUM>.

At step <NUM>, process <NUM> may receive encrypted data for storage in the searchable database. The encrypted data may have been encrypted by a client <NUM> using a cryptographic key based on an encryption alteration scheme. In some embodiments, the encryption alteration scheme may include selecting the cryptographic key from among a set of cryptographic keys (e.g., the set of cryptographic keys <NUM> shown in <FIG> or the set of cryptographic keys <NUM> shown in <FIG>). The set of cryptographic keys may include one or more other cryptographic keys, and in some embodiments, the cryptographic key may be chosen randomly among the set of cryptographic keys.

At step <NUM>, process <NUM> may receive a search query from the client. The search query may include one or multiple search strings, and in some embodiments, the search strings may include an encrypted version of a plaintext string that was encrypted by the client <NUM> using the cryptographic key and one or more encrypted versions of the plaintext string that were encrypted by the client <NUM> using one or more other cryptographic keys. Furthermore, in some embodiments, the plaintext string may be encrypted with each of the cryptographic key and the one or more other cryptographic keys. In such embodiments, the search query from the client <NUM> may include versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys. Further, as discussed above, in some embodiments a portion of the search query (e.g., a field, category, classification, header, type, etc.) may be received at the network storage resource <NUM> in plaintext while the actual search contents itself may be encrypted.

At step <NUM>, process <NUM> may process the search query. In some embodiments, processing the search query may include querying the searchable database <NUM> based on each of the versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys. At step <NUM>, process <NUM> may return a response to the search query to the client <NUM>. Upon receiving the response, the client <NUM> may decrypt the encrypted data contained in the response on client-side using one of the keys contained in the set of cryptographic keys to obtain the data in plaintext.

Referring now to <FIG>, an exemplary flowchart showing a process <NUM> for dynamically changing an encryption technique for encrypted data to be stored in a searchable database is shown. In accordance with above embodiments, process <NUM> may be implemented in system <NUM> depicted in <FIG>. For example, process <NUM> may be performed by a computing device utilized by a client, e.g., client <NUM>. Alternatively, process <NUM> may be performed separate from a client, such as at a proxy server intermediate between the client <NUM> and the network storage resource <NUM>.

At step <NUM>, process <NUM> may send encrypted data for storage in a searchable database <NUM> of a network storage resource <NUM>. The encrypted data may have been encrypted by the client <NUM> using a cryptographic key based on an encryption alteration scheme, as discussed above. In some embodiments, the encryption alteration scheme may include selecting the cryptographic key from among a set of cryptographic keys (e.g., the set of cryptographic keys <NUM> shown in <FIG> or the set of cryptographic keys <NUM> shown in <FIG>). The set of cryptographic keys may include one or more other cryptographic keys, and in some embodiments, the cryptographic key may be chosen randomly among the set of cryptographic keys. Furthermore, in some embodiments, different portions of the encrypted data may be encrypted using different keys contained in the set of cryptographic keys.

At step <NUM>, process <NUM> may formulate a search query. The search query may include multiple search strings, and in some embodiments, the search strings may include an encrypted version of a plaintext string that was encrypted by the client <NUM> using the cryptographic key and one or more encrypted versions of the plaintext string that were encrypted by the client <NUM> using one or more other cryptographic keys. Furthermore, in some embodiments, the plaintext string may be encrypted with each of the cryptographic key and the one or more other cryptographic keys. In such embodiments, the search query from the client <NUM> may include versions of the plaintext string encrypted with each of the cryptographic key and the one or more other cryptographic keys.

At step <NUM>, process <NUM> may send the search query to the searchable database <NUM>. The searchable database <NUM> may process the search query by comparing the search query to contents of the database <NUM>. If any plaintext fields, categories, classifications, or types are present in the search query, those may be used to facilitate the search at database <NUM>. At step <NUM>, process <NUM> may receive a response to the search query from the searchable database <NUM>. Upon receiving the response, the client <NUM> may decrypt the encrypted data contained in the response on client-side using one of the keys contained in the set of cryptographic keys to obtain the data in plaintext.

It is contemplated that there may be situations where a client <NUM> may wish to use the searchable database <NUM> to search for data records that do not match the search query exactly. For example, a client <NUM> may wish to use the searchable database <NUM> to search for customers with names that start with "Jon," including, e.g., Jon, Jonna, Jones, Jonathan, etc. This may be achieved using wild characters or regular expressions in the search query, which may be defined as, e.g., SELECT * FROM customer WHERE name = "Jon*", where "*" is a wild character representing zero or more characters. However, because this search query must go through an encryption process as described above in order to be processed, the encryption process will create an encrypted search query that is only capable of locating encrypted data records that have the encrypted values in the "name" field that match the encrypted value of "Jon*". In other words, this encrypted search query may not be able to retrieve the records with names such as Jon, Jonna, Jones, or Jonathan. This limitation can be addressed using one or more processes described below.

<FIG> is an illustration depicting a process for performing secure and flexible searches of encrypted data in accordance with disclosed embodiments. As shown in <FIG>, a client <NUM> may first define a search query. In some embodiments, the search query may be defined in plain text, e.g., SELECT * FROM customer WHERE name = "Jon*". Client <NUM> may then transform the search query, and in some embodiments, client <NUM> may apply the search query to a language dictionary <NUM> accessible to client <NUM>. Dictionary <NUM> may provide client <NUM> with a list of alternative search terms, e.g., names that start with "Jon," including, e.g., Jon, Jonna, Jones, Jonathan, etc., and help client <NUM> to generate one or more plaintext search strings, including, e.g., SELECT * FROM customer WHERE name = "Jon", SELECT * FROM customer WHERE name = "Jonna", SELECT * FROM customer WHERE name = "Jones", SELECT * FROM customer WHERE name = "Jonathan", etc. Client <NUM> may then encrypt each plaintext search string in manners described above and send the encrypted search strings to a searchable database <NUM> for processing.

Searchable database <NUM> may be implemented as database <NUM> of network storage resource <NUM> shown in <FIG>. Searchable database <NUM> may process each encrypted search string in manners described above and provide a response to client <NUM> containing encrypted data records with names matching the encrypted values of "Jon," "Jonna," "Jones," "Jonathan," etc. Upon receiving the response, client <NUM> may decrypt the encrypted data records contained in the response on the client-side to obtain the data in plaintext.

It is to be understood that the support for wild characters and regular expressions described above are merely exemplary and are not meant to be limiting. It is contemplated that dictionary <NUM> may be configured to support other types of flexible searches without departing from the scope of the present disclosure. For example, in some embodiments, dictionary <NUM> may provide client <NUM> with alternative search terms based on their likeliness to the search term client <NUM> defined in the original search query (e.g., based on spelling or phonetic similarities). In another example, dictionary <NUM> may provide client <NUM> with alternative search terms based on the meaning (e.g., synonyms) of the search term client <NUM> defined in the original search query.

In some embodiments, client <NUM> may provide training data to dictionary <NUM> to help dictionary <NUM> build and expand a library of alternative search terms. Such training data may include, e.g., a client profile, a client website, as well as other documents or data records that may help dictionary <NUM> build and expand its library. In some embodiments, dictionary <NUM> may include one or more definitional dictionaries, synonym dictionaries, product listings or inventories, or database schema dictionaries to help build and expand the library of alternative search terms. Dictionary <NUM> may also be configured to utilize various types of machine learning techniques to learn from search queries provided by client <NUM>, including historic search queries. In this manner, dictionary <NUM> may tailor the library to serve specific needs of client <NUM>. In some embodiments, dictionary <NUM> may be configured to receive feedback from the client <NUM>, further improving the relatedness of the alternative search terms provided by dictionary <NUM> to the client <NUM>. Examples of dictionaries that may be used with the disclosed techniques include "wordfuzz," available on GitHub™, or "WordNet," available from Princeton University's website.

Referring now to <FIG>, an exemplary flowchart showing a process <NUM> for performing secure and flexible searches of encrypted data is shown. In accordance with above embodiments, process <NUM> may be implemented in system <NUM> depicted in <FIG>. For example, process <NUM> may be performed by network storage resource <NUM> or a searchable database, e.g., database <NUM>, of network storage resource <NUM>.

At step <NUM>, process <NUM> may maintain a database, e.g., database <NUM>, which may record multiple sets of encrypted data. At step <NUM>, process <NUM> may receive a transformed search query for the database <NUM>. The transformed search query may have undergone a transformation process at a client, e.g., client <NUM> shown in <FIG> or client <NUM> shown in <FIG>. Alternatively, as discussed above, the transformation process may occur separate from the client (e.g., at a proxy server between the client <NUM> and the network storage resource <NUM>). In some embodiments, the transformation process may identify a plaintext string in a search query at the client <NUM>. Continuing with the example above, the plaintext string in the search query may include, e.g., SELECT * FROM customer WHERE name = "Jon*". The client <NUM> may apply the plaintext string to a language dictionary accessible to the client (e.g., dictionary <NUM> as shown in <FIG>) and receive, based on the language dictionary, one or more plaintext search strings. In some embodiments, the plaintext search strings may be based on the plaintext string in the search query. Such plaintext search strings may include, e.g., SELECT * FROM customer WHERE name = "Jon", SELECT * FROM customer WHERE name = "Jonna", SELECT * FROM customer WHERE name = "Jones", SELECT * FROM customer WHERE name = "Jonathan", etc. The client <NUM> may encrypt each of these plaintext search strings and send the encrypted search strings as the transformed search query to the database <NUM> for processing. Alternatively, the plaintext search strings may be presented to the client <NUM> as selectable recommendations. In such embodiments, the client <NUM> may select and encrypt one or more plaintext search strings and send the one or more encrypted search strings as the transformed search query to the database <NUM> for processing. Furthermore, in some embodiments, the client <NUM> may concatenate certain database schema information together with one or more plaintext search strings and encrypt the concatenated database schema information and the plaintext search strings to formulate the transformed search query.

At step <NUM>, process <NUM> may return a result based on the transformed search query. In some embodiments, the result may be generated based on the encrypted one or more plaintext search strings. Continuing with the example above, process <NUM> may process each encrypted search string in manners described above and generate the result containing encrypted data records with names matching the encrypted values of "Jon," "Jonna," "Jones," "Jonathan," etc. Upon receiving the result, the client <NUM> may decrypt the encrypted data records on client-side to obtain the data in plaintext.

In some embodiments, the plaintext string applied to the language dictionary may include a search prefix. In some embodiments, the language dictionary may be configured to support other types of flexible searches. For example, in some embodiments, the language dictionary may apply a similarity-based search. In some embodiments, the language dictionary may include one or more definitional dictionaries, synonym dictionaries, or database schema dictionaries to help build and expand the library of alternative search terms.

Referring now to <FIG>, an exemplary flowchart showing a process <NUM> for performing secure and flexible searches of encrypted data is shown. In accordance with above embodiments, process <NUM> may be implemented in system <NUM> depicted in <FIG>. For example, process <NUM> may be performed by a computing device utilized by a client, e.g., client <NUM>. Alternatively, process <NUM> may be performed separate from a client, such as at a proxy server intermediate between the client <NUM> and the network storage resource <NUM>.

At step <NUM>, process <NUM> may send encrypted data from a client, e.g., client <NUM>, to a database, e.g., database <NUM>, for storage at the database. At step <NUM>, process <NUM> may formulate a transformed search query for the database. In some embodiments, process <NUM> may identify a plaintext string in a search query. Continuing with the example above, the plaintext string in the search query may include, e.g., SELECT * FROM customer WHERE name = "Jon*". The client <NUM> may apply the plaintext string to a language dictionary accessible to the client <NUM> (e.g., dictionary <NUM> as shown in <FIG>) and receive, based on the language dictionary, one or more plaintext search strings. In some embodiments, the plaintext search strings may be based on the plaintext string in the search query. Such plaintext search strings may include, e.g., SELECT * FROM customer WHERE name = "Jon", SELECT * FROM customer WHERE name = "Jonna", SELECT * FROM customer WHERE name = "Jones", SELECT * FROM customer WHERE name = "Jonathan", etc. The client <NUM> may encrypt each of these plaintext search strings and send the encrypted search strings as the transformed search query to the database <NUM> for processing. Alternatively, the plaintext search strings may be presented to the client <NUM> as selectable recommendations. In such embodiments, the client <NUM> may select and encrypt one or more plaintext search strings and send the one or more encrypted search strings as the transformed search query to the database <NUM> for processing. Furthermore, in some embodiments, the client <NUM> may concatenate certain database schema information together with one or more plaintext search strings and encrypt the concatenated database schema information and the plaintext search strings to formulate the transformed search query.

At step <NUM>, process <NUM> may send the transformed search query to the database <NUM> for querying. The database <NUM> may process the querying in manners described above. At step <NUM>, process <NUM> may receive a result based on the transformed search query. In some embodiments, process <NUM> may receive one or more results from the database <NUM> based on one or more encrypted plaintext search strings. Upon receiving one or more results, the client <NUM> may decrypt the one or more results on client-side to obtain the queried data in plaintext.

It is to be understood that the disclosed embodiments are not necessarily limited in their application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the examples. The disclosed embodiments are capable of variations, or of being practiced or carried out in various ways.

The disclosed embodiments may be implemented in a system, a method, and/or a computer program product.

Computer readable program instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

The descriptions of the various embodiments of the present disclosure have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is appreciated that certain features of the disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment of the disclosure.

Claim 1:
A computer-implemented method for dynamically changing an encryption technique for encrypted data to be stored in a searchable database (<NUM>), the method comprising:
executing a microservice at a client (<NUM>, <NUM>, <NUM>, <NUM>) to encrypt data using a cryptographic key based on an encryption alteration scheme,
sending (<NUM>), by the microservice, the encrypted data for storage in the searchable database, the encrypted data, , wherein the encryption alteration scheme comprises selecting the cryptographic key randomly from among a set of cryptographic keys (<NUM>) including one or more other cryptographic keys;
identifying, by the microservice, a search query provided at the client (<NUM>), the search query comprising a plurality of search strings including at least:
an encrypted version of a plaintext string that was encrypted by the client using the cryptographic key, and
one or more encrypted versions of the plaintext string that were encrypted by the client using one or more other cryptographic keys;
sending the search query to the searchable database; and
receiving (<NUM>) a response to the search query from the searchable database.