Legally Fair Contract Signing Without Keystones

Abstract

In two-party computation, achieving both fairness and guaranteed output delivery is well known to be impossible. Despite this limitation, many approaches provide solutions of practical interest by weakening somewhat the fairness requirement. Such approaches fall roughly in three categories: “gradual release” schemes assume that the aggrieved party can eventually reconstruct the missing information; “optimistic schemes” assume a trusted third party arbitrator that can restore fairness in case of litigation; and “concurrent” or “legally fair” schemes in which a breach of fairness is compensated by the aggrieved party having a digitally signed cheque from the other party (called the keystone).

In this paper we describe and analyse a new contract signing paradigm that doesn’t require keystones to achieve legal fairness, and give a concrete construction based on Schnorr signatures which is compatible with standard Schnorr signatures and provably secure.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

When mutually distrustful parties wish to compute some joint function of their private inputs, they require a certain number of security properties to hold for that computation:

• Privacy: Nothing is learnt from the protocol besides the output;

• Correctness: The output is distributed according to the prescribed functionality;

• Independence: One party cannot make their inputs depend on the other parties’ inputs;

• Delivery: An adversary cannot prevent the honest parties from successfully computing the functionality;

• Fairness: If one party receives output then so do all.

Any multi-party computation can be securely computed [4, 6, 14, 15, 24] as long as there is a honest majority [20]. In the case where there is no such majority, and in particular in the two-party case, it is (in general¹) impossible to achieve both fairness and guaranteed output delivery [8, 20].

Weakening Fairness. To circumvent this limitation, several authors have put forth alternatives to fairness that try and capture the practical context (e.g. contract-signing, bank transactions, etc.). Three main directions have been explored:

• 1. Gradual release models: The output is not revealed all at once, but rather released gradually (e.g. bit per bit) so that, if an abort occurs, then the adversary has not learnt much more about the output than the honest party. This solution is unsatisfactory because it is expensive and may not work if the adversary is more computationally powerful [11, 16, 17, 22].

• 2. Optimistic models: A trusted server is setup but will not be contacted unless fairness is breached. The server is able to restore fairness afterwards, and this approach can be efficient, but the infrastructure requirements and the condition that the server be trusted limit the applicability of this solution [2, 5, 21]. In particular, the dispute-resolving third party must be endowed with functions beyond those usually required of a normal certification authority.

• 3. Legally fair, or concurrent model: The first party to receive output obtains an information dubbed the “keystone”. The keystone by itself gives nothing and so if the first party aborts after receiving it, no damage has been done – if the second party aborts after receiving the result (say, a signature) then the first party is left with a useless keystone. But, as observed in [7] for the signature to be enforced, it needs to be presented to a court of law, and legally fair signing protocols are designed so that this signature and the keystone give enough information to reconstruct the missing data. Therefore, if the cheating party wishes to enforce its signed contract in a court of law, it by doing so reveal the signature that the first party should receive, thereby restoring fairness [7]. Legal fairness requires neither a trusted arbitrator nor a high degree of interaction between parties.

Lindell [20] also introduces a notion of “legally enforceable fairness” that sits between legal fairness and optimistic models: a trusted authority may force a cheating party to act in some fashion, should their cheating be attested. In this case the keystone consists in a digitally signed cheque for an frighteningly high amount of money that the cheating party would have to pay if the protocol were to be aborted prematurely and the signature abused.

Concurrent Signatures. Chen et al. [7] proposed a legally fair signature scheme based on ring signatures [1, 23] and designated verifier signatures [19], that is proven secure in the Random Oracle Model assuming the hardness of computing discrete logarithms.

Concurrent signatures rely on a property shared by ring and designated verifier signatures called “ambiguity”. In the case of two-party ring signatures, one cannot say which of the two parties produced the signature – since either of two parties could have produced such an ambiguous signature, both parties can deny having produced it. However, within the ring, if A receives a signature then she knows that it is B who sent it. The idea is to put the ambiguity-lifting information in a “keystone”. When that keystone is made public, both signatures become simultaneously binding.

Concurrent signatures schemes can achieve legal fairness depending on the context. However their construction is not abuse-free [3, 10]: the party A holding the keystone can always determine whether to complete or abort the exchange of signatures, and can demonstrate this by showing an outside party the signature from B with the keystone, before revealing the keystone to B.

Our Results. In this work we describe a new contract signing protocol that achieves legal fairness and abuse-freeness. This protocol is based on the well-known Schnorr signature protocol, and produces signatures compatible with standard Schnorr signatures. For this reason, and as we demonstrate, the new contract signing protocol is provably secure in the random oracle model under the hardness assumption of solving the discrete logarithm problem. Our construction can be adapted to other DLP schemes, such as most² of those enumerated in [18], including Girault-Poupard-Stern [12] and ElGamal [9].

2 Preliminaries

We assume the reader to be familiar with Schnorr signatures, that we recall in the appendix in the IACR ePrint version of this paper.

2.1 Concurrent Signatures

Let us give a more formal account of legal fairness as described in [7, 20] in terms of concurrent signatures. Unlike classical contract-signing protocol, whereby contractors would exchange full-fledged signatures (e.g. [13]), in a concurrent signature protocol there are “ambiguous” signatures that do not, as such, bind their author. This ambiguity can later be lifted by revealing some additional information: the “keystone”. When the keystone is made public, both signatures become simultaneously binding.

Let $\mathcal M$ be a message space. Let $\mathcal K$ be the keystone space and $\mathcal F$ be the keystone fix space.

Definition 1

(Concurrent signature). A concurrent signature is composed of the following algorithms:

• $\mathsf {Setup}(\ell )$: Takes a security parameter $\ell$ as input and outputs the public keys $(y_A, y_B)$ of all participants, a function $\mathsf {KeyGen}:\mathcal K \rightarrow \mathcal F$, and public parameters $\mathsf {pp}$ describing the choices of $\mathcal M, \mathcal K, \mathcal F$ and $\mathsf {KeyGen}$.

• $\mathsf {aSign}(y_i, y_j, x_i, h_2, M)$: Takes as input the public keys $y_1$ and $y_2$, the private key $x_i$ corresponding to $y_i$, an element $h_2 \in \mathcal F$ and some message $M \in \mathcal M$; and outputs an “ambiguous signature”

  $$\begin{aligned} \sigma = \langle s, h_1, h_2\rangle \end{aligned}$$

  where $s \in \mathcal S, h_1, h_2 \in \mathcal F$.

• $\mathsf {aVerify}(\sigma , y_i, y_j, M)$: Takes as input an ambiguous signature $\sigma = \langle s, h_1, h_2 \rangle$, public keys $y_i$ and $y_j$, a message M; and outputs a boolean value, with the constraint that

  $$\begin{aligned} \mathsf {aVerify}\left( \sigma ', y_j, y_i, M\right) = \mathsf {aVerify}\left( \sigma , y_i, y_j, M\right) \end{aligned}$$

  where $\sigma ' = \langle s, h_2, h_1\rangle$.

• $\mathsf {Verify}(k, \sigma , y_i, y_j, M)$: Takes as input $k \in \mathcal K$ and $\sigma , y_i, y_j, M$ as above; and checks whether $\mathsf {KeyGen}(k) = h_2$: If not it terminates with output $\mathsf {False}$, otherwise it outputs the result of $\mathsf {aVerify}(\sigma , y_i, y_j, M)$.

A valid concurrent signature is a tuple $\langle k, \sigma , y_i, y_j, M \rangle$ that is accepted by the $\mathsf {Verify}$ algorithm. Concurrent signatures are used by two parties A and B in the following way:

• 1. A and B run $\mathsf {Setup}$ to determine the public parameters of the scheme. We assume that A’s public and private keys are $y_A$ and $x_A$, and B’s public and private keys are $y_B$ and $x_B$.

• 2. Without loss of generality, we assume that A initiates the conversation. A picks a random keystone $k \in \mathcal K$, and computes $f= \mathsf {KeyGen}(k)$. A takes her own public key $y_A$ and B’s public key $y_B$ and picks a message $M_A \in \mathcal M$ to sign. A then computes her ambiguous signature to be

  $$\begin{aligned} \sigma _A = \langle s_A, h_A, f \rangle = \mathsf {aSign}(y_A, y_B, x_A, f, M_A). \end{aligned}$$

• 3. Upon receiving A’s ambiguous signature $\sigma _A$, B verifies the signature by checking that

  $$\begin{aligned} \mathsf {aVerify}(s_A, h_A, f, y_A, y_B, M_A) = \mathsf {True} \end{aligned}$$

  If this equality does not hold, then B aborts. Otherwise B picks a message $M_B \in \mathcal M$ to sign and computes his ambiguous signature

  $$\begin{aligned} \sigma _B = \langle s_B, h_B, f \rangle = \mathsf {aSign}(y_B, y_A, x_B, f, M_B) \end{aligned}$$

  then sends this back to A. Note that B uses the same value f in his signature as A did to produce $\sigma _A$.

• 4. Upon receiving B’s signature $\sigma _B$, A verifies that

  $$\begin{aligned} \mathsf {aVerify}(s_B, h_B, f, y_B, y_A, M_B) = \mathsf {True} \end{aligned}$$

  where f is the same keystone fix as A used in the previous steps. If the equality does not hold, then A aborts. Otherwise A sends keystone k to B.

At the end of this protocol, both $\langle k, \sigma _A \rangle$ and $\langle k, \sigma _B \rangle$ are binding, and accepted by the $\mathsf {Verify}$ algorithm.

Remark 1

Note that A has an the upper hand in this protocol: Only when A releases the keystone do both signatures become simultaneously binding, and there is no guarantee that A will ever do so. Actually, since A controls the timing of the keystone release (if it is released at all), A may only reveal k to a third party C but withhold it from B, and gain some advantage by doing so. In other terms, concurrent signatures can be abused by A [3, 10].

Chen et al. [7] argue that there are situations where it is not in A’s interest to try and cheat B, in which abuse-freeness is not necessary. One interesting scenario is credit card payment in the “four corner” model. Assume that B’s signature is a payment to A. To obtain payment, A must channel via her acquiring bank C, which would communicate with B’s issuing bank D. D would ensure that B receives both the signature and the keystone — as soon as this happens A is bound to her signature. Since in this scenario there is no possibility for A to keep B’s signature private, fairness is eventually restored.

Example 1

A concurrent signature scheme based on the ring signature algorithm of Abe et al. [1] was proposed by Chen et al. [7]:

• $\mathsf {Setup}$: On input a security parameter $\ell$, two large primes p and q are selected such that $q|p - 1$. An element $g \in \mathbb Z_p^\times$ of order q is selected. The spaces $\mathcal S = \mathcal F = \mathbb Z_q$ and $\mathcal M = \mathcal K = \{0,1\}^*$ are chosen. Two cryptographic hash functions $H_1, H_2: \{0,1\}^* \rightarrow \mathbb Z_q$ are selected and we set $\mathsf {KeyGen} = H_1$. Private keys $x_A, x_B$ are selected uniformly at random from $\mathbb Z_q$ and the corresponding public keys are computed as $g^{x_i} \bmod p$.

• $\mathsf {aSign}$: The algorithms takes as input $y_i, y_j, x_i, h_2, M$, verifies that $y_i \ne y_j$ (otherwise aborts), picks a random value $t \in \mathbb Z_q$ and computes

  $$\begin{aligned} h&= H_2 \left( g^t y_j^{h_2} \bmod p \Vert M \right) \\ h_1&= h - h_2 \bmod q \\ s&= t - h_1x_i \bmod q \end{aligned}$$

  where $\Vert$ denotes concatenation. The algorithm outputs $\langle s, h_1, h_2 \rangle$.

• $\mathsf {aVerify}$: This algorithm takes as input $s, h_1, h_2, y_i, y_j, M$ and checks whether the following equation holds:

  $$\begin{aligned} h_1 + h_2 = H_2 \left( g^s y_i^{h_1} y_j^{h_2} \bmod p \Vert M \right) \bmod q \end{aligned}$$

The security of this scheme can be proven in the Random Oracle model assuming the hardness of computing discrete logarithms in $\mathbb Z_p^\times$.

2.2 Legal Fairness for Concurrent Signatures

A concurrent signature scheme is secure when it achieves existential unforgeability, ambiguity and fairness against an active adversary that has access to a signature oracle. We define these notions in terms of games played between the adversary $\mathcal A$ and a challenger $\mathcal C$. In all security games, $\mathcal A$ can perform any number of the following queries:

• KeyGen queries: $\mathcal A$ can receive a keystone fix $f = \mathsf {KeyGen}(k)$ where k is chosen by the challenger³.

• KeyReveal queries: $\mathcal A$ can request that $\mathcal C$ reveals which k was chosen to produce a keystone fix f in a previous KeyGen query. If f was not a previous KeyGen query output then $\mathcal C$ returns $\bot$.

• aSign queries: $\mathcal A$ can request an ambiguous signature for any message of his choosing and any pair of users⁴.

• SKExtract queries: $\mathcal A$ can request the private key corresponding to a public key.

Definition 2

(Unforgeability). The notion of existential unforgeability for concurrent signatures is defined in terms of the following security game:

• 1. The $\mathsf {Setup}$ algorithm is run and all public parameters are given to $\mathcal A$.

• 2. $\mathcal A$ can perform any number of queries to $\mathcal C$, as described above.

• 3. Finally, $\mathcal A$ outputs a tuple $\sigma = \langle s, h_1, f\rangle$ where $s \in \mathcal S, h_1, f \in \mathcal F$, along with public keys $y_C, y_D$ and a message $M \in \mathcal M$.

$\mathcal A$ wins the game if $\mathsf {aVerify}$ accepts $\sigma$ and either of the following holds:

• $\mathcal A$ did not query SKExtract on $y_C$ nor on $y_D$, and did not query aSign on $(y_C, y_D, f, M)$ nor on $(y_D, y_C, h_1, M)$.

• $\mathcal A$ did not query aSign on $(y_C, y_i, f, M)$ for any $y_i \ne y_C$, and did not query SKExtract on $y_C$, and f is the output of $\mathsf {KeyGen}$: either an answer to a KeyGen query, or $\mathcal A$ can produce a k such that $k = \mathsf {KeyGen}(k)$.

The last constraint in the unforgeability security game corresponds to the situation where $\mathcal A$ knows one of the private keys (as is the case if $\mathcal A = A$ or B).

Definition 3

(Ambiguity). The notion of ambiguity for concurrent signatures is defined in terms of the following security game:

• 1. The $\mathsf {Setup}$ algorithm is run and all public parameters are given to $\mathcal A$.

• 2. Phase 1: $\mathcal A$ can perform any number of queries to $\mathcal C$, as described above.

• 3. Challenge: $\mathcal A$ selects a challenge tuple $(y_i, y_j, M)$ where $y_i, y_j$ are public keys and $M \in \mathcal M$. In response, $\mathcal C$ selects a random $k \in \mathcal K$, a random $b \in \{0,1\}$ and computes $f = \mathsf {KeyGen}(k)$. If $b = 0$, then $\mathcal C$ outputs

  $$\begin{aligned} \sigma _1 = \langle s_1, h_1, f\rangle = \mathsf {aSign}(y_i, y_j, x_i, f, M) \end{aligned}$$

  Otherwise, if $b = 1$ then $\mathcal C$ computes

  $$\begin{aligned} \sigma _2 = \langle s_2, h_2, f\rangle = \mathsf {aSign}(y_j, y_i, x_i, f, M) \end{aligned}$$

  but outputs $\sigma _2' = \langle s_2, f, h_2\rangle$ instead.

• 4. Phase 2: $\mathcal A$ can perform any number of queries to $\mathcal C$, as described above.

• 5. Finally, $\mathcal A$ outputs a guess bit $b' \in \{0,1\}$.

$\mathcal A$ wins the game if $b = b'$ and if $\mathcal A$ made no KeyReveal query on f, $h_1$ or $h_2$.

Definition 4

(Fairness). The notion of fairness for concurrent signatures is defined in terms of the following security game:

• 1. The $\mathsf {Setup}$ algorithm is run and all public parameters are given to $\mathcal A$.

• 2. $\mathcal A$ can perform any number of queries to $\mathcal C$, as described above.

• 3. Finally, $\mathcal A$ chooses two public keys $y_C, y_D$ and outputs $k \in \mathcal K$ and $S = (s, h_1, f, y_C, y_D, M)$ where $s \in \mathcal S$, $h_1, f \in \mathcal F$, $M \in \mathcal M$.

$\mathcal A$ wins the game if $\mathsf {aVerify}(S)$ accepts and either of the following holds:

• f was output from a KeyGen query, no KeyReveal query was made on f, and $\mathsf {Verify}$ accepts $\langle k, S \rangle$.

• $\mathcal A$ can output $S' = (s', h_1', f, y_D, y_C, M')$ where $\mathsf {aVerify}(S')$ accepts and $\mathsf {Verify}(k, S)$ accepts, but $\mathsf {Verify}(k, S')$ rejects.

This definition of fairness formalizes the idea that B cannot be left in a position where a keystone binds his signature to him while A’s initial signature is not also bound to A. It does not, however, guarantee that B will ever receive the necessary keystone.

3 Legally Fair Co-signatures

3.1 Legal Fairness Without Keystones

The main idea builds on the following observation: Every signature exchange protocol is plagued by the possibility that the last step of the protocol is not performed. Indeed, it is in the interest of a malicious party to get the other party’s signature without revealing its own. As a result, the best one can hope for is that a trusted third party can eventually restore fairness.

To avoid this destiny, the proposed paradigm does not proceed by sending A’s signature to B and vice versa. Instead, we construct a joint signature, or co-signature, of both A and B. By design, there are no signatures to steal — and stopping the protocol early does not give the stopper a decisive advantage. More precisely, the contract they have agreed upon is the best thing an attacker can gather, and if she ever wishes to enforce this contract by presenting it to a court of law, she would confirm her own commitment to it as well as the other party’s. Therefore, if one can construct co-signatures without intermediary individual signatures being sent, legal fairness can be achieved without keystones.

Since keystones can be used by the party having them to abuse the other [7], the co-signature paradigm provides an interesting alternative to concurrent signatures.

Fig. 1.

Public directory $\mathcal D$ distributing the public keys.

3.2 Schnorr Co-signatures

To illustrate the new paradigm, we now discuss a legally fair contract-signing protocol built from the well-known Schnorr signature protocol, that produces signatures compatible with standard Schnorr signatures. This contract signing protocol is provably secure in the random oracle model under the hardness assumption of solving the discrete logarithm problem.

The construction can be adapted to other DLP schemes, such as most⁵ of those enumerated in [18], including Girault-Poupard-Stern [12] and ElGamal [9].

• $\mathsf {Setup}$: An independent (not necessarily trusted) authority generates a classical Schnorr parameter-set p, q, g which is given to A and B. Each user U generates a usual Schnorr public key $y_U=g^{x_U}$ and publishes $y_U$ on a public directory $\mathcal D$ (see Fig. 1). To determine the co-signature public-key $y_{A,B}$ of the pair $\langle A, B \rangle$, a verifier consults $\mathcal D$ and simply computes $y_{A,B}=y_A y_B$. Naturally, $y_{A,B} = y_{B,A}$.

• $\mathsf {Cosign}$: To co-sign a message m, A and B compute a common r and a common s, one after the other. Without loss of generality we assume that B initiates the co-signature.

  • During the first phase (Fig. 2), B chooses a private random number $k_B$ and computes $r_B \leftarrow g^{k_B}$. He commits to that value by sending to A a message digest $\rho \leftarrow H(0\Vert r_B)$. A chooses a private random number $k_A$, computes $r_A \leftarrow g^{k_A}$ and sends $r_A$ to B. B replies with $r_B$, which A checks against the earlier commitment $\rho$. Both parties compute $r \leftarrow r_A r_B$, and $e \leftarrow H(1\Vert m\Vert r)$, where m is the message to be co-signed.

  • During the second phase of the protocol, B sends $s_B \leftarrow k_B - e x_B \bmod q$ to A. A replies with $s_A \leftarrow k_A - e x_A \bmod q$. Both users compute $s \leftarrow s_A + s_B \bmod q$.

  Fig. 2.

  

  Generating the Schnorr co-signature of message m.

• $\mathsf {Verify}$: As in the classical Schnorr signature, the co-signature $\{r, s\}$ is checked for a message m by computing $e \leftarrow H(m\Vert r)$, and checking whether $g^sy^e = r$ (Fig. 3). If the equality holds, then the co-signature binds both A and B to m; otherwise neither party is tied to m.

Fig. 3.

Verification of a Schnorr co-signature m, r, s.

Remark 2

Note that during the co-signature protocol, A might decide not to respond to B: In that case, A would be the only one to have the complete co-signature. This is a breach of fairness insofar as A can benefit from the co-signature and not B, but the protocol is abuse-free: A cannot use the co-signature as a proof that B, and B alone, committed to m. Furthermore, it is not a breach of legal fairness: If A presents the co-signature in a court of law, she ipso facto reveals her commitment as well.

Remark 3

In a general fair-contract signing protocol, A and B can sign different messages $m_A$ and $m_B$. Using the co-signature construction requires that A and B agree first on the content of a single message m.

3.3 Security Analysis

The security of the co-signature scheme essentially builds on the unforgeability of classical Schnorr signatures. Since there is only one co-signature output, the notion of ambiguity does not apply per se — albeit we will come back to that point later on. The notion of fairness is structural in the fact that a co-signature, as soon as it is binding, is binding for both parties.

As for concurrent signatures, an adversary $\mathcal A$ has access to an unlimited amount of conversations and valid co-signatures, i.e. $\mathcal A$ can perform the following queries:

• Hash queries: $\mathcal A$ can request the value of H(x) for a x of its choosing.

• CoSign queries: $\mathcal A$ can request a valid co-signature r, s for a message m and a public key $y_{C,D}$ of its choosing.

• Transcript queries: $\mathcal A$ can request a valid transcript $(\rho , r_C, r_D, s_C, s_D)$ of the co-signing protocol for a message m of its choosing, between users C and D of its choosing.

• SKExtract queries: $\mathcal A$ can request the private key corresponding to a public key.

• Directory queries: $\mathcal A$ can request the public key of any user U.

The following definition captures the notion of unforgeability in the co-signing context:

Definition 5

(Unforgeability). The notion of unforgeability for co-signatures is defined in terms of the following security game between the adversary $\mathcal A$ and a challenger $\mathcal C$:

• 1. The $\mathsf {Setup}$ algorithm is run and all public parameters are provided to $\mathcal A$.

• 2. $\mathcal A$ can perform any number of queries to $\mathcal C$, as described above.

• 3. Finally, $\mathcal A$ outputs a tuple $(m, r, s, y_{C,D})$.

$\mathcal A$ wins the game if $\mathsf {Verify}(m, r, s) = \mathsf {True}$ and there exist public keys $y_C, y_D \in \mathcal D$ such that $y_{C,D} = y_Cy_D$ and either of the following holds:

• $\mathcal A$ did not query SKExtract on $y_C$ nor on $y_D$, and did not query CoSign on $m, y_{C,D}$, and did not query Transcript on $m, y_C, y_D$ nor $m, y_D, y_C$.

• $\mathcal A$ did not query Transcript on $m, y_C, y_i$ for any $y_i \ne y_C$ and did not query SKExtract on $y_C$, and did not query CoSign on $m, y_C, y_i$ for any $y_i \ne y_C$.

We shall say that a co-signature scheme is unforgeable when the success probability of $\mathcal A$ in this game is negligible.

To prove that the Schnorr-based scheme described above is secure we use the following strategy: Assuming an efficient forger $\mathcal A$ for the co-signature scheme, we turn it into an efficient forger $\mathcal B$ for Schnorr signatures, then invoke the Forking Lemma to prove the existence of an efficient solver $\mathcal C$ for the discrete logarithm problem. All proofs hold in the Random Oracle model.

Since the co-signing protocol gives the upper hand to the last-but-one speaker there is an asymmetry: Alice has more information than Bob. Therefore we address two scenarios: When the attacker plays Alice’s role, and when the attacker plays Bob’s.

Theorem 1

Let $\{y, g, p, q\}$ be a DLP instance. If $\mathcal A$ plays the role of Bob (resp. Alice) and is able to forge in polynomial time a co-signature with probability $\epsilon _F$, then in the Random Oracle model $\mathcal A$ can break the DLP instance with high probability in polynomial time.

Proof

The proof of this theorem is given in the appendix of the IACR ePrint of this paper. In the proof, this theorem is split in twain depending on whether $\mathcal A$ impersonates Bob or Alice.    $\square$

4 Concurrent Co-signatures

4.1 Proofs of Involvment

We now address a subtle weakness in the protocol described in the previous section, which is not captured by the fairness property per se and that we refer to as the existence of “proofs of involvment”. Such proofs are not valid co-signatures, and would not normally be accepted by verifiers, but they nevertheless are valid evidence establishing that one party committed to a message. In a legally fair context, it may happen that such evidence is enough for one party to win a trial against the other — who lacks both the co-signature, and a proof of involvment.

Example 2

In the co-signature protocol of Fig. 2, $s_B$ is not a valid Schnorr signature for Bob. Indeed, we have $g^{s_B}y_B^{e} = r_B \ne r$. However, Alice can construct $s' = s_B + k_A$, so that $m, r, s'$ forms a valid classical signature of Bob alone on m.

Example 2 illustrates the possibility that an adversary, while unable to forge a co-signature, may instead use the information to build a valid (mono-) signature. Note that Alice may opt for a weaker proof of involvment, for instance by demonstrating her possession of a valid signature using any zero-knowledge protocol.

A straightforward patch is to refrain from using the public keys $y_A, y_B$ for both signature and co-signature — so that attempts at constructing proofs of involvment become vain. For instance, every user could have a key $y_U^{(1)}$ used for classical signature and for certifying a key $y_U^{(2)}$ used for co-signature⁶. If an adversary generates a classical signature from a co-signature transcript as in Example 2, she actually reveals her harmful intentions.

However, while this exposes the forgery — so that honest verifiers would reject such a signature — the perpetrator remains anonymous. There are scenarios in which this is not desirable, e.g. because it still proves that B agreed (with some unknown and dishonest partner) on m.

Note that the existence of proof of involvment is not necessary and depends on the precise choice of underlying signature scheme.

4.2 Security Model

It is important to make extremely clear the security model that we are targeting. In this situation an adversary $\mathcal A$ (possibly Alice or Bob) tries to forged signatures from partial and/or complete traces of co-signature interactions, which can be of two kinds :

• 1. Co-signatures between two parties, at least one of which did not take part in the co-signature protocol;

• 2. (Traditional) signatures of either party.

$\mathcal A$ succeeds if and only if one of these forgeries is accepted, which can be captured as the probability of acceptance of $\mathcal A$’s outputs, and the victim (purported mono-signatory, or co-signatory) doesn’t have a co-signature with $\mathcal A$ ⁷.

Observe that due to the unforgeability of Schnorr signatures, the attacker must necessarily impersonate one of the co-signatories to achieve either of the two forgeries mentioned above (in fact, the strongest position is that of Alice, who has an edge over Bob in the protocol). This is the reason why the victim may have a co-signature of $\mathcal A$, so that this security model captures fairness.

In short, we propose to address such attacks in the following way:

• 1. By using a different key for co-signature and mono-signature;

• 2. By having Bob store specific co-signature-related information in non-volatile memory.

The reason for (1) is that it distinguishes between mono-signatures, and mono-signatures generated from partial co-signature traces. Thanks to this, it is easy for the verifier to detect a forgery, and perform additional steps.

The reason for (2) is twofold: On the one hand, it enables the verifier to obtain from Bob definitive proof that there was forgery; on the other hand, once the forgery has been identified, it makes it possible for the verifier to re-establish fairness binding the two real co-signatories together. Note that Bob is in charge of keeping this information secure, i.e. available and correct.

Fig. 4.

The legally fair co-signature of message m.

4.3 Concurrent Co-signatures

In the interest of fairness, the best we can ask is that if A tries to incriminate B on a message they both agreed upon, she cannot do so anonymously.

To enforce fairness on the co-signature protocol, we ask that the equivalent of a keystone is transmitted first; so that in case of dispute, the aggrieved party has a legal recourse. First we define the notion of an authorized signatory credential:

Definition 6

(Authorized signatory credential). The data field

$$\begin{aligned} \varGamma _{\text {Alice,Bob}}=\{\text {Alice},\text {Bob},k_A,\sigma _{x_A}(g^{k_A}\Vert \text {Alice}\Vert \text {Bob})\} \end{aligned}$$

is called an authorized signatory credential given by Alice to Bob, where $\sigma _{x_A}$ is some publicly known auxiliary signature algorithm using Alice’s private key $x_A$ as a signing key.

Any party who gets $\varGamma _{\text {Alice,Bob}}$ can check its validity, and releasing $\varGamma _{\text {Alice,Bob}}$ is by convention functionally equivalent to Alice giving her private key $x_A$ to Bob. A valid signature by Bob on a message m exhibited with a valid $\varGamma _{\text {Alice,Bob}}$ is legally defined as encompassing the meaning ($\Rrightarrow$) of Alice’s signature on m:

$$\begin{aligned} \{\varGamma _{\text {Alice,Bob}}, \text {signature by Bob on}\ m\}\Rrightarrow \text {signature by Alice on}\ m \end{aligned}$$

Second, the co-signature protocol of Fig. 2 is modified by requesting that Alice provide $t=\sigma _{x_A}(g^{k_A}\Vert \text {Alice}\Vert \text {Bob})$ to Bob. Bob stores this in a local non-volatile memory $\mathcal L$ along with $s_B$. For all practical purposes, $\mathcal L$ can be simply regarded as Bob’s hard disk. Together, t and $s_B$ act as a keystone enabling Bob (or a verifier, e.g. a court of law) to reconstruct $\varGamma _{\text {Alice,Bob}}$ if Alice exhibits a (fraudulent) signature binding Bob alone with his co-signing public key.

Therefore, should Alice try to exhibit as in Example 2 a signature of Bob alone on a message they both agreed upon (which is known as a fraud), the court would be able to identify Alice as the fraudster.

Fig. 5.

The verification procedure: proof of involvement.

The modified signature protocol is described in Fig. 4. Alice has only one window of opportunity to try and construct a fraudulent signature of Bob: by stopping the protocol at breakpoint ② and using the information $s_B$ ⁸.

Indeed, if the protocol is interrupted before breakpoint ①, then no information involving m was released by any of the parties: The protocol’s trace can be simulated without Bob’s help as follows

$$\begin{aligned} \begin{aligned} s_B,r&\xleftarrow {\$}\mathbb Z_q\\ e&\leftarrow H(1\Vert m\Vert r\Vert \text {Alice}\Vert \text {Bob})\\ r_B&\leftarrow g^{s_B} y_B^e\\ r_A&\leftarrow r r_B^{-1}\\ t&\leftarrow \sigma _{x_A}(r_A\Vert \text {Alice}\Vert \text {Bob})\\ \rho&\leftarrow H(0\Vert r_B) \end{aligned} \end{aligned}$$

and Bob has only received from Alice the signature of a random integer.

If Alice and Bob successfully passed the normal completion breakpoint ③, both parties have the co-signature, and are provably committed to m.

5 Conclusion and Further Work

In this paper we described an alternative construction paradigm for legally fair contract signing that doesn’t require keystones, but can be combined with them to provide additional power. The new paradigm produces co-signatures that bind a pair of users, and can be adapted to a number of DLP signature protocols. In the co-signature version of Schnorr’s protocol, the resulting co-signatures have the same format as classical (single-user) signature. This paradigm guarantees fairness and abuse-freeness, and can be equipped with keystones to add functionalities such as whistleblower traceability.

Appendix

The appendix is available in the IACR ePrint version of this paper.