A protocol for reliable and privacy-preserving genome database discovery

Abstract

A system and method for verifying by a requester that a respondent has genomic data that meets specified requirements, the system and method including digitally publishing the specified requirements, performing a non-interactive zero-knowledge (NIZK) proof with the respondent, verifying that the respondent has genomic data that meets the specified requirements based on the results of the NIZK proof, and receiving encrypted genomic data that meets the specified requirements from the respondent.

Description

[Technical field]

[0001] Various exemplary embodiments disclosed herein relate generally to protocols for reliable, privacy-preserving genomic database discovery. [Background technology]

[0002] Users of genomic data will want to compile large sets of high-quality, reliable genomic data for a variety of purposes. Such exchanges of genomic data may be conducted using privacy-preserving techniques to meet the various privacy requirements associated with genomic data. Summary of the Invention [Problem to be solved by the invention]

[0003] To meet these privacy requirements, privacy-preserving computing techniques can be used on genomic databases. [Means for solving the problem]

[0004] A summary of various exemplary embodiments is provided below. In the following summary, some simplifications and omissions may be made, which are intended to highlight and introduce some aspects of various exemplary embodiments, but do not limit the scope of the present invention. Illustrative details sufficient to enable a person skilled in the art to make and use the concepts of the present invention follow in subsequent paragraphs.

[0005] Various embodiments relate to a method for verifying by a requester that a respondent has genomic data that meets specified requirements, which includes digitally publishing the specified requirements, performing a Non-Interactive Zero-Knowledge (NIZK) proof with the respondent, verifying that the respondent has genomic data that meets the specified requirements based on the result of the NIZK proof, and receiving encrypted genomic data from the respondent that meets the specified requirements.

[0006] Various embodiments are described in which a NIZK proof uses one of a zero-knowledge Succinct Non-interactive ARgument of Knowledge (zk-SNARK) protocol, a zero-knowledge Scalable and Transparent ARgument of Knowledge (zk-STARK) protocol, and a Succinct Non-interactive ARGument (SNARG) protocol.

[0007] Various embodiments are described in which a requirement for a public digital signature key for a source of genomic data that the respondent trusts is included.

[0008] Various embodiments are described in which the public digital signature key is for a particular genome sequencer.

[0009] Various embodiments are described in which the public digital signature key is for a particular medical trial.

[0010] Various embodiments are described in which the requirements further include a threshold indicating the amount of genomic data required.

[0011] Various embodiments are described in which a NIZK attestation receives as input specific requirements and genomic data with associated digital signatures from respondents who meet the specific requirements.

[0012] Various embodiments are described in which the digital signature uses an elliptic curve digital signature protocol.

[0013] Various embodiments are described in which genomic data is hashed before being entered into the NIZK certificate.

[0014] Various embodiments are described in which the specified requirements are published on one of a webpage or a blockchain.

[0015] Various embodiments are described that further include publishing the attestation key and the verification key, where the attestation key and the verification key are output from the NIZK certificate.

[0016] Further, various embodiments relate to a method for proving verification by a respondent that the respondent has genomic data that meets specified requirements of a requester, the method including determining that the respondent has genomic data issued by the requester that meets the specified requirements, performing a non-interactive zero-knowledge (NIZK) proof with the requester, receiving a request from the requester for genomic data that meets the specified requirements, and transmitting encrypted genomic data that meets the specified requirements to the requester.

[0017] Various embodiments are described in which the NIZK proof uses one of a zero-knowledge succinct non-interactive knowledge proof (zk-SNARK) protocol, a zero-knowledge scalable transparent knowledge proof (zk-STARK) protocol, and a succinct non-interactive proof (SNARG) protocol.

[0018] Various embodiments are described in which the requirement includes a public digital signature key for the source of the genomic data that the respondent trusts.

[0019] Various embodiments are described in which the public digital signature key is for a particular genome sequencer.

[0020] Various embodiments are described in which the public digital signature key is for a particular medical trial.

[0021] Various embodiments are described in which the requirements further include a threshold indicating the amount of genomic data required.

[0022] Various embodiments are described in which a NIZK attestation receives as input specific requirements and genomic data with associated digital signatures from respondents who meet the specific requirements.

[0023] Various embodiments are described in which the digital signature uses an elliptic curve digital signature protocol.

[0024] Various embodiments are described in which genomic data is hashed before being entered into the NIZK certificate.

[0025] Various embodiments are described in which the specified requirements are published on one of a webpage or a blockchain.

[0026] Various embodiments are described that further include publishing the attestation key and the verification key, where the attestation key and the verification key are output from the NIZK certificate. [Brief description of the drawings]

[0027] For a better understanding of various exemplary embodiments, reference is made to the accompanying drawings. [Figure 1] Block diagram of the genomic data protocol. [Diagram 2] FIG. 1 is a block diagram of an example implementation of the genomic data protocol. [Diagram 3] An exemplary hardware diagram for implementing various portions of the system for implementing the genomic data protocol of Figures 1 and 2. For ease of understanding, the same reference numbers have been used to indicate elements having substantially the same or similar structure and / or substantially the same or similar functionality. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0028] The description and drawings illustrate the principles of the present invention. Thus, it will be understood that those skilled in the art can devise various configurations that embody the principles of the present invention and fall within its scope, although not explicitly described or illustrated herein. Furthermore, all examples recited herein are intended primarily for the purpose of aiding the reader in understanding the principles of the present invention and the concepts contributed by the inventor to advance the art, and should be construed as not being limited to such specifically recited examples and conditions. Furthermore, the term "or" as used herein refers to a non-exclusive "or" (i.e., "and / or"), unless otherwise indicated (e.g., "otherwise" or "or alternatively"). Also, the various embodiments described herein are not necessarily mutually exclusive, and some embodiments can be combined with one or more other embodiments to form new embodiments.

[0029] The generation of fake genomic data has become so advanced that, as a result, the genomics industry now requires tools and technologies that protect the privacy and ensure the authenticity of the underlying data.

[0030] While genomic databases are currently positive in assessing and adhering to privacy protections for genomic data, this comes with one major drawback: the quality of private genomic databases is difficult to assess. Consider a scenario in which a company is interested in buying some kind of access to private genomic data. How does a company compare two or more private genomic databases without violating the privacy of the underlying data? How does a company verify the quality and quantity of its own data? Why would a company not pay for a private database filled with genomic data generated by machine learning? These questions pose practical drawbacks to a number of possible transactions between owners and buyers of private genomic data. Disclosed herein is a genomic data protocol that resolves all these questions through the exchange of cryptographic evidence between the parties.

[0031] In the first approach, the two parties to the exchange of genomic data must establish some kind of trusted relationship that allows for secure, private, and reliable access to the genomic database. Such an approach may consume a lot of effort and resources, especially when the party seeking access to the private genomic data determines that the private genomic data does not meet its needs. In the second approach, such an exchange may be facilitated by a trusted third party. However, again, the second approach may have the same problems associated with the first approach. Both approaches also require the party seeking genomic data to find potential sources of genomic data and identify potential providers of the desired genomic data. Meanwhile, providers of genomic data are looking for ways to sell access to the data while providing authentication of the data and maintaining the privacy of the data. The genomic data protocol described herein helps facilitate such interactions.

[0032] The genomic data protocol described herein is a decentralized protocol for discovering private genomic databases that contain an appropriate amount of reliable genomic data. The genomic data protocol works by the exchange of zero-knowledge proofs that securely attest to the origin and volume of genomic data (or other desired requirements for genomic data) between parties. A requester publishes a request for genomic data, for example on a webpage or blockchain that is publicly available or available to a provider of genomic data. Such a request may ask for a specific amount of reliable genomic data. A genomic data provider can see the request and can engage in a zero-knowledge proof exchange to prove to the requester that they can provide the requested genomic data.

[0033] Non-interactive zero-knowledge proof (NIZK) can prove that a provider of genome data is committed to possessing genome data that satisfies a request from a requester. NIZK is a type of zero-knowledge proof. In the field of cryptography, zero-knowledge proof itself is known as a method to have a verifier prove that the prover knows a certain value that satisfies a certain property φ. In this case, the device can construct a NIZK for each satisfied predefined property that proves that the provider is committed to possessing genome data that satisfies the requested property. Interestingly, it is known from cryptography that for various statements φ, it is possible to prove such statements φ without having to reveal the value itself. In general, such proofs may involve a series of interactions, for example involving one or more queries by the verifier that are answered by the prover, finally convincing the verifier that the prover actually knows the correct value x. As a summary example of the concept of zero-knowledge proof, reference is made to the example of "Ali Baba's Cave" described in https: / / en.wikipedia.org / w / index.php?title=zero-knowledge_proof&oldid=901394099 (incorporated herein by reference for all purposes). In this case, the zero-knowledge proof may be a non-interactive zero-knowledge proof, e.g., proof of a particular set of genomic data may meet the particular requirements of a requester.

[0034] In the following examples, zero-knowledge concise non-interactive proof of knowledge (zk-SNARK) proofs are used as an example of NIZK proofs. zk-SNARKs are cryptographic proof techniques for establishing knowledge or ownership in a confidential manner (see "Short non-interactive zero-knowledge proofs, In Proceedings of ASIACRYPT 2010", which is incorporated herein for all purposes). zk-SNARKs are increasingly being applied to authenticate and conceal data used in transactions between peers, especially in the area of ​​blockchain-based assets where confidentiality is important. As mentioned above, in the area of ​​genomics, confidential transactions are of increasing interest as the industry begins to move towards privacy-preserving computation techniques on genomic databases. However, the generation of fake genomic data is very advanced and can be difficult to detect. Thus, users may wish to be able to verify the source of the requested data. It should be noted that various other known but yet to be developed types of zero-knowledge proofs, e.g., zero-knowledge scalable transparent knowledge arguments (zk-STARKs), succinct non-interactive arguments (SNARGs), etc., could similarly be used in genomic data protocols with similar advantages.

[0035] FIG. 1 shows a block diagram 100 of a genomic data protocol. The proposed protocol involves the use of a zk-SNARK attestation protocol between a requester 110, a party seeking to find private databases that meet certain conditions, and a responder 120, a private genomic database owner seeking to prove that they can meet the conditions of the request without revealing the private data. The requester 110 determines a set of conditions that define the genomic data being sought, which constitutes a request 112 for genomic data. As described further below, such a request 112 may include a minimum number of samples from one or more specific data sources that are trusted by the requester 110. In another embodiment, the request may specify that n samples are requested from a first source, m samples are requested from a second source, and so on. The request may be simple or may include many different conditions that the provider must meet. The request may be uploaded 150 to a webpage 130 or blockchain 132. Such webpages 130 and blockchains 132 may be publicly available or may be private in that they only allow access to certain parties. A respondent 120 seeking to grant access to data for compensation, exchange with a requester, or other medical purposes accesses (152) a request 112 from either a web page 130 or the blockchain 132. The respondent 120 then verifies that it has the amount and type of data indicated in the request 112.

[0036] The respondent 120 then generates a proof 122 (zk-SNARK) for the conditions that the requester 110 uploaded on the webpage 130 or blockchain 132, and the requester 110 verifies the proof. In this example, the conditions may include a set of public keys PKi and a threshold n. The set of public keys PKi serves as a cryptographic identifier of the source of genomic data that the requester 110 trusts. The threshold n represents the minimum number of genomic samples that should be digitally signed by one of these keys. Both the set of PKi and the threshold n serve as public inputs for the zk-SNARK proof created by the respondent 120. In addition, the zk-SNARK receives private inputs from the responders, which are their private genomic samples. The zk-SNARK proof function f works by checking that n or more private genomic samples are correctly signed by a public key from the set PKi. The zk-SNARK proof yields a public verification key 114 and a proof key 124. Now, the requester 114 can verify the proof 122 using the verification key 114. Note that others with access to the public verification key 114 can also verify the proof. Thus, the verification key 114 and the proof key 124 can be stored on a web page 130 or on the blockchain 132. This allows other requesters who are interested in the same data specified in the request 112 to easily verify that the responder 120 has the requested data. This makes it easier for other requesters and responders 120 to share genomic data.

[0037] FIG. 2 provides a block diagram 200 of an example implementation of the genomic data protocol. A requester 110 may indicate that it trusts a particular source of genomic data, such as data from a particular sequencer 212 or a particular medical test 216. Additionally, the requester may state that it would like a particular number, n, of samples. The requirements would then include the public digital signature keys of the trusted sources and the number of samples provided to each trusted source. The sequencer 212 may digitally sign the generated sequencing results using an asymmetric cryptographic key pair. In this disclosure, a particular sequencer may be a single sequencer, a particular model of a sequencer, all sequences from a particular manufacturer, or any combination of these, as long as the same private signature key is used by all the particular sequencers. For example, a sequencer manufacturer may publish a public signature key 214 for its sequencer, or, for example, each particular model may have its own public signature key. Then, when the sequencer generates the genomic data, that data is signed using the private key, so that the signed results may be verified using the public key. This allows users of the data to verify the source of the genomic data and can trust the genomic data because they trust the particular sequencer. This may be done for the medical trial data 216, i.e., digitally signed using a public signing key of an asymmetric key pair 218 associated with the medical trial, which can be verified and trusted by the requester.

[0038] A practical deployment of the genomic data protocol may be achieved with elliptic curve cryptography, for example using the secp256r curve to realize the asymmetric cryptographic key pair and the Elliptic Curve Digital Signature Algorithm (ECDSA) to digitally sign the sample. Note that other digital signature schemes, such as RSA and ElGamal, may also be used. For example, the respondent 120 has a signed sample of genomic data 224. To reduce the data size of the genomic data sample input to the zkSNARK protocol, the genomic data may optionally be hashed 222 using an algorithm such as SHA-256 (Secure Hash Algorithm with 256-bit output), although any other hash function may be used.

[0039] To implement the zk-SNARK protocol, a library such as MIT's libSnark can be used to implement the proof function f as a sequence of rank-1 constraints. The library then compiles the function f into a secondary span program. This secondary span program is then input to a zk-SNARK generator along with a random secret element. The result is a public proof key and a verification key (see 114, 124 in FIG. 1). The responder uses this public proof key along with the public input (a set of public ECC keys and a threshold number n of data sequences) and the private input (a signed genome sample, possibly a hash) to create a proof 122. The requester 110 verifies the proof 122 with the public verification key 114. Note that other parties with public verification can do the same. Finally, the conditions (public key set PKi, threshold n) as well as the public proof key 124 and verification key 114 can be uploaded to the blockchain 132 or website 130.

[0040] Figure 3 illustrates an exemplary hardware diagram 300 for implementing the genomic data protocol of Figures 1 and 2 and for implementing various portions of the system. As shown, device 300 includes a processor 320, memory 330, a user interface 340, a network interface 350, and storage 360, interconnected via one or more system buses 310. It will be understood that Figure 3 is, in some respects, constructed abstractly and that the actual organization of the components of device 300 may be more complex than depicted.

[0041] Processor 320 may be any hardware device capable of executing instructions or processing data stored in memory 330 or storage device 360. Thus, the processor may include a microprocessor, a graphics processing unit (GPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), any processor capable of parallel computing, or other similar device.

[0042] Memory 330 may include a variety of memories, such as, for example, an L1, L2, or L3 cache or system memory. As such, memory 330 may include static random access memory (SRAM), dynamic RAM (DRAM), flash memory, read-only memory (ROM), or other similar memory devices.

[0043] User interface 340 may include one or more devices for enabling communication with a user and presenting information to a user. For example, user interface 340 may include a display, a touch interface, a mouse and / or a keyboard for receiving user commands. In an embodiment, user interface 340 may include a command line interface or a graphical user interface that may be presented to a remote terminal via network interface 350.

[0044] Network interface 350 may include one or more devices for enabling communication with other hardware devices. For example, network interface 350 may include a network interface card configured to communicate according to an Ethernet protocol or other communication protocol, including a wireless protocol. Additionally, network interface 350 may implement a TCP / IP stack for communicating according to a TCP / IP protocol. Various alternative or additional hardware or configurations for network interface 350 will be apparent.

[0045] The storage device 360 ​​may include one or more machine-readable storage media, such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium, an optical storage medium, a flash memory device, or a similar storage medium. In various embodiments, the storage device 360 ​​may store instructions for execution by the processor 320 or data on which the processor 320 may operate. For example, the storage device 360 ​​may store a basic operating system 361 for controlling various basic operations of the hardware 300. The storage device 362 may store instructions for implementing a genomic data protocol. For example, one instance of FIG. 3 may be considered a requester and may execute the requester part of the genomic data protocol. In another example, one instance of FIG. 3 may be considered a responder and may execute the responder part of the genomic data protocol. Additionally, the system 300 of FIG. 3 may implement a web page 130 or a blockchain 132. Additionally, the system 300 may be found within a sequencer 212 that generates and signs the genomic data, or the system 300 may be found within a server that stores and provides the medical test data 216.

[0046] It will be apparent that the various information described as being stored in storage 360 ​​may additionally or alternatively be stored in memory 330. In this regard, memory 330 may be considered to constitute a "storage device" and storage 360 ​​may be considered a "memory." Additionally, memory 330 and storage 360 ​​may both be considered "non-transitory machine-readable media." As used herein, the term "non-transitory" is understood to exclude transitory signals and to include all forms of storage, including both volatile and non-volatile memory.

[0047] Although the apparatus 300 is shown as including one of each of the described components, various components may be duplicated in various embodiments. For example, the processor 320 may include multiple microprocessors configured to independently perform the methods described herein or to perform steps or subroutines of the methods described herein, such that the multiple processors cooperate to achieve the functions described herein. Such multiple processors may be of the same type or different types. Furthermore, when the apparatus 300 is implemented in a cloud computing system, the various hardware components may belong to separate physical systems. For example, the processor 320 may include a first processor in a first server and a second processor in a second server.

[0048] The genomic data protocol and system described herein provide technical improvements over current methods and systems for providing genomic data to requesters. The genomic data protocol and system allow a requester to publish or advertise a request for genomic data, which may indicate the amount of data sought and a trusted provider. The requester and provider can then perform a NIZK proof that verifies that the provider has data that meets the requester's requirements and conditions. This allows the requester to determine that the data obtained from the responder is valid genomic data from a trusted source and that the genomic data was not generated fraudulently, while maintaining the privacy and confidentiality of the genomic data. The genomic data protocol means that a requester of data does not need to work with a trusted third party or set up an authenticated and secure relationship with each potential provider of genomic data. Furthermore, once a requester's request is verified, such verification is made public, and other requesters can rely on the NIZK proof to verify and obtain the same data requested by the first requester.

[0049] Any combination of specific software executed on a processor to implement an embodiment of the present invention constitutes a specific special-purpose machine.

[0050] As used herein, the term "non-transitory machine-readable storage medium" excludes transitory, propagating signals, but is understood to include all forms of volatile and non-volatile memory.

[0051] Although various illustrative embodiments have been described in detail with particular reference to certain exemplary aspects thereof, it should be understood that the invention is capable of other exemplary embodiments and its details can be modified in various obvious respects. As will be readily apparent to those skilled in the art, variations and modifications can be made while remaining within the spirit and scope of the invention. Accordingly, the foregoing disclosure, description and drawings are for illustrative purposes only and do not in any way limit the invention, which is defined solely by the claims.

Claims

1. 1. A system for verifying, by a requester, that a respondent has genomic data that meets certain requirements, comprising: a digital publishing unit for digitally publishing the specific requirements; a proof execution unit for executing a non-interactive zero-knowledge (nizk) proof with the respondent; A verification unit that verifies that the respondent has genome data that meets the specific requirements based on the result of the nizk proof; a receiving unit for receiving encrypted genomic data from said respondent that meets said specific requirements; A system having

2. 2. The system of claim 1, wherein the nizk proof uses one of a zero-knowledge succinct non-interactive knowledge proof (zk-SNARK) protocol, a zero-knowledge scalable transparent knowledge proof (zk-STARK) protocol, and a succinct non-interactive proof (SNARG) protocol.

3. The system of claim 1 , wherein the requirements include a public digital signature key for a source of genomic data that the respondent trusts.

4. The system of claim 3 , wherein the public digital signature key is for a particular genome sequencer.

5. The system of claim 3 , wherein the public digital signature key is for a particular medical trial.

6. The system of claim 3 , wherein the requirements further include a threshold indicating an amount of genomic data requested.

7. The system described in claim 1, wherein a proof execution unit receives as input for the NIZK proof the specific requirements and genomic data with associated digital signatures from the respondent that meets the specific requirements.

8. The system of claim 7 , wherein the digital signature uses an Elliptic Curve Digital Signature Protocol.

9. The system of claim 7 , wherein the genomic data is hashed before being input into the NIZK certificate.

10. The system described in claim 1, wherein the digital publication unit publishes the specific requirements on a webpage or on a blockchain.

11. The system of claim 10, further comprising a key publishing unit for publishing an attestation key and a verification key, the attestation key and the verification key being output from the NIZK certificate.

12. 1. A system for providing verification by a respondent that the respondent has genomic data that meets a particular requirement of a requester, comprising: a determining unit for determining whether a respondent has genome data published by the requester that meets the specific requirements; a proof execution unit for executing a non-interactive zero-knowledge (NIZK) proof with the claimant; a receiving unit for receiving a request from the requester for the genomic data that meets the specified requirements; a sending unit for sending encrypted genomic data meeting said specific requirements to said requester; A system having

13. 13. The system of claim 12, wherein the nizk proof uses one of a zero-knowledge succinct non-interactive knowledge proof (zk-SNARK) protocol, a zero-knowledge scalable transparent knowledge proof (zk-STARK) protocol, and a succinct non-interactive proof (SNARG) protocol.

14. The system of claim 12 , wherein the requirements include a public digital signature key for a source of genomic data that the respondent trusts.

15. The system of claim 14 , wherein the public digital signature key is for a particular genome sequencer.

16. 15. The system of claim 14, wherein the public digital signature key is for a particular medical trial.

17. The system of claim 14 , wherein the requirements further include a threshold indicating an amount of genomic data requested.

18. The system described in claim 12, wherein a proof execution unit receives as input for the NIZK proof the specific requirements and genomic data with associated digital signatures from the respondent that meets the specific requirements.

19. 20. The system of claim 18, wherein the digital signature uses an Elliptic Curve Digital Signature Protocol.

20. 20. The system of claim 18, wherein the genomic data is hashed before being input into the NIZK certificate.

21. The system described in claim 12, wherein the determination unit obtains the specific requirements published on a web page or on a blockchain.

22. 22. The system of claim 21, further comprising a key publishing unit for publishing an attestation key and a verification key, said attestation key and said verification key being output from said NIZK certificate.

Images