Method for implementing a transaction between a first piece of evidence equipment and a second piece of verification equipment.

Abstract

The present invention relates to a method for implementing a transaction between a first piece of equipment (1) called proof equipment, and a second piece of equipment (2) called verification equipment, comprising the implementation of the following steps: Generation, by data processing means (11) of the first piece of equipment (1), of general parameters and public and private keys of a zero-knowledge proof protocol of type Σ-protocol, linked to said transaction, and transmission to said second piece of equipment (2) of the general parameters and the public key but not the private key; Verification, by data processing means (21) of the second piece of equipment (2), of the knowledge of said private key by the first piece of equipment (1) as a function of said general parameters and public key, said verification comprising the implementation (b2, b3, b4) of said Σ-protocol.If the knowledge of said private key by the first device (1) is verified, said transaction is implemented by said second device (2); The process being characterized in that said step (b) comprises, before the implementation (b2, b3, b4) of said Σ-protocol, the prior transmission (b1) to the first device (1) of a commitment value and a challenge value of said Σ-protocol. [Fig. 1].

Description

Title of the invention: Method for implementing a transaction between a first proof device and a second verification device. [0001 ] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of cryptography. More specifically, it relates to a method for implementing a transaction between a first proof device and a second verification device, using a deniable zero-knowledge disclosure proof.

[0003] STATE OF THE ART

[0004] Cryptographic processes known as zero knowledge proof (ZKP) are increasingly being used in transactions, by which a first so-called proof entity (the "prover") can prove knowledge to a second so-called verification entity (the "verifier") of a secret s without sharing this secret or any common private key a priori.

[0005] This is very useful for many transactions, particularly authentication or identification: instead of providing candidate biometric data to the verification entity (which poses a problem in terms of privacy), the prover can itself make the comparison between this candidate biometric data and a reference biometric data, and transmit to the verification entity proof of the result of the comparison, which would not disclose the biometric data.

[0006] Another use case is that of a transaction in the medical field, in particular for a prescription: instead of providing their health insurance card and therefore revealing their identity (which poses a problem in terms of medical confidentiality, for example for a prescription for a withdrawal product), the prover (patient) can provide the verifier (a prescriber) with proof that they are entitled to treatment, which would not reveal their identity.

[0007] In other applications, the prover can similarly prove, with the same constraints on reliability: - Possession of an identity document without providing it; - Making a payment without providing banking information - A right to access a product, service or place while remaining anonymous; - Etc.

[0008] The problem that arises, however, is that of trust in the proof. It is indeed necessary to propose a means so that the verification entity in charge of the control can verify that the result is correct and that the user has not committed any fraud or error in the action he is claiming (for example the comparison of biometric data).

[0009] "Interactive" ZKPs have been proposed (we then speak of ZKIP for Zero Knowledge Interactive Proof), in which the proof and verification entities exchange information so that the latter can ensure the reliability of the proof.

[0010] One method for constructing ZKPs uses so-called S-protocols (so named because of the three-way communication that is reminiscent of the Greek letter Sigma). An S-protocol (or sigma protocol) is an interactive protocol between a prover and a verifier involving three exchanges: • The commitment (or the “pledge”) which is a first message x sent by the prover to the verifier; • The challenge c (or challenge), which is a question sent by the verifier; • The answer y, which is the last message sent by the prover y, allows us to answer the question c with respect to the commitment x.

[0011] Multiple proofs without knowledge disclosure rely on this construction, for example the Fiat-Shamir, Schnorr, or Guillou-Quisquater protocols which will be discussed later. Note that RSA can even be used as an S-protocol.

[0012] Understanding the prior art and the invention requires recalling the concept of “commitment function” (the French term “de mise en gage” is also used to designate this concept).

[0013] In cryptology, pledge is a process that allows a person to "pledge" a value (or statement) while keeping it hidden from others, with the possibility of revealing this value later by proving that it was indeed the value that was pledged. The pledge is designed so that the person is bound to the pledged value.

[0014] In practice, pledging is done by calculating a pledge value from the value that one wants to hide and communicating this pledge value to a recipient. Subsequently, when the originally hidden value is communicated to the recipient, the latter will be able to verify that the value that was revealed to him is indeed the value that was used to calculate the pledge value. More formally, pledging transforms a value m into a pair (c, d) such that: • 1) c does not reveal any information about m, but that, • 2) together, c and d allow us to reveal m, and that • 3) it is impossible to find such that (c, d') reveals m' m.

[0015] In practice, in many scenarios, it is possible simply to communicate as a commitment a hash H(m) (or cryptographic fingerprint - for a given hash function) because revealing m allows anyone to subsequently recalculate H(m). This practice, however, suffers from a weakness: if the entropy of m is low, an attacker could find m by exhaustive search from H(m). For example, if m is a word in everyday French, an exhaustive search of the 32,000 words in everyday French will reveal m. In order to protect against such an attack, it is usual to commit to H(mlr) where r is a large random number (for example, 160 bits) and then to reveal, when opening the commitment, the data m and r. We generically denote by Eng(m) a commitment on a message m, with a possible random number r. The verification of Eng(m) will be generically denoted by Ouvre(m, Eng(m)). The procedure Ouvre returns a boolean depending on whether the opening was successful or not.

[0016] Most current ZKPs are based on algorithms that integrate difficult problems from number theory, such as factorization or discrete logarithm computation. Designed in 1987, the Fiat-Shamir protocol (see application US4748668) is the precursor of almost all modern ZKPs, and concerns the proof of knowledge of a private key sk = {sb ..., sk] without revealing it. According to the Fiat-Shamir protocol, each prover also has a public key pk = {n, e, vi, ..., vk}. The number n = pq is the product of two large prime numbers. The private key sk = {si, ..., sk] is defined by the relation Siev; =1 mod n and is derived from the prime factors of n. The random variables used to generate these parameters and keys are provided randomly.

[0017] To prove its knowledge of sk, the prover generates from SS a random number r and sends to the verifier a commitment x = r mod n.

[0018] The verifier replies with a random challenge c composed of k digits c = Cilc2l.. .Ick in base e (in other words 0 < c; < e-1). c is also generated randomly.

[0019] The prover replies with answer n

[0020] The verifier verifies knowledge of the secret sk using the test v mod n

[0021] Indeed, we have: rntpf =(rn^n^ =

[0022] All the data used in these calculations are presented in the form of large numbers.

[0023] Often the value taken for e is 2 but other integer values ​​of e can be used.

[0024] The Fiat-Shamir protocol gives rise to numerous variants and optimizations known to those skilled in the art. These variants make it possible in particular to reduce the size of x or v; or to reduce k by repeating the protocol t times in order to reach a level security level of 2 *. The security level expresses the probability that an entity not knowing sk can still pass the protocol and convince the verifier that it holds sk.

[0025] Most ZKPs rely on such an S-protocol (i.e. a similar three-pass (or more) exchange protocol as explained before) consisting of successively exchanging the data x, c, y between the parties. The definition of these x, c, y varies depending on the underlying hard problem of the ZKP security but the three-pass communication scheme remains the same.

[0026] However, it is known that S-protocols have a drawback due to their interactivity: if the verifier behaves dishonestly, it can keep track of its interaction with the prover and thus no longer allow the latter to "deny" the interaction, while such deniability is particularly desirable in many scenarios. To reformulate, the ZKP must be deniable so that the traces collected by the verifier cannot prove the prover's involvement: these traces must be able to have been generated without the help of the prover. Otherwise, the proof is not completely zero-knowledge.

[0027] To return to the example of the anonymous medical prescription, the patient may wish to leave no evidence of the interaction with the doctor and be able to deny such interactions in the future. If the ZKP is not deniable, a doctor wishing to fraudulently collect evidence of the interaction with the patient's health insurance card could achieve this.

[0028] Indeed, the verifier can derive the challenge c from H(x), for example by drawing the digits c; constituting c from H(x), instead of choosing them randomly. The answer y produced by the prover would then not be deniable because it demonstrates the prover's participation in the S-protocol, unless they could have been generated otherwise.

[0029] It can be shown that the probability Pk(w) that a verifier investing a workload w (expressed in number of hash operations) can falsely claim that the prover participated in the session (i.e. that the traces were generated without the intervention of the prover) is Pk(w) = 1-(1-

[0030] As soon as k (the size of the private key in bits) is large (for example k = 80), the number of operations w necessary to reach a probability of k? is excessive (280 operations). We therefore conclude that it is impossible that the traces could have been generated without the intervention of the prover, and therefore the ZKP is not deniable.

[0031] Unfortunately, the Applicant found that the verifier could also achieve this even for lower values ​​of k (e.g. 20).

[0032] To do this, it simply needs to derive from the hash function H an artificially slowed down hash function H' (so as to increase the workload). To slow down the function H', the verifier could, for example, iterate H over its input u times, for a sufficiently large value of u. In other words H'(x) = H(H(H(H(H.. .(H(x)))...). The calculation time of H' is thus slowed down by a factor of u (since u times more hashing operations must be performed).

[0033] As a numerical application, let u = 240 and k = 40, the number of operations w necessary to reach a probability Pk(w) of V2 (we repeat that this is the probability that a verifier can falsely claim that the prover participated in a session, i.e. generated the traces without intervention of the prover) is w = 7.6xlOnxu 2395xu = 279 5 which is still unrealizable although k is twice as small. The proof is therefore not deniable

[0034] Even with k = 20, taking u = 245, the number of operations w necessary to reach a probability Pk(w) of V2 is w = 726817u 219 5xu=264 5 hash operations, which, again, remains an excessive effort clearly tying the prover to the trace.

[0035] The present invention improves the situation. PRESENTATION OF THE INVENTION

[0036] The present invention therefore relates, according to a first aspect, to a method for implementing a transaction between a first piece of equipment, called proof equipment, and a second piece of equipment, called verification equipment, comprising the implementation of steps of: a. Generation, by data processing means of the first piece of equipment, of general parameters and public and private keys of a zero-knowledge proof protocol of S-protocol type, linked to said transaction, and transmission to said second piece of equipment of the general parameters and the public key but not the private key; b. Verification, by data processing means of the second equipment, of the knowledge of said private key by the first equipment as a function of said general parameters and public key, said verification comprising the implementation of said S-protocol. c. If the knowledge of said private key by the first equipment is verified, implementation of said transaction by said second equipment;

[0037] The method being characterized in that said step (b) comprises, before the implementation (b2, b3, b4) of said S-protocol, the prior transmission (bl) to the first equipment of a commitment value of a challenge value of said S-protocol.

[0038] According to advantageous and non-limiting characteristics:

[0039] Said step (b) comprises, during the implementation of said S-protocol, the reception (b2) from the first equipment, of a commitment value of the S-protocol, the transmission (b3) to the first equipment of said challenge value of said S-protocol, the transmission (b4) from the first equipment of a response value of said S- protocol, and the verification (b5) of the consistency of said commitment value of said 2-protocol, challenge value of said S-protocol, response value of said S-protocol, and public key.

[0040] Said response value of said S-protocol is calculated by the data processing means of the first equipment as a function of at least said challenge value and said private key.

[0041] Step (b) comprises, after the transmission (b3) of said challenge value of said S-protocol, the verification (b 3') by the data processing means of the first equipment that said challenge value corresponds to the engagement value of said challenge value previously received.

[0042] The transmission (b4) of the response value of said S-protocol is conditioned on the result of the verification (b 3' ) that said challenge value corresponds to the commitment value of said previously received challenge value.

[0043] The prior transmission (bl) of the commitment value of the challenge value of said S-protocol is conditional on the transmission to said second equipment of a request for deniability of said zero-knowledge disclosure proof.

[0044] The commitment value of the challenge value is a cryptographic fingerprint of said challenge value according to a given hash function.

[0045] The commitment value of said S-protocol and / or the challenge value of said S-protocol is a value derived from a randomly generated value, respectively by the data processing means of the first equipment or the second equipment.

[0046] Said S-protocol is chosen from the Fiat-Shamir protocol, the Guillou-Quisquater protocol, the Schnorr protocol and the RSA protocol.

[0047] The challenge size is between 10 and 160 bits.

[0048] According to a second aspect, the invention relates to a set of a first terminal, called prover, and a second terminal, called verifier, respectively comprising data processing means, characterized in that: - The data processing means of the first equipment are configured to • generate general parameters and public and private keys of a type 2 zero-knowledge proof protocol, linked to a transaction to be implemented between the first terminal and the second terminal, and • transmit to said second device the general parameters and the public key but not the private key; - The data processing means of the second equipment are configured to: • verify the knowledge of said private key by the first equipment according to said general parameters and public key, said verification comprising the implementation of said S-protocol; • If the knowledge of said private key by the first device is verified, implement said transaction; - The data processing means of the second equipment being further configured to, before the implementation of said S-protocol, previously transmit to the first equipment 1 a commitment value of a challenge value of said S-protocol.

[0049] According to a third and a fourth aspect, the invention relates to a computer program product comprising code instructions for the execution of a method according to the first aspect for the implementation of a transaction between a first so-called proof equipment, and a second so-called verification equipment; and a storage means readable by a computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to the first aspect for the implementation of a transaction between a first so-called proof equipment, and a second so-called verification equipment. PRESENTATION OF FIGURES

[0050] Other characteristics and advantages of the present invention will appear on reading the following description of a preferred embodiment. This description will be given with reference to the appended drawings in which:

[0051] [Fig.l] [Fig.l] is a diagram of a system for implementing the method according to the invention;

[0052] [Fig.2] [Fig.2] is a flowchart illustrating the steps of an embodiment of the method according to the invention;

[0053] [Fig.3] [Fig.3] schematically represents the implementation of a mode of rea implementation of step (b) of the authentication process in the system of [Fig.l]. DETAILED DESCRIPTION

[0054] Architecture

[0055] With reference to [Fig.l], a system for implementing the present method of processing a transaction is schematically represented.

[0056] The system comprises at least two pieces of equipment 1, 2. The first piece of equipment 1, called proof equipment, is advantageously a piece of equipment personal to an individual, such as for example their mobile telephone, such as a smartphone, an electronic tablet or even a personal computer, or even directly a chip card (in particular a payment card or a health card such as care vitale), and generally a customer piece of equipment via which the user wishes to initiate the transaction.

[0057] The second equipment 2, called verification equipment, is owned and controlled by an entity with whom the transaction must be carried out. Its nature depends on the desired transaction; it may be an EFT, a banking server, an access control device, a card reader, etc.

[0058] By "transaction" is meant in the broad sense any exchange in which the proof entity 1 requires the implementation of an action by the verification entity 2 in exchange for data, or at least information on said data, which is preferably personal data that one does not wish to publish (information linked to identity or rights, banking information, sensitive information, etc.).

[0059] The transaction is thus advantageously an authentication or an identification of an individual holding the first equipment 1 with the second equipment 2 (on the basis of an identity document or biometric data in particular) but also a financial transaction between the equipments 1 and 2 (payment by card for example directly at the merchant, or online, but also transfer, blockchain, etc.), an access control of the holder of the first equipment 1 to a product, a service or a place controlled by the second equipment 2, etc. In our example of the doctor and the patient, the personal data is medical data and the transaction is the issuance of a prescription.

[0060] It will nevertheless be understood that the present method is not limited to any particular transaction.

[0061] In all cases it is the second device 2 which implements the transaction (or rejects it) for example by implementing a software action (such as opening a session) or physical action (such as opening a door).

[0062] Conventionally, said data necessary for the transaction would be transmitted to the second device 2, and it is the latter which would verify it, and would accept the implementation of the transaction if the result of the verification is conclusive.

[0063] In the present context of zero-knowledge proof, the first device 1 will keep said data secret.

[0064] The first equipment 1 and the second equipment 2 comprise data processing means 11, 21, i.e. a computer such as for example a processor, a microprocessor, a controller, a microcontroller, an FPGA etc. These computers are adapted to execute code instructions to implement the method below.

[0065] The first equipment 1 and / or the second equipment 2 may also comprise data storage means 12, 22 (a memory, for example flash) possibly a user interface (typically a touch screen), etc.

[0066] Note that the first and second devices 1, 2 can be directly connected (case of a card in the reader), but also remotely (the second equipment 2 may be a remote server), via a network 20 such as the Internet network, as shown in [Fig.l].

[0067] Method

[0068] With reference to [Fig.2], the present method, implemented by the data processing means 11, 21 of the two equipments 1, 2 acting interactively, conventionally begins with a step (a) of generation, by the data processing means 11 of the first equipment 1, of general parameters and public and private keys (denoted respectively {par, pk, sk}) of a zero-knowledge proof protocol of S-protocol type, necessary for said transaction, sk (or data derived therefrom) constitutes a secret whose possession will be proven. In the remainder of this description, sk will be considered for convenience as being said secret.

[0069] Advantageously, in step (a) the first device sets the security level by defining the size k of the keys (we recall that the security level expresses the probability that an entity not knowing sk can still pass the protocol and convince the verifier that it holds sk). We will typically take for k a value between 20 and 80 bits, the security level then being 2 k. As we will see, the present method will allow the proof to be reliable whatever k (even for large values).

[0070] Step (a) further comprises the transmission to said second device 2 of the general parameters and the public key but not of the private key of course.

[0071] Asymmetric cryptography defines these two keys: a public key "pk" known to all (in particular to the second device 2) and a private key "sk" kept confidential (by the first device 1). This property is also true for ZKPs.

[0072] In a known manner, the production of an interactive proof with zero knowledge disclosure comprises two phases: a phase of generation of keys and parameters (which corresponds to step (a), and which is well known to those skilled in the art) and an interaction phase (which corresponds to step (b) which will be described later, and which is original).

[0073] The key and parameter generation algorithm allows said first device to generate the keys pk and sk and the parameters necessary for the operation of the ZKP. This algorithm is assumed to be accessible to all and public. The following phase allows said second device 2 to prove knowledge of the secret sk without revealing it. This algorithm is also assumed to be accessible to all and public.

[0074] Said zero-knowledge proof protocol is of the S-protocol type as mentioned above. We can cite the Fiat-Shamir protocol, but also the Guillou-Quisquater protocol, the Schnorr protocol, in particular, implemented on an elliptic curve, etc. Said S-protocol can alternatively be an RSA signature. A person skilled in the art can use any known S-protocol.

[0075] It is understood that said general parameters and public and private keys are linked to said transaction, i.e. their generation is specific to said targeted transaction and to the personal data involved.

[0076] As a classic example, the private key can allow the first device 2 to sign descriptive data of the transaction, and the holder of the second device 2 will be able to convince himself that the holder of the first device 1 does indeed have this private key without knowing his identity.

[0077] It is repeated that this step (a) may be implemented in any way known to those skilled in the art, depending on the type of proof considered and the type of transaction envisaged. The present method is distinguished in fact by a trick during the subsequent interaction phase which makes the proof perfectly deniable, and which those skilled in the art will know how to apply to any S-protocol and to any transaction.

[0078] Thus, the method then comprises the main step (b) shown in [Fig. 3] of verification, by the data processing means 21 of the second equipment 2, of the knowledge of said private key by the first equipment 1 as a function of said general parameters and public key, said verification comprising the implementation (b2, b3, b4) of said S-protocol.

[0079] We note that the verification itself is indeed done (and concluded) on the second equipment side, but that the S-protocol itself is interactive and therefore involves both equipment 1 and 2.

[0080] By S-protocol is meant, as explained, an interactive protocol known to those skilled in the art involving three exchanges: commitment, challenge and response. To reformulate, step (b) comprises a plurality of sub-steps, three of which (b2), (b3) and (b4) are the three exchanges of the S-protocol.

[0081] In other words, said step (b) comprises, during the implementation of said S-protocol: - reception (b2) from the first equipment 1, of a commitment value of the S-protocol (noted x), - the transmission (b3) to the first equipment 1 of a challenge value of said S-protocol (noted c), - the transmission (b4) from the first equipment 1 of a response value of said S-protocol (noted y).

[0082] Furthermore, step (b) comprises the verification (b5), by the processing means 21 of the second equipment 2, of the consistency of said commitment value of said S-protocol, challenge value of said S-protocol, response value of said S-protocol, and public key. In other words, it is a matter of verifying the response value y received with respect to the other values ​​already obtained (x, c, pk, par), generally by applying a formula (dependent on the S-protocol) to x, c, pk, by, and checking that we find y. We understand that this step is determined by the S-protocol, and we will see examples later.

[0083] If said consistency is verified, then the proof is verified, i.e. the second device is convinced of the knowledge of said private key by the first device 1. In other words, the knowledge of said private key by the first device 1 is verified if the consistency of said commitment value of said S-protocol, challenge value of said S-protocol, response value of said S-protocol, and public key is verified.

[0084] Sub-steps (b2), (b3), (b4) and (b5) may be implemented in a conventional manner.

[0085] In particular, the commitment value x of said S-protocol and / or the challenge value c of said S-protocol is preferably a value derived from a randomly generated value (still preferably each of the two), potentially directly a randomly generated value (in particular the challenge c - the commitment value is generally derived from a random value r), respectively by the data processing means 11, 21 of the first equipment 1 or of the second equipment 2. The size of the challenge is generally between 10 and 160, in particular between 60 and 100 or even around 80, preferably a size similar to the size k of the secret key, so as to guarantee a good compromise between calculation time and security.

[0086] Similarly, said response value of said S-protocol is preferentially calculated (in sub-step (b4), prior to its transmission) by the data processing means 11 of the first equipment 1 as a function of at least said challenge value and said private key, in accordance with said S-protocol.

[0087] As explained, the problem is that we want to ensure that the challenge value c is indeed generated randomly, or at least not as a function of said commitment value x.

[0088] To do this, the present method proposes to force the second device 2 to generate it before receiving the commitment value x.

[0089] In this respect, said step (b) comprises, before the implementation (b2, b3, b4) of said S-protocol, a sub-step (bl) implemented by the data processing means 21 of the second equipment 2, the prior transmission to the first equipment 1 of an engagement value (denoted Eng(c)) of a challenge value of said S-protocol.

[0090] The commitment value x of the S-protocol should not be confused with this commitment value Eng(c) of the challenge value c (which is not part of the S-protocol). The idea is that this commitment value of the challenge value does not reveal the challenge value, but makes it possible to ensure that the challenge value has indeed been generated at this stage, i.e. before (b2), and therefore not as a function of the commitment value x. Preferably, the commitment value of the challenge value is simply a cryptographic fingerprint of said challenge value according to a given hash function, i.e. Eng(c) = H(c).

[0091] We recall that by "cryptographic fingerprint" of a data (also called "condensate" or "hashed" of the data, from the English "hash"), obtained by applying a cryptographic hash function to the data (typically SHA-1 or SHA-2 families, in particular SHA-256). The fingerprint has a fixed size and reveals nothing about the data from which it comes: we cannot find the original data from this fingerprint, in any case as long as the hash function used is considered secure. We can however recalculate the fingerprint from the data to check that it is correct.

[0092] Thus, preferably, the sub-step (bl) comprises the prior generation (preferably randomly) of the challenge value c of said S-protocol, then the generation of said commitment value Eng(c) of this challenge value c (in particular by hashing this challenge value), always implemented by the data processing means 21 of the second equipment 2.

[0093] By comparison, this generation of the challenge value c of said S-protocol was traditionally implemented during the S-protocol, i.e. in sub-step (b3). Sub-step (b2) can, on the other hand, always comprise the prior generation (preferably always by deriving it from a randomly generated random value r) of the commitment value x of said S-protocol.

[0094] Preferably, step (b) comprises, after the transmission (b3) of said challenge value of said S-protocol, a sub-step (b3') of verification by the data processing means 11 of the first equipment 1 that said challenge value c corresponds to (in the sense is consistent with) the commitment value Eng(c) of said challenge value previously received.

[0095] It is only a matter of implementing a procedure Open(c, Eng(c)) as mentioned in the introduction, i.e. the verification of c which was received in sub-step (b3) knowing Eng(c) previously received.

[0096] This verification is typically done by recalculating Eng(c) from c, and comparing it to the value received in sub-step (bl), which is the expected value. In the case of a hash function, this simply involves calculating the cryptographic fingerprint of the received challenge value c.

[0097] Consequently, the transmission (b4) of the response value of said S-protocol can be conditioned on the result of the verification (b3') that said challenge value corresponds to (in the sense is consistent with) the commitment value of said previously received challenge value.

[0098] In other words:

[0099]

[0100] - if the first equipment 1 finds that said challenge value c corresponds to the commitment value Eng(c) of said previously received challenge value, then it has the assurance that the second equipment 2 is honest and that the proof will be deniable, and therefore it implements sub-step (b4) so ​​as to respond to the challenge; - if on the contrary the first equipment 1 notes that said challenge value (which will then be noted c') does not correspond to the commitment value Eng(c) of said previously received challenge value, i.e. a new challenge value c' c has been transmitted to which a commitment value Eng(c') Eng(c) corresponds, the first equipment 1 may suspect fraud (potential change during the course of the challenge value so as to base itself on x to prevent deniability) and interrupt the process by not responding to the challenge (no implementation of sub-step (b4) - note that the response y can still be generated but not transmitted). According to a first example conforming to the Fiat-Shamir protocol (where following step (a) the public key pk = {n, e, vb ..., vk] and the private key sk = {Si, ..., sk] is defined s;ev; = 1 mod n, the number n = pq being the product of two large prime numbers), step (b) preferably comprises the following sub-steps: • (bl) the means 21 of the second equipment 2 generate a random challenge c composed of k digits c = cklc2L..Ick in base e (in other words 0 < c; < e-1), prepare a commitment on c noted Eng(c) and transmit Eng(c) to the first equipment 1. • (b2) the means 11 of the first equipment 1 generate a random number r and transmit to the second equipment 2 an engagement value x=re mod n. • (b3) the second equipment 2 replicates with c (already generated). • (b3 ' ) the means 11 of the first equipment 1 check the consistency between c and Eng(c). If Eng(c) is not a valid commitment on c, the first device 1 aborts the protocol. • (b4) If Eng(c) is a valid commitment on c, means 21 of the first equipment 1 transmits the response to the verifier k mod n (b5) the means 21 of the second equipment 2 verify the knowledge of the secret sk by the first equipment 1 thanks to the test '' ,v9 mod n • According to a second example conforming to the RSA protocol (where following step (a) the public key pk = {n, E] and the private key sk = D), step (b) preferably comprises the following sub-steps: • (bl) the means 21 of the second equipment 2 generate a random challenge c, prepare an engagement on c noted Eng(c) and transmit Eng(c) to the first equipment 1. • (b2) the means 11 of the first equipment 1 generate a random number r and transmit to the second equipment 2 the engagement value r. • (b3) the second equipment 2 replicates with c (already generated). • (b3 ' ) the means 11 of the first equipment 1 check the consistency between c and Eng(c). If Eng(c) is not a valid commitment on c, the first device 1 aborts the protocol. • (b4) If Eng(c) is a valid commitment on c, means 21 of the first equipment 1 transmits to the verifier the response y = {yB y2} = {r, (r®c)D mod n} • (b5) the means 21 of the second equipment 2 verify the knowledge of the secret sk by the first device 1 using the test yi®c = y2E mod n. Note that the operator ® (“exclusive or” or XOR) can be replaced by a variety of other functions allowing r and c to be combined.

[0101] It is noted that in all cases the prior transmission (bl) of the commitment value of the challenge value of said S-protocol may itself be conditioned on the transmission to said second equipment 2 may be conditioned on a request for deniability of said zero-knowledge proof. In other words, the first equipment 1 may transmit to the second equipment 2 (for example at the end of step (a), in particular with general parameters and the public key) such a request for deniability of the zero-knowledge proof so as to force the second equipment 2 to adapt (and to act in accordance with the present method).

[0102] If such a request is issued, then the second equipment 2 must implement step (bl) of the prior transmission of the commitment value of a challenge value of said S-protocol. If it does not do so, the first equipment 1 may consider that the second equipment is dishonest (risk that it generates c as a function of x) and refuse to continue.

[0103] If such a request is not issued (i.e. the first device does not care more than that about reliability and accepts the risk of leaving traces), step (b) can be implemented in a conventional manner (generation of c implemented during the S-protocol, i.e. in sub-step (b3)).

[0104] Alternatively, it may be provided that sub-step (bl) is implemented by default (i.e. all the time without necessarily waiting for a request).

[0105] Finally, in a final step (c), the method comprises, if the knowledge of said private key by the first equipment 1 is verified, the implementation of said transaction by said second equipment 2. In other words, the data processing means 21 command an action corresponding to the transaction, such that opening a session or a door.

[0106] Conversely, if the knowledge of said private key by the first device 1 is not verified (for example if the response received from the S-protocol is not consistent), then on the contrary the transaction is rejected.

[0107] Among the numerous advantages provided by the present invention, we can mention that: - The verifier acquires the certainty that the prover has the secret sk but cannot collect any proof of its interaction with the latter; - The zero-knowledge proof protocol according to the invention is particularly optimized and efficient since the algorithms implemented within the framework of the invention require few operations to memorize and execute the two steps (a) and (b) thus combining high execution performance and preservation of the storage capacities of the first and second devices 1, 2. In addition, the number of code instructions necessary to carry out the invention in software or the number of logic gates necessary to carry out the invention in hardware are very low. Similarly, the necessary bandwidth is very low; - Finally, the present method is perfectly compatible with known S-protocol type zero-knowledge proof protocols and is added as a top layer on top of them.

[0108] Equipment

[0109] According to a second aspect, the invention relates to the assembly of the first and second equipment 1, 2 for implementing the method according to the first aspect.

[0110] The first equipment 1 and the second equipment 2 respectively comprise data processing means 11, 21 and data storage means 12, 22.

[0111] The data processing means 11 of the first equipment 1 are configured to • generate general parameters and public and private keys of a zero-knowledge proof protocol of type S-protocol, linked to a transaction to be implemented between the first terminal 1 and the second terminal 2, and • transmit to said second device 2 the general parameters and the public key but not the private key.

[0112] The data processing means 21 of the second equipment 1 are configured to: verify the knowledge of said private key by the first device 1 in function of said general parameters and public key, said verification comprising the implementation of said S-protocol (i.e. the means 21 are configured to implement the S-protocol); • If the knowledge of said private key by the first device 1 is verified, implement said transaction; and • before implementing said S-protocol, transmit in advance to the first device 1 a commitment value of a challenge value of said 2-protocol.

[0113] Computer program product

[0114] According to a third and a fourth aspect, the invention relates to a computer program product comprising code instructions for the execution (on the data processing means 11, 21 of the equipments 1, 2) of a method according to the first aspect for the implementation of a transaction between a first equipment 1 called proof equipment, and a second equipment 2 called verification equipment; and a storage means (for example the data storage means 12, 22 of the equipments 1, 2) on which this computer program product is found.

Claims

Claims

1. Method for implementing a transaction between a first piece of equipment (1) called proof equipment, and a second piece of equipment (2) called verification equipment, comprising the implementation of steps of: a. Generation, by data processing means (11) of the first equipment (1), of general parameters and public and private keys of a zero-knowledge proof protocol of S-protocol type, linked to said transaction, and transmission to said second equipment (2) of the general parameters and the public key but not the private key; b. Verification, by data processing means (21) of the second equipment (2), of the knowledge of said private key by the first equipment (1) as a function of said general parameters and public key, said verification comprising the implementation (b2, b3, b4) of said S-protocol. c. If the knowledge of said private key by the first equipment (1) is verified, implementation of said transaction by said second equipment (2);

2.

3. The method being characterized in that said step (b) comprises, before the implementation (b2, b3, b4) of said S-protocol, the prior transmission (bl) to the first equipment (1) of a commitment value of a challenge value of said S-protocol. Method according to claim 1, wherein said step (b) comprises, when implementing said S-protocol, receiving (b2) from the first equipment (1), a commitment value of the S-protocol, transmitting (b3) to the first equipment (1) said challenge value of said S-protocol, transmitting (b4) from the first equipment (1) a response value of said S-protocol, and verifying (b5) the consistency of said commitment value of said S-protocol, challenge value of said S-protocol, response value of said S-protocol, and public key. Method according to claim 2, wherein said response value of said S-protocol is calculated by the data processing means (11) of the first equipment (1) as a function of at least said value of challenge and said private key.

4. Method according to one of claims 2 and 3, in which step (b) comprises after the transmission (b3) of said challenge value of said 2-protocol, the verification (b3') by the data processing means (11) of the first equipment (1) that said challenge value corresponds to the commitment value of said previously received challenge value.

5. Method according to claim 4, in which the transmission (b4) of the response value of said S-protocol is conditioned on the result of the verification (b3') that said challenge value corresponds to the commitment value of said previously received challenge value

6. Method according to one of claims 1 to 5, in which the prior transmission (bl) of the commitment value of the challenge value of said 2-protocol is conditioned on the transmission to said second equipment (2) of a request for deniability of said zero-knowledge disclosure proof.

7. Method according to one of claims 1 to 7, in which the commitment value of the challenge value is a cryptographic fingerprint of said challenge value according to a given hash function.

8. Method according to one of claims 1 to 7, wherein the commitment value of said S-protocol and / or the challenge value of said 2-protocol is a value derived from a randomly generated value, respectively by the data processing means (11, 21) of the first equipment (1) or of the second equipment (2).

9. Method according to one of claims 1 to 8, wherein said 2-protocol is chosen from the Fiat-Shamir protocol, the Guillou-Quisquater protocol, the Schnorr protocol and an RSA-based protocol.

10. Method according to one of claims 1 to 8, in which the size of the challenge is between 10 and 160 bits.

11. Set of a first terminal (1), called prover, and a second terminal (2), called verifier, respectively comprising data processing means (11, 21), characterized in that: - The data processing means (11) of the first equipment (1) are configured to • generate general parameters and public and private keys of a zero-knowledge proof protocol of S-protocol type, linked to a transaction to be implemented between the first terminal (1) and the second terminal (2), and • transmit to said second equipment (2) the general parameters and the public key but not the private key; - The data processing means (21) of the second equipment (2) are configured to: • verify the knowledge of said private key by the first equipment (1) as a function of said general parameters and public key, said verification comprising the implementation of said S-protocol; • If the knowledge of said private key by the first equipment (1) is verified, implement said transaction; - The data processing means (21) of the second equipment (2) being further configured to, before the implementation of said S-protocol, previously transmit to the first equipment 1 a commitment value of a challenge value of said S-protocol.

12. Computer program product comprising code instructions for the execution of a method according to one of claims 1 to 10 for the implementation of a transaction between a first device (1) called proof, and a second device (2) called verification, when said program is executed on a computer.

13. Storage means readable by computer equipment on which is recorded a computer program product comprising code instructions for the execution of a method according to one of claims 1 to 10 for the implementation of a transaction between a first equipment (1) called proof, and a second equipment (2) called verification.

Images