Keywords

1 Introduction

Bitcoin [22] is an online currency whose value is not endorsed by any central reserve, but is based on the perception of its users [15]. In recent years it has surged in value, reaching a peak of $1147 per bitcoin in December 2013. The currency is supported by a decentralised network of users whose collective computational power provides a guarantee of integrity for an append-only ledger. Any attempt to change the ledger’s history (a history-revision attack [4]) would require an adversary with at least, in theory 51 % of the networks computational resources to be successfulFootnote 1. Several central banks have evaluated the value of digital currencies and their potential impact on society [15, 25, 29].

Bitcoin is increasingly being accepted by many e-commerce websites as a form of payment. For example, Dell, one of the largest computer retailers in the world, now allows customers to use Bitcoin to pay for online purchases on the Dell website [9]. Recently, PayPal [5] and Expedia [24] have also endorsed support for using Bitcoin. Similarly, many community-driven organisations allow anonymous donations using Bitcoin. Examples include the TOR project [27], Mozilla Foundation [21] and the Calyx Institute [18],

While Bitcoin is designed to support anonymity (or pseudonymity) in a transaction, little attention has been paid to the anonymity in the post-payment scenario. As with any on-line payment system, the payer and the payee may need to engage in follow-up correspondence after the payment has been made, e.g., to acknowledge the receipt, to confirm billing information, to amend discrepancies in the order if there are any and to agree on the product delivery or pick-up. Such correspondence can involve privacy-sensitive information, which, if leaked to a third party, may trivially reveal the identity of the user involved in the earlier transaction (e.g., information about product delivery may contain the home address).

Currently, the primary mechanism to support follow-up correspondence after a Bitcoin transaction is through email. The Dell website requires shoppers to provide their email address when making a Bitcoin payment to facilitate post-payment correspondence. The Calyx Institute, a non-profit research organization dedicated to providing “privacy by design for everyone”, also recommends using e-mails for follow-up correspondence after a donation is made in Bitcoin. On its website, the instruction is given as the following [18]:

“Note that if you make a donation by Bitcoin, we have no way to connect the donation with your email address. If you would like us to confirm receipt of the donation (and send a thank you email!), you’ll need to send an email with the details of the transaction. Otherwise, you have our thanks for your support in advance”.

However, emails are merely a communication medium and have no built-in guarantees of security. First of all, there is no guarantee that the sender of the email must be the same person who made the Bitcoin payment. The details of the transaction cannot serve as a means of authentication, since they are publicly available on the Bitcoin network. Furthermore, today’s emails are usually not encrypted. The content of an email can be easily read by third parties (e.g., ISPs) during the transit over the Internet. The leakage of privacy-sensitive information in email can seriously threaten the anonymity of the user who has made an “anonymous” payment in Bitcoin previously.

So far the importance of protecting post-payment communication has been largely neglected in both the Bitcoin and the security research communities. To the best of our knowledge, no solution is available to address this practical problem in the real world. This is a gap in the field, which we aim to bridge in our work.

One trivial solution is to apply existing Authenticated Key Exchange (AKE) protocols to establish a secure end-to-end (E2E) communication channel between Bitcoin users. Two general approaches for realising secure E2E communication in cryptography include using 1) PKI-based AKE (e.g., HMQV), and 2) Password-based AKE (e.g., EKE and SPEKE). The former approach would require Bitcoin users to be part of a global PKI system, with each user holding a public key certificate. This is not realistic in current Bitcoin applications. The second approach requires Bitcoin users to have a pre-shared secret password. However, securely distributing pairwise shared passwords over the internet is not an easy task. Furthermore, passwords are a weak form of authentication and they may be easily guessed or stolen (e.g. by shoulder-surfing). A solution that can provide a stronger form of authentication without involving any passwords will be desirable.

Following the decentralised and anonymity-driven nature of the Bitcoin network [17], we propose new AKE protocols to support secure post-payment communication between Bitcoin users, without requiring any PKI or pre-shared passwords. Our solutions leverage the transaction-specific secrets in the confirmed Bitcoin payments published on the public blockchain to bootstrap trust in establishing an end-to-end secure communication channel. Given each party’s transaction history and our AKE protocols, both parties are guaranteed to be speaking to the other party who was involved in the transactions, without revealing their real identities.

Contributions. Our contributions in this paper are summarised below.

  • We propose two authenticated key exchange protocols – one interactive and the other non-interactive – using transaction-specific secrets and without the support of a trusted third party to establish end-to-end secure communication. These are new types of AKE protocols, since they bootstrap trust from Bitcoin’s public ledger instead of a PKI or shared passwords.

  • We provide proof-of-concept implementations for both protocols in the Bitcoin Core client with performance measurements. Our experiments suggest that these protocols are feasible for practical use in real-world Bitcoin applications.

Organization. The rest of the paper is organised as follows. Section 2 explains the background of Bitcoin and the ECDSA signature that is used for authenticating Bitcoin transactions. Section 3 proposes two protocols to allow post-payment secure communication between users based on their transaction history. One protocol is non-interactive with no forward secrecy, while the other is interactive with the additional guarantee of forward secrecy. Security proofs for both protocols are provided in Sect. 4. Section 5 describes the proof-of-concept implementations for both protocols and reports the performance measurements. Finally, Sect. 6 concludes the paper.

2 Background

In this section, we will provide brief background information about the Bitcoin protocol, the transaction signature and the underlying Elliptic Curve Digital Signature Algorithm (ECDSA). This information will be needed for understanding the two protocols presented in this paper.

2.1 Bitcoin

Bitcoin is a digital currency that allows a network of nodes to access a public ledger and to agree upon append-only changes periodically. We will outline the three main mechanisms in the Bitcoin protocol which include Bitcoin addresses, transactions and the Blockchain. Together, they allow users to identify each other pseudonymously, transfer bitcoins and record the transaction in the public ledger.

Each user is responsible for generating their Bitcoin address, which is simply the hash of an ECDSA public key. The corresponding private key is required to spend bitcoins. This approach for user identification is considered appropriate as the probability that two users generate the same public key is negligible due to the high number of possible ECDSA public keys.

Fig. 1.
figure 1

Transactions stored on the Blockchain based on [19]

Full size image

A common belief in the community is that Bitcoin offers pseudonymity that can help disguise their real-world identity due to the random nature of ECDSA public keys. This belief is bolstered as users are recommended to create a new Bitcoin address per transaction to increase the difficulty of tracking their transactions. However, it should be noted that Bitcoin was not designed with anonymity in mind [23] and studies have shown with limited success that it is possible to link Bitcoin addresses to real-world identities [3, 23, 26].

Transactions are created by users to send bitcoins. All transactions are sent to the network and its correctness is verified by other peers before it is accepted into the public ledger. Each transaction has a list of ‘inputs’ and ‘outputs’. The output states the new owner’s bitcoin address and the quantity to be transferred. The input will contain a signature to authorise the payment and a reference to a previous transaction whereby the user received the bitcoins. Figure 1 highlights how transactions are linked, which allows peers to perform the verification, by comparing the received transaction with their local copy of the ledger.

A special ‘miner’ will collect the most recent set of transactions from the network to form a ‘block’. This block is appended to the longest chain of blocks (Blockchain) approximately every ten minutes by solving a computationally difficult problem (proof of work) in return for a subsidy of bitcoins. This append-only ledger has become a relatively secure time stamp server [7], since reversing transactions that are committed on the Blockchain is considered infeasible. Figure 1 demonstrates how transactions are stored aperiodically on the Blockchain.

2.2 Transaction Signature

Figure 1 presented earlier demonstrates that the signature is stored in the input of a transaction. This signature must be from the Bitcoin address mentioned in the previous transaction’s output. Briefly, it is important to highlight that the user will create the transaction, specify the inputs and outputs, hash this transaction and then sign it using their private key. This prevents an adversary from modifying the contents of a transaction or claiming ownership of the bitcoins before it is accepted into the Blockchain.

figure a

Bitcoin incorporates the OpenSSL suite to execute the ECDSA algorithm. The NIST-P256 curve is used and all domain parameters over the finite field including group order n, generator P and modulus q can be found in [6]. An outline of the signature generation algorithm is presented in Algorithm 1 to highlight the usage of k as this will be required for the authenticated key exchange protocols. The verification algorithm follows what is defined in [13]. The notations and symbols used in our paper are summarised in Table 1.

3 Key Exchange Protocols

Key exchange protocols allow two or more participants to derive a shared cryptographic key, often used for authenticated encryption. In this section we will present two authenticated key exchange protocols: Diffie-Hellman-over-Bitcoin and YAK-over-Bitcoin. These protocols will take advantage of a random nonce k from an ECDSA signature. Our aim is to achieve transaction-level authentication by taking advantage of a secret that only exists due to the creation of a transaction that is stored on the Blockchain.

Both of these protocols will use k as a transaction-specific private key and \(Q=kP\) as a transaction-specific public key. Diffie-Hellman-over-Bitcoin will be a non-interactive protocol without forward secrecy and YAK-over-Bitcoin will be an interactive protocol with forward secrecy. All domain parameters D for both protocols are the same as the ECDSA algorithm.

Table 1. Summary of notations and symbols
Full size table

3.1 Setting the Stage

We will have two actors, Alice and Bob. A single transaction \(T_{A}\) is used by Alice to send her payment (anonymously or not) to Bob. For our protocols, we will assume that Bob has created a second transaction \(T_{b}\) using his ECDSA private key, so the Blockchain contains both Alice and Bob’s ECDSA signature. This is a realistic assumption as Bob naturally needs to spend the money or re-organise his bitcoins to protect against theft. In one possible implementation, upon receiving Alice’s payment, Bob can send back to Alice a tiny portion of the received amount as acknowledgement, so his ECDSA signature is published on the blockchain (the signature serves to prove that Bob knows the ECDSA private key). This is just one way to ensure that the Blockchain contains both actors’ signatures, and there may be many other methods to achieve the same.

The owner of a transaction will be required to derive the transaction-specific private key (random nonce) k from their signature before taking part in the key exchange protocols. For both protocols, we assume the transactions \(T_{\mathrm {A}},T_{\mathrm {B}}\) between Alice and Bob have been sent to the network and accepted to the Blockchain with a depth of at least six blocks, which is considered the standard depth to rule-out the possibility of a double-spend attack [14].

In both protocols, each user will need to extract their partner’s signature (r, s) and attempt to derive their partner’s transaction-specific public key \(Q=(x,y)\). Algorithm 1 demonstrates that the r value from the signature is equal to the x co-ordinate modulo n (note that there is a subtle difference in the data range, since \(r \in Z_n\) and \(x \in Z_q\), but this has an almost negligible effect on the working of the protocols as we will explain in detail in Sect. 5.2). However, the y co-ordinate of Q is not stored in the transaction, and it can be either of the two values (above/below the x axis).

We define the uncompression function as Uncompress(x, sign) by using the x co-ordinate from their partner’s signature and the y co-ordinate’s \(sign \in \{+,-\}\). Using point uncompression and assuming one of the two possible signs for the y co-ordinate, Alice or Bob will be able to derive a value \(\widehat{Q}\) which we call the estimated transaction-specific public key for their partner. This \(\widehat{Q}\) could be either \(Q=(x,y)\) or its additive inverse \(-Q=(x,-y)\). This \(\widehat{Q}\) will correspond to the estimated transaction-specific private key \(\widehat{k}\), which could be either k or \(-k\).

Fig. 2.
figure 2

The Diffie-Hellman-over-Bitcoin Protocol

Full size image

3.2 Authentication

Our definition of authentication will refer to data origin authentication and we will use the Blockchain as a trusted platform for storing digital signatures. Knowledge of the private key d for a bitcoin address or the random nonce k in a signature will prove the identities of pseudonymous parties. We will define two concepts for authentication using Bitcoin:

  1. 1.

    Bitcoin address authentication. Knowledge of the discrete log d for a Bitcoin address.

  2. 2.

    Transaction authentication. Knowledge of the discrete log k from a single digital signature in a transaction.

Bitcoin address authentication is well-known in the community and has been used for other protocols. However, transaction authentication is a special case that our protocols will exploit. Although k and d are equivalent in proving ownership of a Bitcoin address or transaction, k is randomly generated for every ECDSA signature and is unique for each new transaction.

We will show that Alice and Bob can authenticate each other based on the knowledge of the k. This relies on participants trusting the integrity of the Blockchain as the cornerstone for authentication. For an adversary to mount a man-in-the-middle attack in this scene, he would need to perform a history-revision attack to modify the ECDSA signatures stored in the Blockchain.

3.3 Diffie-Hellman-over-Bitcoin Protocol

Based on the concept of transaction authentication, the first protocol that we present is ‘Diffie-Hellman-over-Bitcoin’. The protocol is non-interactive; the shared secret is generated using the signatures from two transactions and no additional information from the participants is required. However, forward secrecy is not provided, as we will illustrate in the security analysis.

Figure 2 presents an outline of the protocol. Initially, each user will derive the random nonce k from their own signatures and fetch their partner’s transaction from the Blockchain. Each user will gain an estimation of their partner’s public key \(\widehat{Q}\) before using their own transaction-specific private key k to derive the shared secret \((x_{\mathrm {A}\mathrm {B}},\pm y_{\mathrm {A}\mathrm {B}})\). Regardless of whether \(\widehat{Q}_{\mathrm {A}} = \pm Q_{\mathrm {A}}\) (or \(\widehat{Q}_{\mathrm {B}} = \pm Q_{\mathrm {B}}\)), the x co-ordinate of \(k_{\mathrm {B}}\widehat{Q}_{\mathrm {A}}\) will be the same as that of \(k_{\mathrm {A}}\widehat{Q}_{\mathrm {B}}\). Following the Elliptic Curve Diffie Hellman (ECDH) [20] approach, the \(x_{\mathrm {A}\mathrm {B}}\) co-ordinate will be used to derive the key \(KDF(x_{\mathrm {A}\mathrm {B}}) = \kappa \).

Fig. 3.
figure 3

YAK-over-Bitcoin Protocol

Full size image
figure c

3.4 YAK-over-Bitcoin Protocol

The second protocol we present is ‘YAK-over-Bitcoin’. This is based on adapting a PKI-based YAK key exchange protocol [12] to the Bitcoin application by removing the dependence on a PKI and instead relying on the integrity of the Blockchain. We chose YAK instead of others (e.g., station-to-station, MQV, HMQV, etc.), as YAK is the only PKI-based AKE protocol that requires each sender to demonstrate the proof of knowledge of both the static and ephemeral private keys. This requirement is important for the security proofs of our system as we will detail in Sect. 4. As well, we will show in the security analysis that the protocol allows the participants to have full forward secrecy.

An outline of our protocol is presented in Fig. 3. Initially, each user will follow the same steps as seen in the previous ‘Diffie-Hellman-over-Bitcoin’ protocol to derive their secret k and their partner’s estimated public key \(\widehat{Q}\). However, a subtle difference requires each user to compare their real public key Q with the estimation of their own key \(\widehat{Q}\) to determine if they are equal. If these public keys are different, then the user will use the additive inverse of k as their estimated transaction-specific private key and we will denote this choice between the two keys as \(\widehat{k}\). This subtle change will allow both parties to derive the same shared secret \((x_{\mathrm {A}\mathrm {B}},y_{\mathrm {A}\mathrm {B}})\) which would be expected in an interactive protocol without exchanging their real y co-ordinates.

Each user generates an ephemeral private key w and computes the corresponding public key \(W=wP\). As required in the original YAK paper [12], each user must also construct a zero knowledge proof to prove possession of the ephemeral private key w. These zero knowledge proofs can be sent over an insecure communication channel to their partners. Here, we will use the same Schnorr signature as in [12] to realise the ZKP. Details of the Schnorr ZKP are summarised in Algorithms 2 and 3. The definition of the Schnorr ZKP includes a unique signer identity ID, which prevents an attacker replaying the ZKP back to the signer herself [12]. In our case, we can simply use the unique r value from the user’s ECDSA signature (r, s) in the associated Bitcoin transaction T as the user’s identity.

Once the ZKPs have been verified, each user will derive \((x_{\mathrm {A}\mathrm {B}},y_{\mathrm {A}\mathrm {B}})\) using their secret \(w,\widehat{k}\), public value W and their partners’ estimated transaction-specific public key \(\widehat{Q}\). It should be easy to verify that although the shared secret has four different combinations \((\pm \widehat{k}_{\mathrm {A}} + w_{\mathrm {A}})(\pm \widehat{k}_{\mathrm {B}} + w_{\mathrm {B}})P\), the secret key derived between Alice and Bob will always be identical (due to each participant predicting the estimated public key \(\widehat{Q}\) that their partner will choose).

4 Security Analysis

Our protocols are based on reusing the signature-specific random value k in ECDSA as the transaction-specific secret on which the authenticated key exchange protocol is based. Hence, the security of both the ECDSA signature and the key exchange protocols needs to be analysed to make sure the reusing of k is sound in terms of security.

figure d

For the AKE protocols, following the security analysis of YAK [12], we consider three security requirements, informally defined in the following:

  • Private key security: The adversary is unable to gain any extra Footnote 2 information about the private key of an honest party by eavesdropping her communication with other parties, changing messages sent to her, or even participating in an AKE protocol with her.

  • Full forward secrecy: The adversary is unable to determine the shared secret of an eavesdropped AKE session in the past between a pair of honest parties, even if their private keys are leaked subsequently.

  • Session key security: The adversary is unable to determine the shared secret between two honest parties by eavesdropping their communication or changing their messages.

Note that in our security arguments we consider the security of shared secrets (\(x_{\mathrm {A}\mathrm {B}}\) in Figs. 2 and 3), as opposed to that of the subsequently calculated shared session keys (\(\kappa \) in the same figures). We henceforth denote the shared secret by K, i.e., \(\kappa =\mathrm {KDF}(K)\). We require the shared secret to be hard to determine for the adversary in the full forward secrecy and session key security requirements. A good key derivation function (KDF) derives from such a shared secret a session key which is indistinguishable from random. Our security proofs can be easily adapted to prove indistinguishability based on the decisional rather than computational Diffie-Hellman assumption.

For ECDSA signature, we require that it remains unforgeable against chosen-message attacks despite the randomness k being reused in subsequent AKE protocols. Although ECDSA has withstood major cryptanalysis, the security of ECDSA has only been proven under non-standard assumptions or assuming modifications (see [28] for a survey of these results). In our analysis, we consider extra information available to an attacker as a result of k being reused in AKE protocols, and show that it does not degrade the security of ECDSA.

We assume ECDSA to be a (non-interactive honest-verifier) zero-knowledge proof of knowledge of the private key d. This is a reasonable assumption in the random oracle model which follows the work of Malone-Lee and Smart [16]Footnote 3. In practice, people accept bitcoin transactions only when the ECDSA signatures are verified successfullyFootnote 4. Verifying the ECDSA signature is tantamount to verifying the knowledge of the ECDSA private key d that should only be held by the legitimate bitcoin user.

We also note that given an ECDSA message-signature pair, m, (r, s), knowledge of the private key d is equivalent to knowledge of the randomness k since given either the other can be calculated from \(sk = H(m) + dr \text { mod } n\).

4.1 Security of Diffie-Hellman-over-Bitcoin

This protocol is an Elliptic Curve Diffie-Hellman key exchange and the public values are bound to two transactions in the Blockchain. Private key security considers a malicious active adversary “Mallory”, and session key security considers an eavesdropper adversary “Eve”. The protocol does not provide full forward secrecy. We will provide a sketch of the proof of security for each property in the following. In each proof, we follow the same approach as in [12] to assume an extreme adversary, who has all the powers except those that would allow the attacker to trivially break any key exchange protocol.

Theorem 1

(Private Key Security). Diffie-Hellman-over-Bitcoin provides private key security under the assumption that ECDSA signature is a zero knowledge proof of knowledge of the ECDSA secret key.

Proof

(sketch). The goal of an adversary Mallory is to be able to gain some extra information on Alice’s transaction-specific private key \(k_\mathrm {A}\) through the following attack. Mallory is given the public parameters of the system and access to the Blockchain which includes Alice’s transaction \(T_\mathrm {A}\), then she provides a transaction \(T_\mathrm {M}\) which is included in the Blockchain, then she carries out a Diffie-Hellman-over-Bitcoin protocol with Alice (which is non-interactive), and eventually is able to calculate the shared secret K. The attack is depicted in Fig. 4(i). Alice’s ECDSA signature in \(T_\mathrm {A}\) is assumed to be zero knowledge and hence does not reveal any information about her private key. Furthermore, since Mallory’s transaction \(T_\mathrm {M}\) includes an ECDSA signature by her, and ECDSA signature is a proof of knowledge of Mallory’s ECDSA secret key \(d_\mathrm {M}\), Mallory must know \(d_\mathrm {M}\), and hence \(k_\mathrm {M}\). Hence, Mallory does not gain any extra knowledge from calculating K, since knowledge of \(k_\mathrm {M}\) and Alice’s public key enables her to simulate K on her own.    \(\square \)

Fig. 4.
figure 4

Security of Diffie-Hellman-over-Bitcoin. Light grey denotes what the adversary (Mallory in (i), Eve in (ii)) knows. Dark grey denotes what the adversary (Mallory) chooses.

Full size image

Theorem 2

(Session Key Security). Diffie-Hellman-over-Bitcoin provides session key security based on the computational Diffie-Hellman assumption under the assumption that ECDSA signature is a zero knowledge proof of knowledge of the ECDSA secret key.

Proof

(sketch). Assume there is a successful adversary Eve that is able to calculate the shared secret K for a key exchange between two honest parties Alice and Bob, without knowing either Alice or Bob’s transaction-specific secret keys, \(k_\mathrm {A}\) or \(k_\mathrm {B}\). The attack is depicted in Fig. 4(ii). Note that since the protocol is non-interactive, the adversary is reduced to a passive adversary. A successful attack would contradict the computational Diffie-Hellman (CDH) assumption since given an instance of the CDH problem \((P, \alpha P, \beta P)\), one is able to leverage Eve and solve the CDH problem by setting up Alice and Bob’s transaction-specific secrets as \(k_\mathrm {A}=\alpha \) and \(k_\mathrm {B}=\beta \), which results in \(K=\alpha \beta P\). A successful Eve implies that CDH can be solved efficiently.    \(\square \)

Fig. 5.
figure 5

Security of YAK-over-Bitcoin. Light grey denotes what the adversary (Mallory in (i) and (iii), Eve in (ii)) knows. Dark grey denotes what the adversary (Mallory) chooses.

Full size image

4.2 Security of YAK-over-Bitcoin

This protocol is an Elliptic Curve YAK key exchange and the public values are bound to two transactions in the Blockchain. Private key security and session key security consider a malicious active adversary “Mallory”, and full forward secrecy considers an eavesdropper adversary “Eve”. Similar as before, we assume an extreme adversary who has all the powers except those that would trivially allow the attacker to break any key exchange protocol. Under this assumption, we provide a sketch of the proof of security for each property in the following.

Theorem 3

(Private Key Security). YAK-over-Bitcoin provides private key security under the assumption that ECDSA signature is a zero knowledge proof of knowledge of the ECDSA secret key.

Proof

(sketch). The goal of an adversary Mallory is to be able to gain some extra information on Alice’s transaction-specific private key \(k_\mathrm {A}\) through the following attack. Mallory is given the public parameters of the system and access to the Blockchain which includes Alice’s transaction \(T_\mathrm {A}\), then she provides a transaction \(T_\mathrm {M}\) which is included in the Blockchain, then she carries out a YAK-over-Bitcoin protocol with Alice, in which Alice sends the message \((w_\mathrm {A}P,\mathrm {ZKP}\{w_\mathrm {A}\})\) and Mallory sends the message \((w_\mathrm {M}P,\mathrm {ZKP}\{w_\mathrm {M}\})\). Alice’s ephemeral secret \(w_\mathrm {A}\) is also assumed to be leaked to Mallory. The attack is depicted in Fig. 5(i). Alice’s ECDSA signature in \(T_\mathrm {A}\) is assumed to be zero knowledge and hence does not reveal any information about her private key. Furthermore, since the ECDSA signature in Mallory’s transaction and her message in the protocol are proofs of knowledge of \(d_\mathrm {M}\) (equivalently \(k_\mathrm {M}\)) and \(w_\mathrm {M}\), respectively, Mallory must know both \(k_\mathrm {M}\) and \(w_\mathrm {M}\). Note that she receives \((w_\mathrm {A}P,\mathrm {ZKP}\{w_\mathrm {A}\})\) and \(w_\mathrm {A}\) and hence will be able to calculate \(K=(k_\mathrm {M}+w_\mathrm {M})(k_\mathrm {A}P+w_\mathrm {A}P)\). Hence, Mallory does not gain any extra knowledge from the values she receives, since \(w_\mathrm {A}\) is independent of \(k_\mathrm {A}\) and knowledge of \(w_\mathrm {A}\), \(k_\mathrm {M}\), and \(w_\mathrm {M}\) enables Mallory to simulate all the values she receives.    \(\square \)

Theorem 4

(Full Forward Secrecy). YAK-over-Bitcoin provides full forward secrecy based on the computational Diffie-Hellman assumption.

Proof

(sketch). Assume there is a successful adversary Eve that is able to calculate the shared secret K for a previous key exchange between two honest parties Alice and Bob through the following attack. Both Alice and Bob’s transaction-specific secret keys \(k_\mathrm {A}\) and \(k_\mathrm {B}\) are assumed to be leaked to Eve. Eve is also assumed to have access to all the protocol messages exchanged between Alice and Bob, as well as the Blockchain of course. The attack is depicted in Fig. 5(ii). Given an instance of the CDH problem \((P, \alpha P, \beta P)\) one is able to leverage Eve and solve the problem as follows. The protocol is set up with the ephemeral secret values \(w_\mathrm {A}=\alpha \) and \(w_\mathrm {B}=\beta \) and all other parameters as per the protocol description. When Eve calculates K, the value \(S = K - k_\mathrm {A}k_\mathrm {B}P - k_\mathrm {A}(\beta P) - k_\mathrm {B}(\alpha P)\) is calculated and returned as the solution to the CDH problem. Note that since \(K=(k_\mathrm {A}+w_\mathrm {A})(k_\mathrm {B}+w_\mathrm {B})P\), we have \(S = \alpha \beta P\). A successful Eve implies that CDH can be solved efficiently.    \(\square \)

Theorem 5

(Session Key Security). YAK-over-Bitcoin provides session key security based on the computational Diffie-Hellman assumption under the assumption that ECDSA signature is a zero knowledge proof of knowledge of the ECDSA secret key.

Proof

(sketch). Assume there is a successful adversary Mallory that is able to calculate the shared secret K for a key exchange between two honest parties Alice and Bob through the following attack by impersonating Bob to Alice. Alice believes she is interacting with Bob, whereas in reality she is interacting with an impersonator Mallory who replaces Bob’s message in the protocol with her own \((w_\mathrm {M}P,\mathrm {ZKP}\{w_\mathrm {M}\})\). Alice’s transaction-specific secret key \(k_\mathrm {A}\) is assumed to be leaked to Mallory as well. However, Mallory does not know Bob’s transaction-specific secret key \(k_\mathrm {B}\). The attack is depicted in Fig. 5(iii). Given an instance of the CDH problem \((P, \alpha P, \beta P)\) one is able to leverage Mallory and solve the problem as follows. The protocol is set up with Alice’s ephemeral secret \(w_\mathrm {A}=\alpha \) and Bob’s transaction-specific secret \(k_\mathrm {B}=\beta \) and all other parameters as per the protocol description. When Mallory calculates K, the value \(S = K - k_\mathrm {A}w_\mathrm {B}P - w_\mathrm {A}(\beta P) - w_\mathrm {B}(\alpha P)\) is calculated and returned as the solution to the CDH problem. Note that since \(K=(k_\mathrm {A}+w_\mathrm {A})(k_\mathrm {B}+w_\mathrm {B})P\), we have \(S = \alpha \beta P\). A successful Mallory implies that CDH can be solved efficiently.    \(\square \)

4.3 Security of ECDSA Signatures

Diffie-Hellman-over-Bitcoin is a non-interactive protocol and the protocol participants do not send any messages to each other that would potentially have an impact on the security of ECDSA signatures.

In ‘YAK-over-Bitcoin’, the messages that the protocol participants send each other include information about their ephemeral keys \(w_\mathrm {A}\) and \(w_\mathrm {B}\) only, which are chosen independently of all the secret values related to the ECDSA signatures in \(T_\mathrm {A}\) and \(T_\mathrm {B}\). As shown in Theorem 1 in Sect. 4.2, the protocol does not reveal any information about the static private key (i.e., k), and hence not any information about the ECDSA private key (i.e., d) since the two values are linearly related. One can compute d from k, or vice versa. The key element in the proof of Theorem 3 is that each party is required to demonstrate knowledge of both the static and ephemeral keys. This also explains our choice of the YAK protocol, as YAK is the only PKI-based AKE protocol that has the requirement that each party must demonstrate the proof of knowledge for both the static and ephemeral keys (the former is realized by the Proof of Possession at the Certificate Authority registration while the later is achieved by Schnorr Non-interactive ZKP).

Table 2. Time performance for Alice executing Diffie-Hellman-over-Bitcoin and YAK-over-Bitcoin
Full size table

5 Implementation

Our implementation is a modification of the Bitcoin Core client and is considered a proof of concept. We have included three new remote procedure commands (RPC) that will allow the client to perform a non-interactive Diffie-Hellman key exchange, generate a zero knowledge proof to be shared with their partner and verify a partner’s zero knowledge proof before revealing the shared secret. Our modified implementation was executed using the -txindex parameter which allows us to query the Blockchain and retrieve the raw transaction data.

Two transactions were created using a non-modified implementation on the 10th December, 2013 to allow us to test our key exchange on the real network. All tests were carried out a MacBook Pro mid-2012 running OS X 10.9.1 with 2.3GHz Intel Core i7 and 4 cores and 16 GB DDR3 RAM. Each protocol is executed 100 times from Alice’s perspective and the average times are reported.

5.1 Time Analysis

Preliminary steps for both protocols involve fetching the transactions from the Blockchain 0.04 ms and retrieving the signatures (r, s) stored in the transaction 0.08 ms. Overall, these steps on average require 0.12 ms.

This ‘Diffie-Hellman-over-Bitcoin’ protocol is non-interactive as participants are not required to exchange information before deriving the shared secret. Table 2 demonstrates an average time of 0.08 ms to derive Alice’s transaction-specific private key \(k_{\mathrm {A}}\) and Bob’s estimated public key \(\widehat{Q}_{\mathrm {B}}\) and 0.051 ms to compute the shared key \(\kappa _{\mathrm {A}\mathrm {B}}\). Overall, on average the protocol executes in 0.59 ms which is reasonable for real-life use.

The ‘YAK-over-Bitcoin’ protocol is interactive as it requires each party to send an ephemeral public key together with a non-interactive Schnorr ZKP to prove the knowledge of the ephemeral private key. Table 2 shows that computing and verifying zero knowledge proofs is the most time-consuming operation. However, a total execution time of 2.55 ms is still reasonable for practical applications.

5.2 Note About Domain Parameters

Our investigation highlighted that \(q>n\) as seen in [6] which could obscure the relationship between k and r as the x co-ordinate can wrap around n. However, the probability that this may occur can be calculated as \((q-n)/q \approx 4\times 10^{-39}\) and is unlikely to occur in practice. However, in the rare chance that this does happen then it is easily resolved by \(r'= r+n\). This does not require any modification to the underlying signature code as it is simply an addition of the publicly available r with the modulus n. Once resolved, both parties can continue with the protocol. For reference, q and n are defined below:

figure f

6 Conclusion

In this paper, we have demonstrated transaction authentication by using the digital signatures stored in Bitcoin transactions to bootstrap key exchange. We proposed two protocols to allow for interactive and non-interactive key exchange, the latter offering an additional property of forward-secrecy. We encourage the community to try our proof-of-concept implementation and to take advantage of this new form of authentication to enable end-to-end secure communication between Bitcoin users.