Source verification for selective disclosure attributes

Abstract

Some embodiments are directed to a system (100) for selectively disclosing attributes of a record. A publisher device (110) generates a digital signature on a message comprising attributes and a secret record identifier. The record, the secret record identifier, and the signature are provided to a selector device. The selector device (111) selectively discloses attributes of the record to a recipient device (112), thereby proving authenticity by means of zero-knowledge proof of knowledge of the signature on the attributes. The recipient device (112) verifies the proof with respect to the publisher's public key and the received attributes.

Description

Technical Field

[0001] This invention relates to a system for selectively disclosing recorded attributes (e.g., medical attributes). The invention also relates to publisher devices, selector devices, and receiver devices used in such a system. Furthermore, the invention relates to publisher methods, selector methods, and receiver methods corresponding to the respective devices. The invention also relates to a computer-readable storage medium. Background Technology

[0002] The use of medical data (such as genomic data) for medical research and treatment holds great promise in terms of potential applications, but it also carries significant risks regarding data privacy and security if not handled carefully. As medical data from an increasing number of individuals becomes available, the scope of medical research (e.g., to find better or more customized treatments) is expanding. Simultaneously, such medical research involves highly sensitive data, such as genotypic and / or phenotype data. In many cases, for example, data about many different patients may be used. Therefore, appropriate measures are needed to prevent unauthorized access to and modification of such data.

[0003] A known way to limit data exposure in medical research settings is through deidentification. For example, in known systems, medical data may be collected from one or more sources (e.g., data from various devices or medical trials) and stored on a central platform. Researchers may request medical data from patients with specific characteristics. Such data should be deidentified according to law and global standards. Therefore, the platform can select data about one or more patients; deidentify the data, for example, selecting a subset of medical data (e.g., phenotypic and genotypic data); and provide the deidentified data to the researchers.

[0004] More generally, deidentification (e.g., revising a record to provide sufficiently limited personal information in its specificity and detail so that it is no longer linked to its data object) is becoming increasingly common, driven by legislation such as the GDPR and medical standards such as the GA4GH beacon. For example, deidentified data can be used in medical research beyond genomics, but also in a variety of other application areas such as financial services and advertising. More generally, deidentification of records (e.g., those that do not contain personal information) can be considered a type of selective disclosure, such as allowing data providers to decide which parts of the record to share with recipients.

[0005] From the perspective of the recipient of de-identified data (e.g., a researcher receiving de-identified medical data about patients), the fact that the data is de-identified can introduce the risk of fraud or manipulation by malicious actors. Because de-identified data may not be linked to its original source, distinguishing between genuine data with a legitimate source and fake data without one can be difficult. Therefore, it is desirable to perform de-identification in such a way that the recipient (e.g., someone paying for the data or someone checking the data for regulatory purposes) can trust that the de-identified data is legitimate, for example, from a trustworthy source. For example, a problem arises when de-identified data is illegally copied. In particular, if the data has attached monetary value, for example, if researchers pay to access the data, there may be an incentive for such copying, such as artificially inflating the data volume. Because the data is de-identified, it is difficult to verify whether two records are truly different. Besides malicious intent, copied records may also occur due to errors, such as programming errors, operator errors, etc. It is expected that the recipient (e.g., the researcher) can verify this.

[0006] Further complicating matters is the difficulty in implementing authentication measures. For example, authentication labels associated with records can also simplify copying. Furthermore, such authentication labels need to be verifiable from the de-identified data, rather than from the complete record. Adding to the complexity, the ultimate recipient of the data (e.g., a researcher) may have direct contact with the data publisher. Typically, there is a selector, for example, a broker between the publisher and the recipient, who ensures the correct data is delivered to the correct researcher. However, this means that de-identification is preferably performed after the data has already been provided to the selector.

[0007] In reality, direct contact between the publisher and the receiver may be impossible. For example, the publisher might be an inactive or decommissioned organization or machine. A secure method for de-identifying data is desired, preferably independent of the data publisher, while still allowing verification by the data receiver.

[0008] US Patent Application US2012 / 303616 A1 discloses a method for anonymizing data from multiple data sources. The data sources include record identifiers that identify entries associated with the data, wherein the record identifiers are stored only by the data source. The data is collected by a central data aggregation module connected to the data sources. The record identifiers are received by an anonymization engine from a first data source; and a first anonymous identifier is generated using the anonymization engine to replace the record identifiers. If the anonymization engine has already anonymized the data, a graph is sent to a mapping module, wherein the graph includes a list of anonymous identifiers that have already been used to replace the record identifiers. The first anonymous identifier and first data associated with the first anonymous identifier are sent to the data aggregation module. Summary of the Invention

[0009] Ensuring authenticity can be performed using conventional techniques, such as sending requests to all originators of the data to digitally check out the de-identified data, demonstrating their approval. However, this is cumbersome, often expensive, and may or may not be possible, for example, if the originators are retired organizations or machines. Therefore, there is a need for better automated techniques to ensure the credibility of selectively disclosed records.

[0010] To address these and other issues, a system for selectively disclosing the attributes of a record, as defined in the claims, has been proposed. The system may include: a publisher device for providing the record to a selector device for selective disclosure; a selector device for selectively disclosing portions of the record to a receiver device; and a receiver device for selectively obtaining portions of the record.

[0011] The record may include one or more attributes. In selective disclosure, the selector device may determine one or more attributes to be disclosed as a subset of the one or more attributes, and one or more data entries to be disclosed as a subset of the plurality of data entries. The record may be a personal information record; for example, attributes may include information about a person. However, records including other types of sensitive information are also possible.

[0012] Attributes typically come from a predefined set; for example, if multiple records are processed by the system, each record can provide values ​​for the same set of attributes. For instance, one or more records might represent phenotypic information about a person, such as length, hair color, a diagnosis of a specific medical condition, etc. The values ​​of attributes for a particular record are usually fixed throughout the record's lifespan. Attributes are typically numbers, fixed-length strings for categorization, etc.

[0013] Various types of data can be linked to signatures. For example, data can represent portions of a person's genome represented by a record, such as single nucleotide polymorphisms (SNPs), encoded as data lines in a variant call format (VCF) file of genomic data.

[0014] To still allow for the selective disclosure of these two attributes in a secure manner, the inventors have designed a publisher device to generate digital signatures on the attributes using a publisher's private key, whose corresponding public key is known to the receiver device. It is well known that digital signatures on a message allow a person possessing the publisher's public key to determine that the message has been signed by a party holding the corresponding private key. In this case, the publisher device can generate digital signatures on one or more attributes, such as generating digital signatures on attributed messages that include one or more attributes.

[0015] Therefore, these digital signatures can allow the establishment of the authenticity of record attributes, such as their provenance. In this case, it is preferable to choose digital signatures that effectively allow so-called zero-knowledge proofs to be performed on them, as discussed later.

[0016] Therefore, the publisher device according to the embodiment can determine a secret record identifier, such as a randomly generated identifier specific to a particular record, and can include it in the attribute message and optionally in the data message for which it signs the record. The publisher device can then provide the record, the secret record identifier, and the digital signature to the selector device. The secret record identifier can thus be used to ensure that the corresponding digital signature corresponds to a single record provided by the publisher device.

[0017] When performing selective disclosure, the selector device can now provide the attributes to be disclosed along with their signature to the receiver device. However, the attribute message may also contain non-disclosed attributes, but the receiver device will generally still need those attributes to verify the signature. Furthermore, the signature contains the secret record identifier, so the receiver will generally need the secret record identifier to verify the signature. Therefore, if the receiver obtains a non-overlapping set of attributes from the same record in two different disclosures, the receiver can link these two different partial records to each other based on the secret record identifier. Alternatively, the receiver can use the secret record identifier to link its partial records to other partial records received by different receivers.

[0018] Furthermore, if attribute messages are deidentified, it becomes difficult for the receiver to verify whether any records have been copied. Interestingly, as described below, the secret record identifier can remain hidden from the receiver device. Instead, the selector device can be configured to determine the public record identifier based on the secret record identifier. The public record identifier can be provided to the receiver device along with the one or more attributes to be made public. For a given record to be made public, the public record identifier can be bijective with the secret record identifier; that is, if the corresponding secret record identifiers are equal, then the two public record identifiers are equal.

[0019] The inventor devised a method whereby the selector device uses zero-knowledge proofs to prove to the receiver that the provided value belongs to a single record signed by the publisher device. As known from cryptography, zero-knowledge proofs are a method by which one party (the prover) can prove to another party (the verifier) ​​that they know a value that satisfies certain properties. Interestingly, in zero-knowledge proofs, this is done without the prover disclosing the value to the verifier. For example, in a zero-knowledge proof, the verifier knows the public key and the prover can prove to the verifier that they know the private key corresponding to that public key without revealing the private key to the verifier.

[0020] In this scenario, the selector device can utilize the receiver device to perform zero-knowledge proofs, wherein the selector device proves knowledge of the secret record identifier, the digital signature on the attribute message, and the digital signature on the digital message. The selector device also proves that it possesses knowledge of the secret record identifier corresponding to the public record identifier.

[0021] In other words, the selector device typically does not disclose the secret record identifier or any digital signature to the receiver device, but instead proves that it knows the valid identifier and signature. Specific examples of efficiently constructing such proofs are provided below; however, it should be noted that general techniques are available in the literature that allow proofs of knowledge of data satisfying arbitrary relations, making it possible, in principle, to use any digital signature scheme and any general zero-knowledge proof system.

[0022] Regarding attributes, the selector device can prove that the digital signature on the attribute message is a digital signature on a message that includes at least one or more attributes to be disclosed and the secret record identifier. The receiver device can verify this portion of the proof regarding one or more attributes it has obtained from the selector device to determine the correctness of the received attributes. The selector device can also prove that the digital signature is signed using a private key corresponding to the publisher's public key, which the receiver can use to verify it. By executing this portion of the proof as a verifier, the receiver device can obtain a guarantee that the attributes it has obtained from the receiver device are indeed part of a record provided by the publisher device.

[0023] Interestingly, the selector device can choose a public table key and determine the public record identifier based on the secret record identifier and the public table key. For example, the selector device can generate table key pairs, such as a private table key and a corresponding public table key, to obtain the public table key. Interestingly, a private table key is not required. For example, the public table key can be used as a fixed point for IDs, an application that does not require a private key. Instead of generating table key pairs, the selector device can directly obtain the point in the corresponding group G or G1 to obtain the public table key without having to generate a private table key in the first place. For example, a phrase can be hashed to the point in the group and that phrase can be made public to the receiving device. One advantage of generating a random private key is that it reduces the chance of using the same public table key twice in error.

[0024] A public table key can be provided to the receiving device and used in zero-knowledge proofs to prove knowledge of the secret record identifier corresponding to the public record identifier and the public table key. The public table key allows the receiving device to control which records are made public and how they should be distinguishable from each other. A guarantee of equality of public record identifiers is given using the same table key if and only if the corresponding secret record identifiers are equal. However, public record identifiers calculated for different table keys will not be equal, regardless of whether the corresponding secret record identifiers are equal. In this way, the receiving device can verify a copy in a set of data it receives, but it still cannot compare the received data with data received in different contexts or by different receiving devices.

[0025] In embodiments, the publisher may compute a separate digital signature on the data message including the corresponding data entry, for example, one for each data entry. The publisher device according to embodiments may include a secret record identifier in the attribute message, or in one or more data messages for which it signs that record. This allows for the use of different signature schemes depending on the data type. However, it should be noted that this approach is optional, as data messages may be linked to records in other ways, for example, by including their hashes in the attributes.

[0026] Regarding the data entries, the selector device can prove that the digital signature on the data message is a digital signature on a message that includes the data entries to be disclosed and each includes the secret record identifier, for example, the respective messages each include a data entry and the second record identifier. The receiver device can verify this part of the proof regarding the data entries it has obtained from the selector device to determine their correctness. The selector device can also prove that the digital signature is signed using a private key corresponding to the publisher's public key, which the receiver can use to verify it. By executing this part of the proof as a verifier, the receiver device can obtain a guarantee that the data entries it has obtained from the receiver device are part of a record provided by the publisher device. In particular, the proof can guarantee that each of the digital signatures includes the secret record identifier and is therefore part of the same record provided by the publisher device; the receiver device may still not actually know the secret record identifier, which prevents linking between partial records obtained in different selective disclosures.

[0027] Therefore, a system is provided in which a selector device can provide the attributes of a record to a receiver device with improved privacy and / or authenticity guarantees. Furthermore, different devices are provided, each offering specific features contributing to various advantages. For example, the publisher device can determine a secret record identifier and include it in a corresponding digital signature used for the record. The digital signature preferably has a type that allows efficient zero-knowledge proofs to be performed thereon; examples of such are provided below, but any type of digital signature can be combined with a suitable zero-knowledge proof system. As another example, the selector and receiver devices can perform zero-knowledge proofs to determine to the receiver device that a selectively disclosed value belongs to a single record of the publisher device.

[0028] Due to the measures discussed, the receiving device can obtain a guarantee that the acquired attribute belongs to a single record provided by the publishing device. However, the receiving device is generally unaware of undisclosed attributes or data entries, or even how many data entries the record comprises. In particular, although portions of the record are linked by identifiers, these identifiers can be secret record identifiers unknown to the receiving device. The burden of performing this selective disclosure is removed from the publishing device, which may only need to provide its record to the selecting device once and may not need to be involved thereafter. The system can be particularly suitable for large and / or dynamic sets of data entries, as the selective disclosure of a subset of the multiple data entries typically involves computational and communication scaling in the number of disclosed data entries rather than the total number of data entries. For example, instead of disclosing the entire genome, only relevant portions can be disclosed, where the disclosure is scaled only in the number of relevant portions. Thus, an improved selective disclosure of portions of the record is provided.

[0029] In embodiments, the attributes of the record may include one or more phenotypic attributes about a person. Data entries for the record may include one or more genomic portions of the person. For example, the system may be a system for providing genomic data to researchers conducting medical research. Given the sensitivity of genomic data and also improving compliance with privacy regulations in various jurisdictions, deanonymization is important for such records; simultaneously, the number of genomic portions in the record may be large, for example, the record may include the entire sequence of the person's genome or a large portion thereof. In such cases, allowing selective disclosure of a subset of the set of genomic portions as described herein is particularly relevant, and therefore, the beneficial scaling features described herein are particularly relevant.

[0030] Various digital signature schemes can be used to sign the attribute messages and the data messages for the multiple data entries. As discussed earlier, in principle, any digital signature scheme can be used. Now, various particularly advantageous options are discussed.

[0031] Various embodiments are based on anonymous certificates. An anonymous certificate is, in the art, a way for a user to obtain authentication from a certificate issuer based on one or more of their attributes (e.g., the user's age and country of origin). A user can anonymously present a certificate to a third party to prove that he / she meets certain properties, such as being at least 18 years old, without revealing information that allows links back to the user. Attributes in anonymous certificate schemes are generally assumed to be numeric; other types of attributes can be encoded in various ways, for example, text attributes can be encoded as numeric attributes by applying a one-way function to text, etc.

[0032] Examples of such anonymous certificate schemes are disclosed, for example, in J. Camenisch et al., “Signatureschemes and anonymous credentials from bilinear maps” (Proceedings CRYPTO'04) (incorporated herein by reference within the scope of the description of the anonymous certificate schemes involved) and in J. Camenisch et al., “An Accumulator Based on Bilinear Maps and Efficient Revocation for AnonymousCredentials” (Proceedings PKC'09) (incorporated herein by reference within the scope of the description of the anonymous certificate schemes involved).

[0033] Interestingly, in this embodiment, the anonymous certificate can be repurposed for the system presented herein in the sense that the digital signature on the attribute message as presented herein includes an anonymous certificate signed using the publisher's private key. The anonymous certificate may have one or more attributes of the record and the secret record identifier as attributes. In fact, anonymous certificates are used "instead." Traditionally, users and publishers run a publishing protocol whereby the user obtains a certificate regarding attributes whose values ​​the publisher may not know; the user uses the published anonymous certificate when a third party requests proof of its nature. Conversely, in this case, no such publishing protocol is needed, and the publisher device can directly provide the certificate to the selector device. Unlike in the conventional case, where the selector device holding the certificate is typically an unrelated intermediary, for example, the selector device may hold different records about different entities, such as people it does not involve. The selector device can then selectively expose portions of these records and / or, at its own discretion, demonstrate or prove the nature of the attributes. Regardless of these differences, interestingly, anonymous certificates can still be used as building blocks in this system.

[0034] In some embodiments, the digital signature scheme used for the data message is the same as the digital signature scheme used for the attribute message. For example, the digital signature for a data entry can be an anonymous certificate having the secret record identifier and the data entry, or a one-way function applied to the data entry as an attribute. This results in a particularly simple design.

[0035] In various embodiments, the selector device acquires multiple records, such as multiple records from a single publisher device, multiple records from multiple publisher devices, etc. Therefore, the selector device can act as a system for providing access to the multiple records to a recipient device, for example, selecting and providing a centralized access point for data to a recipient (e.g., a medical researcher who wants to perform research on genomic data).

[0036] In an embodiment, the publisher device is configured to obtain a record query and select one or more records from a plurality of records to be disclosed based on the record query. For example, the receiver device may provide the record query or may otherwise determine the record query. Typically, the record query provides one or more conditions to be satisfied by the records. For example, the publisher device may select all records that satisfy the conditions, the top X records that satisfy the conditions, X random records that satisfy the conditions, and so on. For example, the conditions may be attribute-based conditions, such as stating that an attribute equals a specific value or another attribute, that the attribute is within a certain range, and so on. Conditions may also be data entry-based conditions, such as the existence of a data entry containing certain data, for example, a genome with a specific mutation. The publisher device can then selectively disclose attributes for each current record of the selected records, for example, by repeatedly determining the attributes to be disclosed, providing attributes for the current records, and performing zero-knowledge proofs for each current record of the one or more selected records. In this way, the receiver device can receive records relevant to its specific use.

[0037] In an embodiment, the selector device uses a zero-knowledge proof for the current record to prove to the receiver device that the current record satisfies the record query. For example, the record query may include conditions on attributes not provided to the receiver device, such as age > 65. The zero-knowledge proof can be used to prove that such conditions are maintained. It can also prove the properties of data entries not provided to the receiver device. Conditions relative to disclosed attributes generally do not need to be proven in zero-knowledge, as the receiver knows them. Proving the entire record query is also not strictly necessary; for example, for efficiency reasons, only the most relevant conditions of the record query can be proven. Interestingly, by means of zero-knowledge proofs, the receiver device can receive a guarantee that the records it receives satisfy the record query, such as age > 65, without knowing details, such as the exact age. Therefore, a particularly advantageous combination of data minimization and authenticity can be obtained.

[0038] In an embodiment, the selector device also receives, for example, a data entry query received from the receiver device or otherwise determined. The selector device can determine one or more data entries to be disclosed based on the data entry query. For example, the data entry query can specify one or more conditions for data entries to be met, or it can specify one or more specific data entries to be included, such as genomic data at a specific location. This allows control over which data entries are provided. Similar methods can be used to determine which attributes should be disclosed.

[0039] Of course, the use of record queries and / or data entry queries to control which records and / or portions of records are to be made public does not preclude the possibility that the selector device may perform checks on the data to be made public to the recipient device. For example, the selector device may perform checks to ensure that the attributes of the set of records to be made public to the recipient device satisfy certain data minimization properties (e.g., privacy properties such as k-anonymity).

[0040] In an embodiment, the zero-knowledge proof may involve the selector device providing the receiver device with a commitment to the secret record identifier and proving knowledge of the digital signature regarding the commitment. For example, the commitment may be a Pedersen-type commitment as known in the art. Providing a comment to the receiver device allows the receiver device to efficiently establish that the same secret record identifier is included in the corresponding digital signature by providing each of those digital signatures that includes the same secret record identifier as the comment.

[0041] In one embodiment, the zero-knowledge proof can be a non-interactive zero-knowledge proof determined and sent by the selector device and received and verified by the receiver device. This can reduce the required communication volume and / or allow data transmission when both parties are not online at the same time.

[0042] The techniques described in this article can be applied to a wide range of practical applications. Such applications include platforms for providing deanonymized datasets to researchers in medical or financial contexts, for example. Such platforms could be operated by numerous hospitals or external service providers. More generally, any type of application requiring the selective disclosure of portions of records (especially records containing flexible or large datasets of entries) can benefit from the techniques described in this article.

[0043] Embodiments of the method may be implemented on a computer as a computer-implemented method, or on dedicated hardware, or a combination of both. Executable code for embodiments of the method may be stored on a computer program product. Examples of computer program products include memory devices, optical storage devices, integrated circuits, servers, online software, etc. Preferably, the computer program product includes non-transient program code stored on a computer-readable medium for performing embodiments of the method when the program product is run on a computer.

[0044] In an embodiment, the computer program includes computer program code adapted to perform all steps of an embodiment of the method when the computer program is run on a computer. Preferably, the computer program is implemented on a computer-readable medium.

[0045] Another aspect of the invention provides a method for making the computer program available for download. This aspect is used when the computer program is uploaded to, for example, Apple's App Store, Google's Play Store, or Microsoft's Windows Store, and when the computer program is available for download from such stores. Attached Figure Description

[0046] Further details, aspects, and embodiments of the invention will be described by way of example only with reference to the accompanying drawings. Elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale. In the drawings, elements corresponding to those already described may have the same reference numerals. In the drawings:

[0047] - Figure 1a An example of a selectively public system that does not involve zero-knowledge proofs is illustrated schematically;

[0048] - Figure 1b An example of an embodiment of a selective disclosure system is illustrated schematically;

[0049] - Figure 2 An example of an embodiment of the publisher's device is illustrated schematically;

[0050] - Figure 3An example of an embodiment of the selector device is illustrated schematically;

[0051] - Figure 4 An example of an embodiment of the receiver device is illustrated schematically;

[0052] - Figure 5 An example of an embodiment of the publisher method is illustrated schematically;

[0053] - Figure 6 An example of an embodiment of the selector method is illustrated schematically;

[0054] - Figure 7 An example of an embodiment of the receiver method is illustrated schematically;

[0055] - Figure 8 A computer-readable medium having a writable portion including a computer program, according to an embodiment, is illustrated schematically.

[0056] - Figure 9 A representation of a processor system according to an embodiment is shown schematically.

[0057] List of reference numerals in the attached diagram:

[0058] 000, 100 Selective Disclosure System

[0059] 010, 110, 210 Publisher devices

[0060] 011, 111, 311 Selector Device

[0061] 012, 112, 412 Receiver equipment

[0062] Memory 130, 131, 132

[0063] Processors 140, 141, and 142

[0064] Network interfaces 150, 151, and 152

[0065] 160 Computer Networks

[0066] 070, 170, 270 Publisher's private key

[0067] 071, 171, 471 Publisher public key

[0068] Records 072, 172, 272, 372

[0069] 173, 273, 373 Secret Record Identifiers

[0070] 174, 374, 474 Zero-knowledge proofs

[0071] 175, 275, 375 Public Record Identifiers

[0072] Digital signature on the publicly disclosed attributes of 075

[0073] Digital signatures on attribute messages 180, 280, and 380

[0074] Attributes: 081-084, 181-184, 281-282, 381-384, 483-484

[0075] 241 Identifier Generation Unit

[0076] 242 Attribute Signature Unit

[0077] 341 Selection Unit

[0078] 342 Proof Unit

[0079] 441 Verification Unit

[0080] 800 Computer-readable media

[0081] 810 Writable portion

[0082] 820 Computer Program

[0083] 910 (one or more) integrated circuits

[0084] 920 processing unit

[0085] 922 memory

[0086] 924 Application-Specific Integrated Circuit

[0087] 926 Communication Components

[0088] 930 Interconnect

[0089] 940 processor system Detailed Implementation

[0090] Although the invention allows for many different forms of embodiments, one or more specific embodiments are shown in the accompanying drawings and will be described in detail herein. It should be understood that this disclosure is to be considered as exemplary of the principles of the invention and is not intended to limit the invention to the specific embodiments shown and described.

[0091] In the following description, for the purpose of understanding, the elements of the embodiments are described in operation. However, it will be apparent that the corresponding elements are arranged to perform the functions described as being performed by them.

[0092] Furthermore, the present invention is not limited to the embodiments, and the invention lies in each and every novel feature or combination of features described above or recited in mutually different dependent claims.

[0093] Figure 1a An example of a system 000 for selectively disclosing recorded attributes is shown, which does not use signatures or zero-knowledge proofs about the attributes as defined in the claims.

[0094] The figure illustrates a publisher device 010 that aims to enable a selector device 011 (e.g., a genomic platform) to selectively publish portions of record 072. The specific record 072 shown in the figure includes values ​​for a predefined set of attributes 081-082 (e.g., phenotype and / or genotype data). Publisher device 010 provides the record to selector device 011.

[0095] When the selector device 011 wants to selectively disclose a portion of record 011 to the receiver device 102, the selector device can select one or more of attributes 081-082, in this case attributes 083 and 084, to disclose to the receiver device 012. The receiver device 012 can receive the attributes 083 and 084 to be disclosed.

[0096] Although the steps up to this point provide selective disclosure—for example, only a portion of the record is obtained by the receiving device 012—authenticity is not yet provided. For instance, the receiving device 012 does not have assurance that the received attributes originated from a trusted publisher device 010, and / or that the received attributes belong to the same record (e.g., all referring to the same person). To obtain such assurance, a digital signature 075 can be used. In this example, the digital signature 075 can be a conventional signature, such as an RSA or ECDSA signature. The annotation S(X; Y) used in the diagram and throughout this specification can refer to a signature with the private key X on message Y. Upon disclosure, the publisher device 010 can provide the receiving device 012, for example, prompted by the selector device 011, with the digital signature 075 on the attributes to be disclosed, signed using the publisher's private key 070. The receiving device 012 can verify the digital signature 075 relative to the publisher's public key 071 corresponding to the publisher's private key 070. Digital signatures typically do not allow for message recovery; for example, the message is not derived from the signature, and instead the signature and message are verified together with the public key 071.

[0097] While the above system can provide authenticity guarantees for selective disclosure, it has the undesirable characteristic that publisher device 010 needs to be involved in each selective disclosure. This is cumbersome, often expensive, and sometimes impossible; for example, publisher device 010 or its organization may no longer exist. Therefore, the problem addressed below is how to perform selective disclosure in a way that leverages comparable authenticity guarantees but in a manner in which the publisher device does not need to be involved in the selective disclosure. Another problem is that dishonest or careless selector device 011 might duplicate some of the records disclosed to 012. For example, deidentified record 072 might be disclosed multiple times. After deidentification, device 012 cannot verify the duplication. Even if the two records are identical, this could be due to deidentification. In particular, when disclosing few attributes and / or involving a large number of records, two or more records may be perfectly identical. Removing such identical records distorts inferences that might be derived from the data. However, not removing duplicate records carries the same risk.

[0098] Figure 1b An example embodiment of a system 100 for selectively disclosing attributes of record 172 is illustrated schematically. System 100 may include publisher device 100, selector device 111, and / or receiver device 112.

[0099] Publisher device 110 can be used to provide record 172 to selector device 111 for selective disclosure. Publisher device 110 may include processor 130 and memory 140. Memory 140 may be used for data and / or instruction storage. For example, memory 140 may include software and / or data to which processor 130 is configured to operate. Memory 140 may also store publisher private key 170, which forms a public-private key pair with the corresponding publisher public key 171. Memory 140 may also store record 172. Record 172 may include one or more attributes 181-182. Two attributes are shown by way of example only. Processor 130 may be implemented as one or more processor circuits, such as a microprocessor, ASIC, FPGA, etc. Memory 140 may include computer program instructions executable by processor 130. Processor 130 may be configured together with memory 140 according to embodiments of the publisher device. Publisher device 110 may also include communication interface 150, which is arranged to communicate with other devices (particularly selector device 111). For example, a communication interface may include connectors, such as wired connectors (e.g., Ethernet connectors) or wireless connectors (e.g., antennas, such as Wi-Fi, 4G, or 5G antennas). A communication interface may also be a storage interface leading to internal or external data storage devices, keyboards, application programming interfaces (APIs), etc.

[0100] Publisher device 110 can be configured to determine secret record identifier 173. Publisher device 110 can also be configured to generate a digital signature 180 using publisher private key 170 on one or more attributes 181-182 and secret record identifier 173. For example, processor 130 can apply a signature algorithm to an attribute message that includes one or more attributes 181-182 and secret record identifier 173.

[0101] The publisher device 110 can be configured to provide the selector device 111 with a record 172, a secret record identifier 173, and a digital signature 180 on the attribute message.

[0102] As shown in and throughout the figure, S1(X;Y) can be used to refer to a digital signature signed on message Y (e.g., on an attribute message) using the private key X. Digital signatures typically do not require message recovery; for example, the digital signature can be verified using the public key corresponding to the private key along with the message.

[0103] Selector device 111 may be configured to selectively disclose attributes of record 172 to receiver device 112. Selector device 111 may include processor 131 and memory 141. Memory 141 may be used for data and / or instruction storage. For example, memory 141 may include software and / or data to which processor 131 is configured to operate. Memory 141 may also store record 172, secret record identifier 173, and digital signature 180 on attribute messages. Processor 131 may be implemented as one or more processor circuits, such as a microprocessor, ASIC, FPGA, etc. Memory 141 may include computer program instructions executable by processor 131. Processor 131 may be configured together with memory 141 according to embodiments of the selector device. Selector device 111 may also include a communication interface 151 arranged to communicate with other devices (particularly publisher device 110 and receiver device 112). For example, the communication interface may include a connector, such as a wired connector, such as an Ethernet connector, or a wireless connector, such as an antenna, such as a Wi-Fi, 4G, or 5G antenna. The communication interface can also be a storage interface that leads to internal or external data storage devices, keyboards, application interfaces (APIs), etc.

[0104] Selector device 111 can be configured to obtain the digital signature 180 on record 172, secret record identifier 173, and attribute message. Selector device 111 can be configured to verify digital signature 180 using publisher public key 171. This is not necessary because if signature 180 is incorrect, it will also be detected later when receiver device 112 verifies signature 180.

[0105] Selector device 111 can also be configured to determine one or more attributes to be disclosed as a subset of one or more attributes 181-182. By way of example only, the accompanying figure shows two attributes 183-184 to be disclosed. Selector device 111 can be configured to provide one or more attributes 183, 184 to be disclosed to receiver device 112.

[0106] Selector device 111 can also be configured to determine public record identifier 175 based on secret record identifier 173. The public record identifier is calculated from the secret record identifier in such a way that two corresponding public record identifiers are different if and only if they are different. Therefore, one can verify whether a deidentified record is a copy of some other deidentified record by comparing their public record identifiers.

[0107] Interestingly, the selector device can be configured to generate a public table key. Generating a public table key can also be done by generating a private table key, for example, in the form of a table key pair, but this is not required. The public table key is associated with a specific attribute table, such as one disclosed to the receiving device. It is possible that information from the same record may be disclosed to this or another receiving device on other occasions, and it is desirable to avoid the possibility of two disclosures being pieced together. For example, attributes 1 and 2 may be disclosed in a first disclosure to a first receiving device, and attributes 1 and 3 may be disclosed in a second disclosure to a second receiving device. If the two receiving devices collude somewhere, it is possible to reconstruct a record in which attributes 1, 2, and 3 are combined again. As a result, privacy may be compromised. This combination of records is particularly easy if the records have unique record identifiers. To avoid this possibility, a new table key can be selected for each disclosure of data that should be composable. The public record identifier can be determined based on the secret record identifier and the public table key. For example, determining the public record identifier may include applying a bilinear graph to, for example, the public table key and grouping points based on the secret record identifier.

[0108] The public table key can be provided to the receiving device. The effect of different table keys is that the same secret record identifier in two data disclosures will have different corresponding public record identifiers, thus avoiding the combination of data based on public record identifiers.

[0109] On the other hand, if it is expected that copies can be checked across different publics in certain circumstances, the table key can be omitted, or the same table key can be used in multiple publics.

[0110] The selector device 111 can also be configured to perform zero-knowledge proof 174 using the receiver device 112. Zero-knowledge proof is shown here as a message being sent from the selector device 111 to the receiver device 112, for example, a non-interactive zero-knowledge proof; however, this is not necessary. For example, a zero-knowledge proof may include multiple messages exchanged between the parties, for example, an interactive zero-knowledge proof.

[0111] As used in the accompanying drawings and throughout the specification, the annotation ZK(X;Y) refers to a zero-knowledge proof in which value X satisfies a specific property about value Y. For example, value X is included in the so-called witnesses of a zero-knowledge proof. The prover typically uses value X to perform the proof and the verifier typically uses value Y to verify the proof.

[0112] In zero-knowledge proofs, the selector device can prove knowledge of the following:

[0113] -Secret record identifier 173;

[0114] - The digital signature 180 on the attribute message is a digital signature on a message that includes at least one or more attributes 183-184 to be disclosed and a secret record identifier, which is signed using a private key corresponding to the publisher's public key 171.

[0115] Receiver device 112 may be configured to selectively obtain attributes 183-184 of record 172 from selector device 111. Receiver device 112 may include processor 132 and memory 142. Memory 142 may be used for data and / or instruction storage. For example, memory 142 may include software and / or data to which processor 132 is configured to operate. Memory 142 may also store publisher public key 171. Processor 132 may be implemented as one or more processor circuits, such as a microprocessor, ASIC, FPGA, etc. Memory 142 may include computer program instructions executable by processor 132. Processor 132 may be configured together with memory 142 according to embodiments of the receiver device. Receiver device 112 may also include a communication interface 152 arranged to communicate with other devices (particularly selector device 111). For example, the communication interface may include a connector, such as a wired connector, such as an Ethernet connector, or a wireless connector, such as an antenna, such as a Wi-Fi, 4G, or 5G antenna. The communication interface can also be a storage interface that leads to internal or external data storage devices, keyboards, application interfaces (APIs), etc.

[0116] Receiver device 112 can be configured to obtain one or more attributes 183-184 from selector device 111. Receiver device 112 can also be configured to perform zero-knowledge proofs using selector device 111 with respect to the obtained values ​​183-184 and the publisher's public key 174 to determine that the obtained values ​​183-184 belong to record 172 of publisher device 110.

[0117] Various devices in system 100 communicate with each other via computer network 160. The computer network can be the Internet, intranet, LAN, WLAN, etc. Computer network 160 can be the Internet. The computer network can be wholly or partially wired, and / or wholly or partially wireless. For example, the computer network can include Ethernet connections. For example, the computer network can include wireless connections such as Wi-Fi, ZigBee, etc. Computer network 160 can include additional components, such as routers and hubs.

[0118] The various devices in Figure 1 can have corresponding user interfaces, which may include known elements such as one or more buttons, a keyboard, a display, a touch screen, etc. For example, the user interface of receiver device 112 may be arranged to accommodate user interaction for obtaining a portion of the record that satisfies a specific record query.

[0119] Interestingly, system 100 achieves what system 000 cannot. The selector device 111 can de-identify a record, for example, by providing only a portion of the record to the receiver device 112. However, the receiver device can verify that the portion of the record it receives actually originates from the publisher device 110; that is, the receiver device can verify the authenticity and integrity of the received data. Furthermore, the receiver device 112 can verify whether some of the de-identified records are copies of each other by verifying whether any of the public record identifiers are duplicates or whether any of the public record identifiers cannot be verified using zero-knowledge proofs. Moreover, the publisher device 110 only needs to be involved at the moment it provides data to the selector device 111. No subsequent involvement from the publisher is required to prove authenticity, integrity, or absence of duplication to the receiver device 112.

[0120] Figure 2 The illustration schematically shows the provision of records to a selector device for selective disclosure (e.g., for...). Figure 1b An example of an embodiment of the publisher device 210 in system 100.

[0121] Figure 2 The functional units of what may be the processor of the publisher device 210 (not shown separately) are schematically illustrated. For example, Figure 2 It can be used as a blueprint for organizing the possible functions of a processor. For example, Figure 2The functional units shown (e.g., units 241-243) may be implemented, in whole or in part, in computer instructions stored at device 210 (e.g., in the electronic memory of device 210) and executable by the microprocessor of device 210. In a hybrid embodiment, the functional units are implemented partly in hardware (e.g., as a coprocessor) and partly in software stored and running on device 210. For illustrative purposes, Figure 2 Various elements that can be stored by the device 210 at various stages of its operation are also shown.

[0122] The attached figure shows record 272, which includes one or more attributes 281-282. For example, record 272 may be a genomic record. In this case, attributes 281-282 may include one or more of a person's phenotypic attributes, such as age, BMI, markers indicating a diagnosis of one or more medical conditions, etc. In this example, the attributes may be integers or other types of values ​​encoded as integers. Integers typically come from a range of 0, ..., N-1 defined by the signature scheme(s) used, for example, as described below.

[0123] Instead of directly encoding information into attributes, one can encode a hash of the information within the attribute. This works in the same way, except that if the information is included in the publicly disclosed portion of the attribute, then that information can be made public. The receiving device can then compute the hash from the information and verify that the signature was indeed computed on the correct hash. In this case, the hash is used as the publicly disclosed attribute.

[0124] An alternative approach to linking larger amounts of data is to include them in separate messages, such as data messages. The data messages can then be signed and linked to secret record identifiers. Zero-knowledge proofs can then be extended to prove that the signature on the data message is indeed linked to the secret record identifier corresponding to the public record identifier. This can be a signature S2 of a different type than the signature S1 used for attributes.

[0125] As an illustrative example, a large amount of data that can be conveniently included in either of the two methods described above is genomic information. For example, the data entry for record 272 could represent a single nucleotide polymorphism (SNP) in the human genome. For example, record 272 could be derived from or encoded by a variant call format (VCF) file. As is known in bioinformatics, VCF files can be used to store gene sequence variations with respect to a reference genome. Optionally, VCF files can also store phenotypic information. A portion of a VCF file is shown below:

[0126]

[0127] For example, for a record corresponding to a VCF file as illustrated above, the record's data entry can correspond to a line in the VCF file. For instance, a data entry could be a string representing a line in the VCF file. The hash of the VCF file can be included as an attribute. Alternatively, the VCF file can be signed and linked to a secret record identifier.

[0128] The figure also shows an identifier generation unit 241. Identifier generation unit 241 can generate a secret record identifier 273. Typically, the secret record identifier 273 is, for example, an integer from the same range 0,…,N-1 as attributes 281-282. Advantageously, the secret record identifier 273 is generated randomly based on a large domain, making it unpredictable to other devices and minimizing the probability of collisions between identifiers generated by other devices, for example. For example, identifier generation unit 241 can randomly generate the secret record identifier 273 based on at least 2… 30 At least 2 62 , or 2 126 One possible value generates the secret record identifier 273.

[0129] The publisher's private key 270 is also shown, which may be generated by the publisher device 210 or otherwise obtained. The publisher's private key 270 may be any kind of secret key compatible with the digital signature scheme used to generate the digital signature 280 discussed below.

[0130] Attribute signing unit 242 is also shown. Attribute signing unit 242 can generate a digital signature 280 on an attribute message using the publisher's private key 270. The attribute message may include one or more attributes 281-282 and a secret record identifier 273. As discussed elsewhere, although any signature scheme S1 can be used in principle, it is particularly advantageous that the digital signature 280 is an anonymous certificate; in other words, it is an algorithm for generating anonymous certificates for the purpose of signature generation. The secret record identifier 273 can be used as an attribute of the anonymous certificate.

[0131] As a specific example, the anonymous certificate scheme is as follows: Given an ordered list of attributes m, the signature can be a quadruple (c, s, γ, σ), where attribute signature unit 242 randomly generates values ​​c, s, and γ, and σ is calculated as:

[0132]

[0133] Where x is the secret key 273, and its associated public key y = h x Trusted by the receiving device. H may be a generator h of a set of prime numbers q in G. i And for Similar to h0. Here, γ273 is the secret record identifier, which is considered part of the signature in this notation. Interestingly, It may be a generator for group G used to include the secret record identifier γ into the signature. The proof can be adapted from the aforementioned articles "Signature schemes and anonymouscredentials from bilinear maps" and "An Accumulator Based on Bilinear Maps and Efficient Revocation for Anonymous Credentials".

[0134] The publisher device 210 may also provide the selector device with a record 272, a secret record identifier 273, and a digital signature 280 on the attribute message, for example, by sending them via a communication interface (not shown).

[0135] Although the signing process has been discussed so far with respect to a single record 272, the same units 241-243 can also be used to generate corresponding secret identifiers and signature sets for multiple records. Furthermore, the publisher device 210 can update the attributes of a record by having units 242, 243 appropriately determine the new attribute message signature. If separate data, such as genomic information, is used, this data can also be provided to the selector.

[0136] Figure 3 The illustration schematically shows the attributes for selectively exposing record 372 to the receiving device (e.g., for use in...). Figure 1b An example of an embodiment of the selector device 311 in system 100.

[0137] Figure 3 The functional units of a processor, which may be selected device 311 (not shown separately), are schematically illustrated. For example, Figure 3 It can be used as a blueprint for organizing the possible functions of a processor. For example, Figure 3 The functional units shown (e.g., units 341-342) may be implemented, in whole or in part, in computer instructions stored at device 311 (e.g., in the electronic memory of device 311) and executable by the microprocessor of device 311. In a hybrid embodiment, the functional units are implemented partly in hardware (e.g., as a coprocessor) and partly in software stored and running on device 311. For illustrative purposes, Figure 3 Various elements that can be stored by the device 311 at various stages of its operation are also shown.

[0138] The accompanying diagram illustrates a record 372 including one or more attributes 381-382; a secret record identifier 370; and a digital signature 380 on the attribute message generated using the publisher's private key, wherein the attribute message includes one or more attributes 381-382 and the secret record identifier 370. For example, the record, the secret record identifier, and the digital signature can correspond to... Figure 2 Those. For example, the data can be obtained from the publisher's device.

[0139] Selection unit 341 is also shown. Selection unit 341 can determine one or more attributes to be disclosed to the receiving device as a subset of one or more attributes 381-382. In this particular example, attributes 383 and 384 are selected. The attributes to be disclosed can be determined based on, for example, a data entry query provided by the receiving device, which may indicate specific data entries to be disclosed and / or criteria for selecting data entries, and similarly for attributes. Selection unit 341 can additionally perform selection based on criteria and / or checks not provided by the receiving device, such as a privacy policy provided by the publishing device along with the record.

[0140] For example, Record 372 may include personally identifiable information, such as data that could potentially be used to identify a specific person. Examples include full name, Social Security number, driver's license number, bank account number, passport number, and email address. Such information can be removed from Record 372 before the information is sent to the recipient's device. Record 372 may also include attributes that, while not directly personally identifiable, may be privacy-sensitive, such as age and weight. If such information is not needed, these attributes can be avoided from being sent to the receiving device.

[0141] Furthermore, proof unit 342 is shown. Proof unit 342 can perform zero-knowledge proof 374 using the receiver's device. As is known in cryptography and discussed elsewhere, zero-knowledge proofs are used to allow a prover to prove a statement to a verifier. Zero-knowledge proofs preferably satisfy the properties of integrity, robustness, and zero knowledge.

[0142] Completeness means that if the statement is true, a prover following the protocol will convince a validator following the protocol. Robustness means that if the statement is false, a fraudulent prover cannot convince a validator following the protocol. In the case of knowledge proofs, completeness may also mean that not only is the statement true, but the prover knows certain values ​​that occur in the statement, referred to as witnesses. Robustness is typically maintained until a certain robustness error occurs, at which point a fraudulent validator successfully convinces the validator; however, zero-knowledge proofs can include multiple instances of protocols that reduce robustness errors. Zero knowledge means that the validator has not learned any information from proofs other than the fact that the statement is true. Zero knowledge can be computational and / or statistical.

[0143] In this scenario, the selector device can use zero-knowledge proof 374 to prove knowledge of: secret record identifier 373; and a digital signature 380 on the attribute message as a digital signature on a message that includes at least one or more attributes 383, 384 to be disclosed and the secret record identifier 373, which is signed using a private key corresponding to the publisher's public key. In other words, the witnesses to a zero-knowledge proof can include the secret record identifier and the signature; the public values ​​proving its validity can include attributes 383, 384, and the publisher's public key.

[0144] Specifically, to prove that signature 380 includes secret record identifier 373 without disclosing the secret record identifier to the receiving device, proof unit 342 can construct a commitment to the secret record identifier (e.g., a Pedersen-type commitment) and provide it to the receiving device. Therefore, zero-knowledge proof 374 can prove that the same secret record identifier 373 is included in every signature and in the commitment. This can be an efficient way to prove the existence of a common secret identifier for various types of zero-knowledge proofs and signature schemes.

[0145] Many different types of zero-knowledge proofs are known in the field and can be readily applied, such as Σ-protocols like the Schnorr protocol; non-interactive zero-knowledge proofs obtained from interactive zero-knowledge protocols by means of the Fiat-Shamir heuristic; zero-knowledge concise non-interactive knowledge proofs (zk-SNARK), etc.

[0146] However, it is particularly advantageous to use a signature scheme S1 that allows for efficient proofs of knowledge, if it does not rely on genetic technology. For example, it can be beneficial to base signature scheme S1 on anonymous certificate schemes (e.g., the scheme of Camenisch et al. discussed above), because it allows efficient zero-knowledge proofs to be performed. For example, the use of signatures based on the principle of exponentiation of group elements is also particularly efficient, as this again allows for efficient zero-knowledge proofs.

[0147] The particularly advantageous implementation based on attribute signature 380 will now be discussed in detail. The Camenisch-Stadler notation, as described by J. Camenisch et al., “An Accumulator Based on Bilinear Maps and Efficient Revocation for Anonymous Credentials” (Proceedings PKC'09), is used. Attribute signature 380 can have the following form:

[0148]

[0149] It should be noted that zero-knowledge proofs are presented here as interactive proofs, but with the understanding that they can be made non-interactive, for example, using the Fiat-Shamir heuristic. The proof can also be extended to prove properties about attribute values, for example, to prove that a record satisfies a record query, such as 30 ≤ BMI ≤ 40. Proofs about multiple records can also be performed in parallel and / or combined into a single non-interactive zero-knowledge proof using known techniques.

[0150] In detail, in this example, it is shown that unit 342 can compute the public record identifier of record m. For example, it can choose a private table key a and compute the public table key K = h of that table. a For a specific table, the public / private table key pair may be unique. The public table key can also be chosen as a random point in G1 in other ways, such as by the coefficients of a randomly generated point, or by a hash phrase, such as a public phrase. For each row of the deidentified dataset, the creator can now generate a unique public record identifier ID, as follows: Furthermore, in this example, proof unit 342 can construct multiple commitments that can be submitted to the recipient device:

[0151] - For generators And a randomly generated value t, for the secret record identifier γ;

[0152] - And the randomly generated value; and

[0153] -

[0154] In the first part of the zero-knowledge proof, proof unit 342 can prove the following knowledge: signature 380, as a signature on a message including one or more attributes to be disclosed and a secret record identifier corresponding to the commitment X described above, and which utilizes the public key y = h x Use the private key x to sign. Set mult = ρc and tmp = open·c; the first part of the zero-knowledge proof can be used to prove:

[0155]

[0156] Here, It is the blinding of a signature σ with a random value p generated by the proof unit 342 and provided to the receiver device. Summing the publicly disclosed attributes, and Summing undisclosed attributes, optionally encoding them as hashes, etc.

[0157] In the second part of zero-knowledge proofs, it can be proven that the secret record identifier corresponds to the public record identifier, for example, by proving:

[0158]

[0159] The effect of a commitment is to blind the receiving device to the corresponding data, but to bind the selector device to a specific value in the underlying data. No public commitment is required. Above, 'e' is used to refer to a cryptographic pairing, for example, a type-3 elliptic curve pairing, such as a pairing on a 256-bit Barreto-Naehrig (BN) curve known in the art. A pairing on a BN curve can be formally referred to as: e(G1×G2)→G T The various generators used above (e.g., generators for H, import generators) (etc.) can be a generator of G1 generated in the nothing-up-my-sleeves method, for example, the basic generator of hash G1 until a point is encountered.

[0160] In other zero-knowledge proofs, it may be explicitly proven that:

[0161]

[0162] For example, it is possible to prove knowledge of the secret identifier in commitment X. Interestingly, but not necessarily, this is not required, as with the use of X in the second part of the zero-knowledge proof mentioned above. The above proof can be based, for example, on the Schnorr proof system disclosed in US patent application US4995082A. Interestingly, the above proof may deviate from Camenisch's zero-knowledge proof.

[0163] Although the above process has been discussed with regard to a single record, it will be understood that the selector device 311 can be readily adapted to situations where it stores multiple records and associated information (e.g., from multiple publisher devices). In this way, the selector device 311 can also selectively expose portions of multiple records. For example, as discussed elsewhere, the selector device 311 can obtain a record query and select one or more records from multiple records based on the record query. The steps performed by units 341 and 343 can be repeated for the corresponding selected record to perform selective exposure for the corresponding record.

[0164] Interestingly, zero-knowledge proofs for records can then be used to prove that the current record satisfies a record query. For example, a record query could include conditions on attributes, such as age > 65, 40 ≤ age < 65, etc. For instance, in the specific case of using an adjusted Camenisch anonymous certificate as signature 380, known techniques for proving the properties of attributes concerning such a certificate can be readily employed.

[0165] Figure 4 The illustration schematically shows the attributes used to selectively obtain records from the selector device (e.g., for...). Figure 1b An example of an embodiment of receiver device 412 in system 100.

[0166] Figure 4 The functional units of a processor, which may be a receiver device 412 (not shown separately), are schematically illustrated. For example, Figure 4 It can be used as a blueprint for organizing the possible functions of a processor. For example, Figure 4 The functional units shown (e.g., unit 441) may be implemented, in whole or in part, in computer instructions stored at device 412 (e.g., in the electronic memory of device 412) and executable by the microprocessor of device 412. In a hybrid embodiment, the functional units are implemented partly in hardware (e.g., as a coprocessor) and partly in software stored and running on device 412. For illustrative purposes, Figure 4 Various elements that can be stored by device 412 at various stages of its operation are also shown.

[0167] The figure shows the publisher's public key 471 stored in the memory of the receiver device 412. The authenticity of a portion of the record can be established relative to this public key. Attributes 483 and 484 of the record are also shown, two in this example. The receiver device 412 can receive this information from the selector device, as discussed elsewhere.

[0168] Verification unit 441 is also shown in the figure. Verification unit 441 can perform zero-knowledge proofs with respect to the obtained values ​​483, 484 and the publisher's public key 471 using the selector device. A non-interactive zero-knowledge proof 474 that verification unit 441 can verify non-interactively is shown here; however, the proof can also be interactive, for example, by generating a challenge and providing it to verification unit 441 on the selector device. As discussed from the prover's perspective, the proof can be with respect to the selector device 311. Proof 474 can determine that the obtained values ​​483-484 belong to a record of the publisher device corresponding to the publisher's public key 481. Therefore, the selector device can prove the following knowledge: a secret record identifier; a digital signature on a message including at least one or more attributes 483-484 to be disclosed and the secret record identifier, which is signed using the private key corresponding to the publisher's public key 471.

[0169] The verification of the zero-knowledge proof can be performed using a zero-knowledge proof system corresponding to the one used by the selector device to prove the above statements. In this particular example, the proof of the various parts discussed with respect to selector device 311 can be used as described above. For example, receiver device 412 can receive a commitment to the secret identifier from the selector device. As described above, the selector device can then prove knowledge of the secret record identifier and the signature on attributes 483-484, and verification unit 441 verifies this knowledge.

[0170] Although not explicitly shown in the accompanying drawings, as previously described, the selective disclosure technique as described herein can be applied to multiple records that may come from different publisher devices. In this case, verification unit 442 can repeat the above process for each disclosed record. The recipient device can also provide record queries to influence which records are obtained.

[0171] Therefore, through the various measures discussed above, the receiver device 412 can obtain the information it needs, such as attributes 483, 484 and appropriate authenticity guarantees regarding the public key 471, without needing to access other sensitive materials, such as undisclosed attributes, secret record identifiers, or the publisher's private key.

[0172] Verification unit 441 can also be configured to identify whether two or more of the received public record identifiers are duplicates. If receiver device 412 receives two deidentified records with the same public record identifier, calculated using the same public table key (if used), then the corresponding secret record identifiers are also equal. In this case, a warning may be generated and / or operation may be aborted.

[0173] Once verified, researchers can use publicly available attributes, but they do not access private attributes, such as privacy-sensitive information.

[0174] The following provides a summary of specific effective embodiments. However, it should be noted that zero-knowledge protocols can also be constructed for other types of signatures. In a specific embodiment:

[0175] The publisher may have the public key y=h x The private key x. Data can be represented as multiple records, for example, including attribute m. i A vector m. For each vector, a signature can be computed by randomly selecting values ​​c, s, and γ; the latter is a secret record identifier. Attribute signatures can have the following form:

[0176]

[0177] Where H is a set of generators h of a set of primes of order q in G. i , such as h, and The signature of vector m can be represented as a quadruple (c, s, γ, σ). The publisher provides the selector with vector m, the corresponding signature including the secret record identifier, and the public key y.

[0178] The selector can compute the public record identifier of vector m. For example, he can select a private table key a and compute the public table key K = h for that table. a The public / private table key pair may be unique for that specific table, for example, the one publicly disclosed to the recipient's device. For each record, the selector can now generate a unique public record identifier ID, as follows:

[0179] The selector forwards some of the attributes to the receiver, but not all, along with the public record identifier ID. To prove the source, the following protocol can be executed. The selector, such as proof unit 342, generates randomized blinded values ​​t, t, and open, and calculates the values ​​mult = ρc and tmp = open·c. Proof unit 342 constructs the following commitment that can be sent to the receiver's device:

[0180] -

[0181] - For generators And a randomly generated value t, for the secret record identifier γ;

[0182] -

[0183] Proof Unit 342 now allows the verifier to participate in zero-knowledge proofs of knowledge about the following values: c, s, u, ρ, t, open, mult, tmp, m1, ..., m n

[0184] The first part of a zero-knowledge proof can be used to prove:

[0185] 1.

[0186] 2.

[0187] 3.

[0188] Here, H1 corresponds to the public attribute, and H2 corresponds to the non-public attribute; together we get H1∪H2=H. Note that the attributes can optionally be encoded as hashes in proofs and / or signatures, etc. The latter is convenient if the attributes can be very large. Values ​​y, h, h i , It is likely public, and the values ​​ID, A, C, and X are also known to the prover and verifier. The value A is a blinded signature, which does not need to be verified independently because if A is blinded more than anything else, the proof does not work. Similarly, X does not need to be checked separately because it is included at the top of the third proof statement.

[0189] Surprisingly, the above proof can be precisely articulated as proving the knowledge of a series of exponents that together derive known values ​​from a known cardinality. This can be proven using the Schnorr protocol. A bilinear graph e can be, for example, a so-called type 1 bilinear graph or a type 3 bilinear graph, etc.

[0190] The system can be extended to individual signatures of data entries. For example, in an embodiment of a system (100) for selectively disclosing attributes, the record comprises multiple data entries. This extension is optional. The processor of the publisher device can be configured to generate multiple digital signatures on multiple data messages for multiple data entries using the publisher's private key, the data message for each data entry including the data entry and a secret record identifier. The digital signatures on the data messages are provided to the selector device. The processor of the selector device can be configured to determine that one or more data entries to be disclosed are a subset of the multiple data entries. Zero-knowledge proofs by the selector and receiver devices prove that the digital signature on the data message of the data entry to be disclosed is a digital signature on a message including the data entry to be disclosed and each containing a secret record identifier, which is signed using the private key corresponding to the publisher's public key. In an embodiment, the processor of the publisher device is configured to generate a digital signature on the data message by calculating the power of the reciprocal of the multiplication of the group element (g) with respect to the value (x+γ+H(m)), for example, (g 1 / (x+γ+H(m))The value is based at least on the publisher's private key (x), the secret record identifier (γ), and the data entry (m). However, other digital signatures may also be used.

[0191] Figure 5 An example embodiment of a publisher method 500 for providing records to a selector device for selective disclosure is illustrated schematically. Method 500 is typically implemented by a computer.

[0192] The publisher method 500 may include storing 510 a publisher private key, which forms a public-private key pair with the corresponding publisher public key; and a record that includes one or more attributes.

[0193] Publisher method 500 may include identifying the secret record identifier 520.

[0194] Publisher method 500 may include using the publisher's private key to generate a digital signature on a 530 attribute message, the attribute message including one or more attributes and a secret record identifier.

[0195] The publisher method 500 may include providing 550 a record, a secret record identifier, a digital signature on an attribute message, and a digital signature on a data message to the selector device.

[0196] Figure 6 An example embodiment of a selector method 600 for selectively exposing recorded attributes to a receiving device is illustrated schematically. Method 600 is typically implemented by a computer.

[0197] The selector method 600 may include: storing 610 records, including one or more attributes; a secret record identifier; a digital signature on an attribute message generated using the publisher's private key, the attribute message including one or more attributes and the secret record identifier; and a digital signature on a data message generated using the publisher's private key and the secret record identifier.

[0198] Selector method 600 may include obtaining 620 records, secret record identifiers, digital signatures on attribute messages, and digital signatures on data messages.

[0199] Selector method 600 may include determining one or more attributes to be exposed as a subset of one or more attributes 630.

[0200] Selector method 600 may include determining 635 public record identifier based on secret record identifier.

[0201] The selector method 600 may include providing the receiver device with one or more attributes to be disclosed 640.

[0202] The selector method 600 may include performing 650 zero-knowledge proofs using the receiver device, wherein knowledge of the following is proven:

[0203] -Secret record identifier;

[0204] A digital signature on an attribute message is a digital signature on a message that includes at least one or more attributes to be disclosed and a secret record identifier, and it is signed using a private key corresponding to the publisher's public key.

[0205] Figure 7 An example embodiment of a receiver method 700 for selectively obtaining recorded attributes from a selector device is illustrated schematically. Method 700 is typically implemented by a computer.

[0206] Receiver method 700 may include storing 710 the publisher's public key.

[0207] Receiver method 700 may include obtaining 720 or more attributes from selector device.

[0208] Receiver method 700 may include using a selector device to perform a 730 zero-knowledge proof regarding the obtained value and the publisher's public key to determine that the obtained value belongs to a record of the publisher device corresponding to the publisher's public key, wherein the selector device proves knowledge of the following:

[0209] -Secret record identifier;

[0210] - A digital signature on a message that includes at least one or more attributes to be disclosed and a secret record identifier, which is signed using a private key corresponding to the publisher's public key.

[0211] Many different ways of executing a method are possible, as will be apparent to those skilled in the art. For example, the order of steps can be changed, or some steps can be executed in parallel. Furthermore, other method steps can be inserted between steps. The inserted steps may represent a refinement of the method as described herein, or they may be unrelated to the method. For example, some steps may be executed at least partially in parallel. Moreover, a given step may not be fully completed before the next step begins.

[0212] Embodiments of the method can be executed using software, which includes instructions for causing a processor system to execute method 500, 600, or 700. The software may include only those steps taken by a specific sub-entity of the system. The software may be stored on a suitable storage medium, such as a hard disk, floppy disk, memory, optical disk, etc. The software may be transmitted as a signal along a wire, wirelessly, or using a data network (e.g., the Internet). The software may be available for download and / or for remote use on a server. Embodiments of the method can be executed using a bitstream arranged to configure programmable logic, such as a field-programmable gate array (FPGA), to execute the method.

[0213] It will be appreciated that the invention also extends to computer programs, particularly computer programs on or in a carrier suitable for practicing the invention. Programs may take the form of source code, object code, intermediate source code, and object code such as partially compiled form, or any other form suitable for embodiments of the methods. Embodiments relating to computer program products include computer-executable instructions corresponding to each processing step of at least one of the illustrated methods. These instructions may be subdivided into subroutines and / or stored in one or more files that may be statically or dynamically linked. Another embodiment relating to computer program products includes computer-executable instructions corresponding to each module of at least one of the illustrated systems and / or products.

[0214] Figure 8 A computer-readable medium 800 is shown having a writable component 810 including a computer program 820, which includes instructions for causing a processor system to perform a publisher method, selector method, or receiver method according to an embodiment. The computer program 820 may be implemented on the computer-readable medium 800 by means of physical markings or by means of magnetization of the computer-readable medium 800. However, any other suitable embodiments are conceivable. Furthermore, it will be appreciated that although the computer-readable medium 800 is shown herein as an optical disc, the computer-readable medium 800 may be any suitable computer-readable medium (such as a hard disk, solid-state storage, flash memory, etc.) and may be non-recordable or recordable. The computer program 820 includes instructions for causing a processor system to perform the methods.

[0215] Figure 9 A schematic representation of a processor system 940 according to an embodiment is shown. The processor system includes one or more integrated circuits 910. Figure 9The diagram schematically illustrates the architecture of one or more integrated circuits 910. Circuit 910 includes a processing unit 920 (e.g., a CPU) for running computer program components to perform methods according to embodiments and / or implement modules or units thereof. Circuit 910 includes a memory 922 for storing programming code, data, etc. A portion of the memory 922 may be read-only. Circuit 910 may include a communication element 926, such as an antenna, a connector, or both. Circuit 910 may include some or all of an application-specific integrated circuit 924 for performing some or all of the processes defined in the methods. The processor 920, memory 922, application-specific IC 924, and communication element 926 may be interconnected via an interconnection 930 (e.g., a bus). The processor system 910 may be arranged for contact and / or contactless communication using antennas and / or connectors, respectively.

[0216] For example, in one embodiment, the processor system 940 (e.g., a publisher device, a selector device, or a receiver device) may include processor circuitry and memory circuitry, with the processor arranged to run software stored in the memory circuitry. For example, the processor circuitry may be an Intel Core i7 processor, an ARM Cortex-R8, etc. In another embodiment, the processor circuitry may be an ARM Cortex M0. The memory circuitry may be ROM circuitry or non-volatile memory, such as flash memory. The memory cells may be volatile memory (e.g., SRAM memory). In the latter case, the device may include a non-volatile software interface (e.g., a hard disk drive, a network interface, etc.) arranged to provide the software.

[0217] Typically, each device includes a microprocessor that executes appropriate software stored on the device; for example, this software may have been downloaded and / or stored in a corresponding memory (e.g., volatile memory such as RAM or non-volatile memory such as flash memory). Alternatively, the device may be implemented wholly or partially as programmable logic, for example, as a field-programmable gate array (FPGA). The device may be implemented wholly or partially as a so-called application-specific integrated circuit (ASIC), i.e., an integrated circuit (IC) customized for its specific purpose. For example, the circuit may be implemented in CMOS, for example, using hardware description languages ​​such as Verilog, VHDL, etc.

[0218] In one embodiment, the publisher device includes an identifier generation circuit and an attribute signature circuit. In another embodiment, the selector device includes a selection circuit and a verification circuit. In yet another embodiment, the receiver device includes a verification circuit. The device may include additional circuitry. The circuitry implements the corresponding units described herein. The circuitry may be processor circuitry and storage circuitry, with the processor circuitry running instructions electronically represented in the storage circuitry. The processor circuitry may be implemented in a distributed manner, for example, as multiple sub-processor circuits. A portion of the storage device may be read-only. The circuitry may also be an FPGA, ASIC, etc. The storage device may be distributed across multiple distributed sub-storage devices. Part or all of the memory may be electronic memory, magnetic memory, etc. For example, the storage device may have volatile and non-volatile portions.

[0219] It should be noted that the embodiments mentioned above are illustrated but not intended to limit the invention, and those skilled in the art will be able to devise many alternative embodiments.

[0220] In the claims, any reference numerals within parentheses should not be construed as limiting the claims. The use of the verb "comprising" and its variations does not exclude the presence of elements or steps other than those recited in the claims. The words "a" or "an" preceding an element do not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In device claims enumerating several modules, several of these modules can be implemented by the same item of hardware. The mere fact that a particular measure is recited in different dependent claims does not indicate that combinations of these measures cannot be advantageously used.

[0221] In the claims, references enclosed in parentheses refer to reference numerals in the drawings of exemplary embodiments or formulas of embodiments, thereby increasing the comprehensibility of the claims. These references should not be construed as limiting the claims.

Claims

1. A system (100) for selectively disclosing attributes of a record (172), the system comprising a publisher device (110), a selector device (111), and a receiver device (112), The publisher device (110) is used to provide records to the selector device for selective disclosure, the publisher device comprising: Memory (130), which is configured to store: The publisher's private key (170) and the corresponding publisher's public key (171) form a public-private key pair; The record includes one or more attributes (181, 182); Processor (140), which is configured as follows: Identify the secret record identifier (173); A digital signature is generated using the publisher's private key on one or more of the attributes and the secret record identifier (180); The selector device is provided with the record, the secret record identifier, and the digital signature; The selector device (111) is used to selectively disclose the attributes of the record to the receiver device, the selector device comprising: Memory (131), which is configured to store: The record, the secret record identifier, and the digital signature; Processor (141), which is configured as follows: One or more attributes (183, 184) to be disclosed are determined to be a subset of the one or more attributes; The public record identifier (175) is determined based on the secret record identifier (173); Provide the recipient device with one or more attributes to be disclosed and the public record identifier; The receiver device is used to perform zero-knowledge proof (174), wherein the selector device proves knowledge of the following: The secret record identifier corresponds to the public record identifier; The digital signature generated by the publisher device on the one or more attributes and the secret record identifier serves as a digital signature on at least the one or more attributes to be disclosed and the secret record identifier, which is signed using a private key corresponding to the publisher's public key; The receiver device (112) is configured to selectively obtain the attribute of the record from the selector device, the receiver device comprising: A memory (132) configured to store the publisher's public key; Processor (142), which is configured as follows: The selector device obtains the one or more attributes to be disclosed and the public record identifier. The zero-knowledge proof is performed using the selector device on the obtained attribute and the publisher's public key to determine that the obtained attribute belongs to the record of the publisher device.

2. The system (100) according to claim 1, wherein, The attributes include one or more medical attributes about a person.

3. A selector device (111, 311) for selectively disclosing recorded attributes to a receiver device, the selector device comprising: Memory (131), which is configured to store: The record includes one or more attributes; a secret record identifier; and a digital signature generated using the publisher's private key on one or more of the attributes and the secret record identifier; Processor (141), which is configured as follows: Obtain the record, the secret record identifier, and the digital signature on the one or more attributes and the secret record identifier; One or more attributes (183, 184) to be disclosed are determined to be a subset of the one or more attributes; The public record identifier is determined based on the secret record identifier; Provide the recipient device with one or more attributes to be disclosed and the public record identifier; The receiver device is used to perform zero-knowledge proof (174), wherein the selector device proves knowledge of the following: The secret record identifier corresponds to the public record identifier; The digital signature generated using the publisher's private key on one or more attributes serves as a digital signature on at least one or more attributes to be disclosed and the secret record identifier, and is signed using a private key corresponding to the publisher's public key.

4. The selector device (111, 311) according to claim 3, wherein, The memory (131) is configured to store a plurality of records, and the processor (141) is configured to: The determination, the provision, and the execution of the zero-knowledge proof are repeated for one or more selected records from the plurality of records.

5. The selector device (111, 311) according to claim 4, wherein, The memory (131) is configured to store a plurality of records, and the processor (141) is configured to: Retrieve record query; Select one or more records from the plurality of records based on the record query.

6. The selector device (111, 311) according to claim 5, wherein, The processor (141) is configured to perform zero-knowledge proofs on records among the one or more selected records to further prove that the records satisfy the record query.

7. The selector device (111, 311) according to any one of claims 3-6, wherein, The processor (141) is configured to generate a public table key, the public record identifier being determined based on the secret record identifier and the public table key, the public table key being provided to the receiver device.

8. The selector device (111, 311) according to any one of claims 3-6, wherein, Performing the zero-knowledge proof includes providing the recipient device with a commitment to the secret record identifier and proving knowledge of the digital signature regarding the commitment.

9. A receiver device (112, 412) for selectively obtaining attributes of a record from a selector device, the receiver device comprising: A memory (132) is configured to store the publisher's public key; Processor (142), which is configured as follows: Obtain one or more attributes and public record identifiers to be disclosed from the selector device; The selector device performs zero-knowledge proofs on the obtained attributes and the publisher's public key to determine that the obtained attributes belong to the record of the publisher device corresponding to the publisher's public key, wherein the selector device proves knowledge of the following: The secret record identifier corresponds to the public record identifier; The digital signature on at least one or more of the attributes to be disclosed and the secret record identifier is signed using a private key corresponding to the publisher's public key.

10. The receiver device (112, 412) according to claim 9, wherein, The receiver device is configured to perform the zero-knowledge proof by obtaining a non-interactive zero-knowledge proof from the selector device and verifying the non-interactive zero-knowledge proof.

11. The receiver device (112, 412) according to any one of claims 9-10, wherein, Repeat the acquisition and execution process for multiple records.

12. The receiver device (112, 412) according to claim 11, wherein, The processor is configured to identify whether two or more public record identifiers among the received public record identifiers are duplicates.

13. A selector method (600) for selectively disclosing recorded attributes to a receiving device, the selector method comprising: Storage (610): The record includes one or more attributes; Secret record identifier; A digital signature generated using the publisher's private key on one or more of the attributes and the secret record identifier; Obtain (620) the record, the secret record identifier, and the digital signature; One or more attributes to be disclosed are determined (630) to be a subset of the one or more attributes; The public record identifier (635) is determined based on the secret record identifier; Provide the receiver device with (640) one or more attributes to be disclosed; The receiver device is used to perform (650) zero-knowledge proofs, wherein knowledge of the following is proven: The secret record identifier corresponds to the public record identifier; The digital signature generated using the publisher's private key on one or more attributes serves as a digital signature on at least one or more attributes to be disclosed and the secret record identifier, and is signed using a private key corresponding to the publisher's public key.

14. A receiver method (700) for selectively obtaining attributes of a record from a selector device, the receiver method comprising: Store (710) the publisher's public key; One or more attributes determined to be disclosed and a public record identifier are obtained from the selector device (720); Using the selector device, a (730) zero-knowledge proof is performed on the obtained attribute and the publisher public key to determine that the obtained attribute belongs to the record of the publisher device corresponding to the publisher public key, wherein the selector device proves knowledge of the following: The secret record identifier corresponds to the public record identifier; The digital signature on at least one or more of the attributes to be disclosed and the secret record identifier is signed using a private key corresponding to the publisher's public key.

15. A computer-readable storage medium (800) comprising transient or non-transient data (820), said transient or non-transient data representing instructions for causing a processor system to perform the method according to any one of claims 13 to 14.

Images