Restricted fully private conjunctive database query for protecting user privacy and identity

Abstract

A method for secure access by a client to a database having sensitive data (e.g., clinical information of patients) in a privacy-preserving manner includes: communicating with a server to obtain labels for particular attribute-value pairs when the client is authorized to make queries; imposing a label quota on each client and limiting label generation to authorized query items with a valid digital signature from a third-party authority; secret storing the labels and their associated query items for future queries; sending a combination of labels defining items in a conjunctive query to an agent over a secure channel; receiving encrypted coefficients of a polynomial from the agent, roots of the polynomial being indices to query results; decrypting the encrypted coefficients with a first protocol with the server; computing the roots of the polynomial based on the decrypted coefficients and discarding any extraneous roots; obtaining encrypted records associated with the computed roots from the agent; and decrypting the encrypted records with a second protocol with the server.

Description

Technical Field

[0001] The various exemplary embodiments disclosed herein relate to restricted, fully private concatenation database queries for protecting user privacy and identity. Background Technology

[0002] Genetic knowledge repositories (including structured, multi-institutional patient records and databases of associated genomic aberrations) can serve as a rich resource for research and clinical decision support by linking patient phenotypes and clinical outcomes to their underlying genotypes. In the case of rare diseases, input queries that input patient characteristics and genotypes into a sufficiently large repository can aid in diagnosis. If approved therapies cannot be identified, patients can be easily informed of existing clinical trials. When no clinical trials are available, clinicians can engage with pharmaceutical companies on new research projects.

[0003] The Lighthouse Project from the Global Alliance for Genomics and Health (GA4GH) is an open standard for genomics data discovery. Initially designed as a conjoint database, it aims to answer questions such as, “Do you have information about allele 'A' at position 938294 on chromosome 9?” This feature is useful for clinicians searching for second cases that can inform treatment decisions for their patients. Recently, the Lighthouse Project announced additional features, including tiered metadata access levels—public, registry, and controlled—where the highest access level allows not only viewing the presence of alleles in the database but also viewing metadata that informs the exact nucleotide changes, reference genome version, and associated annotations (e.g., pathogenicity). While this model is useful on its own, it does not allow users to query based on genotype combinations and / or metadata, nor does it allow data outside this scope (e.g., sets of patient phenotypes). This is partly due to the numerous privacy challenges that frameworks with this quality face. Summary of the Invention

[0004] The following provides an overview of various exemplary embodiments. Some simplifications and omissions may be made in this overview, which are intended to highlight and introduce some aspects of the various exemplary embodiments, and not to limit the scope of the invention. Detailed descriptions of the exemplary embodiments will be described in later sections, which are sufficient to enable those skilled in the art to acquire and use the inventive concept.

[0005] Various embodiments relate to a method for securely accessing a patient database by a client, comprising: communicating with a server to transform attribute value pairs into tags; obtaining tags associated with the attribute value pairs on a secure communication channel; sending a combination of tags for items in a generated conjunctive query to an agent on the secure communication channel; receiving encrypted coefficients of a polynomial from the agent, the roots of the polynomial being indexes of records satisfying the query items; decrypting the encrypted coefficients with a first protocol with the server; calculating the roots of the polynomial based on the decrypted coefficients and discarding any redundant roots; obtaining an encrypted record associated with the calculated root; and decrypting the encrypted record with a second protocol with the server.

[0006] Various embodiments are described, wherein the label is a hash value generated by transforming the attribute value pair through collaboration between the client and the server using a method that evaluates the attribute value using an unintentional pseudo-random function that includes authorization.

[0007] Various embodiments are described in which the tag is generated only if one or more of the following criteria are met: (i) the total number of tags issued to the client is within a predefined limit of access permissions specified in the client's public key certificate, and (ii) each query item in the query item has a valid digital signature from a third-party authority.

[0008] Various embodiments are described, wherein decrypting the encryption coefficients with a first protocol with the server includes unintentional decryption.

[0009] Various embodiments are described, wherein decrypting the encrypted record with a second protocol to the server includes unintentional decryption.

[0010] Various embodiments are described, including: limiting the number of tags that can be issued to a client, and secretly storing the tags and their associated query items at the client for future queries.

[0011] Various embodiments are described, including setting an upper limit on the total number of tags allowed for a client based on the access permissions specified in the client's public key certificate, and maintaining a record of the total number of tags issued by the client at the server.

[0012] Various embodiments are described, including: creating a user account on the server and logging into the user account using the client's authorized public key certificate and associated private key, and establishing a secure communication channel with the server.

[0013] Various embodiments are described, including: secretly storing the tag and its associated query items for future queries; and establishing a secure communication channel with the agent.

[0014] Other embodiments relate to a method for setting up secure access to a patient database by a client via a server, comprising: receiving a query tag request, the query tag request including an authorized public key certificate of the client; verifying the client's digital signature; setting up a secure communication channel with the client upon successful verification of the digital signature; communicating with the server to transform attribute value pairs into tags; and using the client account to secretly store the authorized tags.

[0015] Various embodiments are described, wherein communicating with the server to transform attribute value pairs into labels further includes performing an unintentional pseudo-random function (OPRF) evaluation with the client.

[0016] Various embodiments are described, including keeping track of the total number of tags that have been issued against the client.

[0017] Various embodiments are described, wherein verifying the digital signature of the client further includes generating a random message and sending the random message to the client.

[0018] Other embodiments relate to a client system configured to securely access a patient database using an agent system and a server, comprising: a memory configured to store data and computer instructions; and a processor configured to: communicate with the server to transform attribute value pairs into tags; obtain tags associated with the attribute value pairs on a secure communication channel; send a combination of tags for items in a generated conjunctive query to the agent on a secure communication channel; receive encrypted coefficients of a polynomial from the agent, the roots of which are indices of records satisfying the query items; decrypt the encrypted coefficients using a first protocol with the server; compute the roots of the polynomial based on the decrypted coefficients and discard any redundant roots; obtain an encrypted record associated with the computed root; and decrypt the encrypted record using a second protocol with the server.

[0019] Various embodiments are described, wherein the label is a hash value generated by transforming the attribute value pair through collaboration between the client and the server using a method that evaluates the attribute value using an unintentional pseudo-random function that includes authorization.

[0020] Various embodiments are described in which the tag is generated only if one or more of the following criteria are met: (i) the total number of tags issued to the client is within a predefined limit of access permissions specified in the client's public key certificate, and (ii) each query item in the query item has a valid digital signature from a third-party authority.

[0021] Various embodiments are described, wherein decrypting the encryption coefficients with a first protocol with the server includes unintentional decryption.

[0022] Various embodiments are described, wherein decrypting the encrypted record with a second protocol to the server includes unintentional decryption.

[0023] Various embodiments are described, wherein the processor is further configured to: limit the number of tags that can be issued to the client, and secretly store the tags and their associated query items at the client for future queries.

[0024] Various embodiments are described, wherein the processor is further configured to: set an upper limit on the total number of tags allowed for the client based on the access permissions specified in the client's public key certificate, and retain a record of the total number of tags issued for the client at the server.

[0025] Various embodiments are described, wherein the processor is further configured to: create a user account on the server and log in to the user account using the client's authorized public key certificate and associated private key, and establish a secure communication channel with the server.

[0026] Various embodiments are described, wherein the processor is further configured to: secretly store the tag and its associated query items for future queries; and establish a secure communication channel with the agent.

[0027] Other embodiments relate to a server configured to provide secure access to a patient database by a client, comprising: a memory configured to store data and computer instructions; and a processor configured to: receive a query tag request including an authorized public key certificate of the client; verify the client's digital signature; establish a secure communication channel with the client upon successful verification of the digital signature; communicate with the server to transform attribute value pairs into tags; and secretly store the authorized tags using the client's account.

[0028] Various embodiments are described, wherein communicating with the server to transform attribute value pairs into labels further includes performing an unintentional pseudo-random function (OPRF) evaluation with the client.

[0029] Various embodiments are described, wherein the processor is further configured to: keep track of the total number of tags that have been issued for the client.

[0030] Various embodiments are described, wherein verifying the digital signature of the client further includes generating a random message and sending the random message to the client. Attached Figure Description

[0031] To better understand the various exemplary embodiments, reference should be made to the accompanying drawings, in which:

[0032] Figure 1 The diagram illustrates how to set up a database and how to add a new sample to the database.

[0033] Figure 2 The diagram illustrates how to set a limit on the number of allowed queries for authorized anonymous clients;

[0034] Figure 3 The diagram illustrates a method for fully private queries with client-specific query item restrictions; and

[0035] Figure 4 An exemplary hardware diagram for implementing the above-described client, server, or agent is shown.

[0036] To facilitate understanding, the same reference numerals are used to refer to elements having substantially the same or similar structure and / or substantially the same or similar function. Detailed Implementation

[0037] The description and accompanying drawings illustrate the principles of the invention. Therefore, it will be appreciated that those skilled in the art will be able to devise various arrangements that, while not explicitly described or shown herein, embody the principles of the invention and are included within its scope. Furthermore, all examples recorded herein are primarily intended for pedagogical purposes to aid the reader's understanding of the principles of the invention and the inventive concepts developed by (one or more) the inventors in further extending the art, and are to be construed as not being limited to such specifically recorded examples and conditions. Additionally, as used herein, the term "or" means non-exclusive or (i.e., and / or) unless otherwise stated (e.g., "otherwise" or "or in an alternative"). Moreover, the various embodiments described herein are not necessarily mutually exclusive, as some embodiments can be combined with one or more other embodiments to form new embodiments.

[0038] A key aspect of utilizing genetic knowledge repositories for rare diseases (and more common ones) is the ability to submit queries related to each patient's condition and genotype. Equally important is maintaining the privacy of patients residing in the knowledge repository and the patient data included in queries. Existing search engines that purely house genomic data (e.g., the Lighthouse Network) have relatively simple measures (e.g., data aggregation, information budgeting, secure access) to partially mitigate re-identification, as re-identification using exclusive genomic data is difficult. However, for scenarios requiring insights into patient characteristics (e.g., phenotype, diagnostic outcomes, demographics, and other aspects of the patient journey), it is necessary to set the privacy bar higher. Because the combination of genotype and phenotype data makes identifying specific patients easier, it is more difficult to protect the privacy of such patients. Any solution that promises to utilize combined clinical and genomic data must address this privacy dilemma. This paper describes embodiments that address these concerns using a series of methods for database initialization and enhancement, fully private query construction, and client-targeted query restrictions.

[0039] Genetic knowledge repositories are also useful tools for creating and optimizing clinical pathways. Clinical pathways are crucial tools in cancer treatment—they represent a set of standard treatment guidelines for a given patient's medical history. Due to data sharing / ownership barriers, data residing in individual institutions is often used to create and improve clinical pathways. However, privacy-preserving mechanisms could potentially enable cross-institutional genetic knowledge repositories and allow for the provision of additional data as a means of optimizing existing clinical pathways.

[0040] An embodiment of a system for improving secure access to patient data using a set of security protocols will now be described. First, a three-party protocol for fully private concatenated database queries will be described. This three-party protocol is described in more detail in “Private Database Queries Using Somewhat Homomorphic Encryption” by Boneh D., Gentry C., Halevi S., Wang F., and Wu DJ (Jacobson M., Locasto M., Mohassel P., Safavi-Naini R. (eds.), Applied Cryptography and Network Security, ACNS 2013, Lecture Notes in Computer Science, Vol. 7954, Springer, Berlin, Heidelberg) (which is incorporated herein by reference for all purposes included herein).

[0041] The protocol involves three parties: the server, the agent, and the client. During the preprocessing step, the server prepares an encrypted inverse index and sends it to the agent. Afterward, the server retains only the key used to create the inverse index, which includes some hash keys and a secret key for the partially homomorphic encryption (SWHE) scheme.

[0042] For each attribute value pair (a, v) in the database, the inverted index contains the record (tg, Enc(A(x))), where tg is the label, which is computed as tg = Hash(“a = v”), and A(x) is a polynomial whose root is the exact record index r containing that attribute value pair.

[0043] The proxy stores a reverse index and encrypted records against the database. This associates each tag (tg) with specific data recorded in the database. The basic assumption is that there is no collusion between the server and the proxy.

[0044] The client possesses a public key certificate and an associated private key, and obtains the query tag by performing an unintentional pseudo-random function (OPRF) evaluation together with the server. The client secretly stores the query tag and its associated query item and initiates a concatenation query by sending a selected set of tags to the agent over a secure communication channel, ensuring the query remains private.

[0045] To limit the number of queries allowed for authorized anonymous clients, each client is only allowed a maximum number of query tags, depending on the access permissions specified in the client's public key certificate. During the tag generation process, the server keeps a record of the total number of tags issued to a client and stops generating any more tags once the maximum number for a client is reached. The client then secretly stores the tags issued by the server and their associated query items for future queries. As a result, clients can only use a limited number of query items for their queries. Duplicate tag requests for the same query item will result in a waste of tag quota, so clients should avoid this.

[0046] In more restrictive environments where clients are authorized to query only certain attribute value pairs (where these attribute value pairs are independently digitally signed by a third party (e.g., a laboratory generating clinical reports with information on a patient's phenotype and genomic aberrations)), the client obtains a label by performing an unintentional PRF evaluation with the server, where such evaluation succeeds only if the client has a valid signature. A corresponding authorized unintentional PRF protocol is described in "Efficient techniques for privacy-preserving sharing of sensitive information" by De Cristofaro, Emiliano, Yanbin Lu, and Gene Tsudik (International Conference on Trust and Trustworthy Computing, Springer, Berlin, Heidelberg, 2011). At the end of this protocol, if the signature is valid, the label is obtained by the client and the server does not receive any new information. If the signature is invalid, neither the client nor the server receives any new information.

[0047] Figure 1 The diagram illustrates how to set up a database and add a new sample to it. To add a new sample to the database, the server generates a pair of searchable attribute values ​​(a, b, c) for each new sample, including its tag. i v ij The reverse index record 110 of ) is used to generate an encrypted polynomial function 110. A label can be defined as tg = Hash("a i =v ij The encrypted polynomial function can be defined as Enc(A). ij (x)), whose root is the exact record index containing the attribute value pair. Here, Enc() is a SWHE function, and if the attribute value pair already exists in the database, Enc(A) can be regenerated or updated by incorporating the index of the new matching sample as an additional root into the cryptographic polynomial of the existing sample. ij (x)). In the context of clinical and genomic databases, attribute value pairs can include any demographic / clinical data (e.g., "HDL=HIGH") or genomic aberrations (e.g., "BRAF V600E=True"). Next, the server sends the reverse index to the agent and retains only the hash and encryption key 115. The agent then stores the reverse index and encrypted record 120, and the process ends 125.

[0048] Figure 2The diagram illustrates a method for setting a limited number of permissible query items for authorized anonymous clients. To prevent malicious clients from abusing the private query mechanism by performing numerous searches for unauthorized data access, query-level access control is imposed to restrict access to minimal operations and data. This is accomplished through a query tag request process, where an anonymous client with an authorized public key certificate accesses their account at the server 215 by signing a random message generated by the server using their private key. Upon receiving the digital signature, the server verifies the signature using the client's public key, and if the digital signature is correct 220, a secure communication channel can be established 225 using a private session key shared between the server and the client. The client is now able to obtain tags 230 corresponding to a list of attribute value pairs by performing an unintentional pseudo-random function (OPRF) evaluation together with the server. The attribute value pairs are transformed into tags tg = PRF (a = v) 230, where PRF is a pseudo-random function, such as a hash function, and S is the key associated with the PRF. In a more restrictive environment where clients are authorized to query only certain attribute value pairs (where these attribute value pairs are independently digitally signed by a third-party organization), the client obtains tags by performing an unintentional PRF evaluation with the server, where such evaluation only succeeds if the client possesses a valid signature. The client then secretly stores the generated tags and their associated query items for future queries. The server keeps track of the total number of tags issued to clients and imposes a cap on the total number of allowed queries for each client. This process can be repeated until the number of tags reaches the maximum allowed for each client. The maximum number of tags can be set based on the client's access permissions specified in the authorized public key certificate.

[0049] Figure 3 The diagram illustrates a method for fully private queries with client-specific query item restrictions. Assume the client queries "SELECT * FROM database WHERE a1=v1 AND…AND a n =v n "And as described in the tag request process, the tag tg with individual attribute value pairs has been obtained from the server." k The steps involved in a fully private query process are as follows:

[0050] 1. The client and agent set up a secure communication channel to protect query tag 310.

[0051] 2. The client sends the tag tg to the proxy. k Used for concatenation query 315.

[0052] 3. The agent obtains the encryption coefficients A1(x), ..., A of the polynomial. n (x), whose root is related to the attribute value pair a1 = v1, ..., a n =v n The tags tg1, ..., tg n The corresponding record index. Then, the agent uses additive homomorphism to compute... (where R) i (x) is a random polynomial) and sends an encrypted B(x) to the client. The roots of B(x) are those that satisfy the conjunctive query condition "a1 = v1 AND ... AND a n =v n The record is indexed at 320.

[0053] 4. The client and server participate in another protocol to perform an unintentional decryption of B(x) encrypted with the server's private key (325). After this step, the client knows B(x) and the server knows nothing (325 and 330).

[0054] 5. The client parses B(x) to find its root, which contains an index of 335 on records that satisfy the query conditions. Due to the random polynomial R(x) introduced in step 3, some of these roots are redundant. However, since a large enough amount of space has been used, it is most likely that these redundant roots will be identified as invalid roots and discarded roots.

[0055] 6. Using the index of the matching record, the client can directly send the index or use Private Information Retrieval (PIR) / Occurrence RAM (ORAM) to retrieve the encrypted record 340, and then perform inadvertence decryption with the server to obtain the decrypted record 345.

[0056] Some examples of applying the embodiments described herein will now be given.

[0057] In the first example, the clinician queries an existing database for registered patients. Automated (hospital-initiated, third-party application-initiated) or manual (clinic-initiated) queries can be submitted to an existing genetics knowledge repository for registered pediatric patients. Based on the presented phenotype, the clinician initially suspects a diagnosis of Shprintzen-Goldberg syndrome. However, the patient tests negative for a known pathogenic SKI gene mutation. The query includes the following set of patient characteristics:

[0058] Demographic information: age, gender

[0059] Phenotype: The symptoms presented indicate Sphrintzen-Goldberg syndrome.

[0060] Genotype: SKI gene mutation negative

[0061] Since a genetics knowledge repository (database) has already been set up for this scenario, database setup is not required. Then, a fully private query with the following restrictions is executed:

[0062] 1. The clinician's client uses his public key certificate to log in to his account.

[0063] 2. The client communicates with the server via a secure channel to obtain OPRF evaluation tags for the attribute value pairs in the query. Tags are generated only for query items with valid digital signatures from third-party organizations. The server records the total number of tags issued to clients and imposes an upper limit based on the client's access permissions specified in its public key certificate.

[0064] 3. After receiving the tag, the client sends the tag to the agent.

[0065] 4. The agent retrieves the encrypted coefficients of the polynomial (whose roots are indexes of records that satisfy the query conditions) and sends the encrypted coefficients to the client.

[0066] 5. The client communicates with the server to perform unintentional decryption of the encryption coefficients.

[0067] 6. The client parses the coefficients to obtain the record index.

[0068] 7. The client uses the record index to retrieve encrypted records and communicates with the server to perform unintentional decryption to obtain the final unencrypted record.

[0069] By using unencrypted records, another case was discovered where the patient shared many phenotypic characteristics, in which a diagnosis of Kosaki overgrowth syndrome was made to confirm that the pathogenicity was a PDGFRB gene mutation. Based on this information, the clinician ordered a genetic test for the PDGFRB mutation. The results showed that the patient actually had a novel mutation in PDGFRB, and subsequent treatment decisions were based on this new diagnostic finding.

[0070] In the second example, the clinical pathway optimization process is illustrated. A renowned cancer center issuing a clinical pathway license has consulted with several clients (other healthcare institutions paying for such licenses) to work towards a specific licensing model that reduces the direct licensing costs of using clinical pathways instead of participating in a shared clinical knowledge base for collaborating institutions. The cancer center wants to use the clinical knowledge base to evaluate the performance of a particular pathway and identify areas for improvement, while keeping its proprietary clinical pathways private. The cancer center (in this case, the client) has registered and therefore has a set of tags corresponding to a pre-determined set of permissible queries based on each clinical pathway. By using combinations of query tags (representing part or all of the pathways of interest), the cancer center is able to evaluate records in the knowledge base to obtain aggregated results data. Using this data, the cancer center concludes that there is no measurable benefit to patients with aggressive disease receiving specific systemic treatments within that pathway and chooses to change the pathway to reflect this new knowledge.

[0071] In the third example, a public figure was diagnosed with major depressive disorder and severe insomnia and was already using currently available prescription medications, but his symptoms were worsening. He wanted to find clinical trials that might improve his condition but was worried that unprotected online searches might expose his mental health issues to the media. He learned about a clinical trial database that used restricted, fully private query technology and decided to give it a try. He obtained an anonymous digital certificate and electronic clinical reports from the hospital, which included information about his diagnosis and symptoms (“Diagnosis = ‘Major Depression’”, “Symptoms = ‘Insomnia’”) and personal background (“Gender = ‘Male’”, “Race = ‘Caucasian’”, “Age = ‘20-30’”, etc.). Each key item in the report had a digital signature from the hospital, allowing each key item to be used as a query item. He used the anonymous digital certificate to create an account to access the clinical trial database and then submitted the relevant query item along with its digital signature to the database server. Through the query process, none of his sensitive personal data was exposed to the database server or the network. He found a matching clinical trial that used a survey-based digital therapy approach to provide cognitive behavioral therapy for insomnia and sleep restriction algorithms, aiming to reduce the severity of insomnia and depressive symptoms. He enrolled in the trial, and after several months of treatment, his condition improved significantly.

[0072] Figure 4 An exemplary hardware diagram 400 for implementing the aforementioned client, server, or agent is illustrated. As shown, device 400 includes a processor 420, memory 430, user interface 440, network interface 450, and storage device 460, which are interconnected via one or more system buses 410. It should be understood that, in some aspects, Figure 4This constitutes an abstraction, and the actual organization of the components of device 400 can be more complex than shown.

[0073] Processor 420 can be any hardware device capable of executing instructions stored in memory 430 or storage device 460 or otherwise processing data. Therefore, processor can include microprocessors, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), or other similar devices.

[0074] Memory 430 may include various types of memory, such as L1, L2, or L3 cache memory or system memory. Therefore, memory 430 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read-only memory (ROM), or other similar memory devices.

[0075] User interface 440 may include one or more devices for communicating with a user. For example, user interface 440 may include a display, touch interface, mouse, and / or keyboard for receiving user commands. In some embodiments, user interface 440 may include a command-line interface or a graphical user interface that can be presented to a remote terminal via network interface 450.

[0076] Network interface 450 may include one or more devices for enabling communication with other hardware devices. For example, network interface 450 may include a network interface card (NIC) configured to communicate according to the Ethernet protocol or other communication protocols, including wireless protocols. Alternatively, network interface 450 may implement a TCP / IP stack for communication according to the TCP / IP protocol. Various alternatives or additional hardware or configurations for network interface 450 will be readily apparent.

[0077] Storage device 460 may include one or more machine-readable storage media, such as read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash memory devices, or similar storage media. In various embodiments, storage device 460 may store instructions for execution by processor 420 or data operable by processor 420. For example, storage device 460 may store a basic operating system 461 for controlling various basic operations of hardware 400. Storage device 461 may store instructions 462 for performing the functions of the aforementioned server, client, or agent.

[0078] It is obvious that various descriptive information, such as that stored in storage device 460, may be additionally or alternatively stored in memory 430. In this respect, memory 430 may also be considered as constituting a "storage device," and storage device 460 may be considered as a "memory." Various other arrangements will be apparent. Furthermore, both memory 430 and storage device 460 may be considered as "non-transient machine-readable media." As used herein, the term "non-transient" will be understood to exclude transient signals and instead include all forms of storage devices, including volatile and non-volatile memory.

[0079] Although host device 400 is shown as including one of each described component, various components may be replicated in various embodiments. For example, processor 420 may include multiple microprocessors configured to independently run the methods described herein, or configured to execute steps or subroutines of the methods described herein, such that multiple processors cooperate to achieve the functions described herein. Furthermore, in the case where device 400 is implemented in a cloud computing system, various hardware components may belong to separate physical systems. For example, processor 420 may include a first processor in a first server and a second processor in a second server.

[0080] The embodiments described herein address the technical challenge of improving security and patient privacy when querying patient databases containing patient information. For example, identifying specific patients becomes much easier when the patient database includes both genomic and phenotypic data. Therefore, the embodiments described above only allow users to query the database for authorized attribute value pairs with specific values. As a result, clients are restricted in what data they can access, which improves the security and privacy of the patient database.

[0081] Any combination of specific software running on a processor to implement embodiments of the present invention constitutes a specific dedicated machine.

[0082] As used herein, the term “non-transient machine-readable storage medium” will be understood to exclude transient propagation signals and include all forms of volatile and non-volatile memory.

[0083] While various exemplary embodiments have been described in detail with specific reference to certain exemplary aspects of the invention, it should be understood that other embodiments are also possible, and the details can be modified in various obvious ways. It will be apparent to those skilled in the art that variations and modifications can be made while still remaining within the spirit and scope of the invention. Therefore, the foregoing disclosure, description, and drawings are for illustrative purposes only and are not intended to limit the invention in any way, which is defined only by the claims.

Claims

1. A method of secure access by a client to a patient database, comprising: communicating with a server to transform attribute-value pairs into tags, wherein the tags are computed as hashes of the respective attribute-value pairs in the patient database; obtaining from the server on a secure communication channel tags associated with the attribute-value pairs; sending to an agent on a secure communication channel a combination of tags defining items in a conjunctive query; receiving from the agent encrypted coefficients of a polynomial whose roots are indices of records satisfying the query items; communicating with the server to decrypt the encrypted coefficients in a first protocol; computing by the client the roots of the polynomial based on the decrypted coefficients and discarding any extraneous roots; obtaining from the agent encrypted records for the patient database associated with the computed roots; and communicating with the server to decrypt the encrypted records in a second protocol, wherein the server is configured to provide only tags for attribute-value pairs that are individually digitally signed by a third party authority.

2. The method of claim 1, wherein, the tags are hash values generated by a method that uses an authorized oblivious pseudo-random function evaluation transformed by a collaboration between the client and the server.

3. The method of claim 1, wherein, the tags are generated only if the total number of tags issued for the client is within a predefined limit of access rights specified in a public key certificate of the client.

4. The method of claim 1, wherein, decrypting the encrypted coefficients in the first protocol with the server includes oblivious decryption.

5. The method of claim 1, wherein, decrypting the encrypted records in the second protocol with the server includes oblivious decryption.

6. The method of claim 1, further comprising: limiting the number of tags that can be issued for a client and secret storing the tags and their associated query items at the client for future queries.

7. The method of claim 5, wherein, further comprising: setting an upper limit on the total number of tags allowed for a client according to access rights specified in a public key certificate of the client and keeping a record of the total number of tags already issued for the client at the server.

8. The method of claim 1, further comprising: creating a user account on the server using an authorized public key certificate and associated private key of the client and logging into the user account and establishing a secure communication channel with the server.

9. The method of claim 1, further comprising: secret storing the tags and their associated query items for future queries; and establishing a secure communication channel with the agent.

10. A method of setting up secure access by a client to a patient database by a server, comprising: receiving a query tag request, the query tag request including an authorized public key certificate of the client; verifying a digital signature of the client using the public key of the client; setting up a secure communication channel with the client upon successful verification of the digital signature; transforming attribute-value pairs into tags and transmitting the tags of the attribute-value pairs to the client, wherein the tags are computed as hashes of the respective attribute-value pairs in the patient database; and secret storing the tags with a client account, wherein the server is configured to provide only tags for attribute-value pairs that are individually digitally signed by a third party authority. the tags are hash values generated by a method that uses an authorized oblivious pseudo-random function evaluation transformed by a collaboration between the client and the server. the tags are generated only if the total number of tags issued for the client is within a predefined limit of access rights specified in a public key certificate of the client. decrypting the encrypted coefficients in the first protocol with the server includes oblivious decryption. decrypting the encrypted records in the second protocol with the server includes oblivious decryption. limiting the number of tags that can be issued for a client and secret storing the tags and their associated query items at the client for future queries. further comprising: setting an upper limit on the total number of tags allowed for a client according to access rights specified in a public key certificate of the client and keeping a record of the total number of tags already issued for the client at the server. creating a user account on the server using an authorized public key certificate and associated private key of the client and logging into the user account and establishing a secure communication channel with the server. secret storing the tags and their associated query items for future queries; and establishing a secure communication channel with the agent.

11. The method of claim 10, wherein, Transforming the attribute-value pair into a tag further comprises performing an oblivious pseudo-random function (OPRF) evaluation with the client.

12. The method of claim 10, further comprising keeping track of a total number of tags that have been issued for the client.

13. The method of claim 10, wherein, Verifying the digital signature of the client further comprises generating a random message and sending the random message to the client.

14. A client system configured to securely access a patient database using a proxy system and a server, comprising: a memory configured to store data and computer instructions; and a processor configured to: communicate with the server to receive a tag for an attribute-value pair, wherein the tag is computed as a hash of the corresponding attribute-value pair in the patient database; obtain the tag for the attribute-value pair over a secure communication channel; send a combination of tags defining items in a conjunctive query to a proxy over a secure communication channel; receive encrypted coefficients of a polynomial from the proxy, roots of the polynomial being indices of records that satisfy the query items; communicate with the server to decrypt the encrypted coefficients in a first protocol; compute the roots of the polynomial based on the decrypted coefficients by the client and discard any extraneous roots; obtain encrypted records for the patient database associated with the computed roots from the proxy; and communicate with the server to decrypt the encrypted records in a second protocol, wherein the server is configured to only provide tags for attribute-value pairs that are individually digitally signed by a third-party authority.

15. The system of claim 14, wherein, the tag is a hash value generated by transforming the attribute-value pair by a collaboration between the client and the server using a method comprising an authorized oblivious pseudo-random function evaluation.

16. The system of claim 14, wherein, the tag is generated only if a total number of tags issued for the client is within a predefined limit of access rights specified in a public key certificate of the client.

17. The system of claim 14, wherein, decrypting the encrypted coefficients in a first protocol with the server comprises oblivious decryption.

18. The system of claim 14, wherein, decrypting the encrypted records in a second protocol with the server comprises oblivious decryption.

19. The system of claim 14, wherein, the processor is further configured to limit a number of tags that can be issued for a client and to secret store tags and their associated query items at the client for future queries.

20. The system of claim 19, wherein, the processor is further configured to set an upper limit of a total number of tags allowed for a client according to access rights specified in a public key certificate of the client and to keep a record of a total number of tags that have been issued for the client at the server.

21. The system of claim 14, wherein, the processor is further configured to create and log into a user account on the server using an authorized public key certificate and associated private key of the client and to establish a secure communication channel with the server.

22. The system of claim 14, wherein, the processor is further configured to secret store the tags and their associated query items for future queries and to establish a secure communication channel with the proxy.

23. A server configured to set up secure access to a patient database by a client, comprising: a memory configured to store data and computer instructions; and a processor configured to: communicate with the server to receive a tag for an attribute-value pair, wherein the tag is computed as a hash of the corresponding attribute-value pair in the patient database; obtain the tag for the attribute-value pair over a secure communication channel; send a combination of tags defining items in a conjunctive query to a proxy over a secure communication channel; receive encrypted coefficients of a polynomial from the proxy, roots of the polynomial being indices of records that satisfy the query items; communicate with the server to decrypt the encrypted coefficients in a first protocol; compute the roots of the polynomial based on the decrypted coefficients by the client and discard any extraneous roots; obtain encrypted records for the patient database associated with the computed roots from the proxy; and communicate with the server to decrypt the encrypted records in a second protocol, wherein the server is configured to only provide tags for attribute-value pairs that are individually digitally signed by a third-party authority. a processor configured to: receive a query tag request, the query tag request including an authorized public key certificate of the client; verify a digital signature of the client using the public key of the client; set up a secure communication channel with the client upon successful verification of the digital signature; transform attribute value pairs into tags and transmit the tags of the attribute value pairs to the client, wherein the tags are computed as hashes of corresponding attribute value pairs in the patient database; and secretly store the tags with a client account, wherein the server is configured to only provide tags for attribute value pairs that are individually digitally signed by a third party authority.

24. The server of claim 23, wherein, transforming attribute value pairs into tags further includes performing an Oblivious Pseudo-Random Function (OPRF) evaluation with the client.

25. The server of claim 23, wherein, the processor is further configured to keep track of a total number of tags that have been issued for the client.

26. The server of claim 23, wherein, verifying the digital signature of the client further includes generating a random message and sending the random message to the client.

Images