1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
|
\section{Remediation of the Withdraw Loophole}
The withdraw loophole allows untaxed and untraceable payments by "misusing" the withdraw protocol.
It allows withdraw operations where owner of the resulting coins isn't the owner of the reserve that the coins where withdrawn from.
It is used for tipping and can therefore be seen as a feature.
Using the withdraw loophole for payments is illustrated in figure \ref{fig:withdraw-loophole-exploit}.
Note that we omitted the parts leading up to the coin creation (contract, agreement of price, number of coins and their denominations).
This is how it works on a high level:
\begin{enumerate}
\item The malicous merchant generates and blinds coins, which are then transmitted to the customer
\item The customer authorizes the withdraw from his reserve by signing the blinded coins with the private key of his reserve, thus generating withdraw confirmations.
\item The withdraw confirmations are transmitted to the exchange, which generates the signatures and returns them to the malicous merchant.
\item The malicous merchant unblinds the signatures.
He is now in possession of the coin, thus the payment is completed.
\end{enumerate}
\begin{figure}[h]
\begin{equation*}
\begin{array}{ l c l}
% preliminaries
\text{Customer} & & \text{malicous Merchant}
\\ \text{knows:} & & \text{knows:}
\\ \text{reserve keys } w_s, W_p
\\ \text{denomination public key } D_p = \langle e, N \rangle & & \text{denomination public key } D_p = \langle e, N \rangle
\\
% generate coin
\\ & & \text{generate coin key pair:}
\\ & & c_s, C_p \leftarrow \text{Ed25519.KeyGen}()
% blind
\\ & & \text{blind:}
\\ & & r \leftarrow random \in \mathbb{Z}_N^*
\\ & & m' := \text{FDH}(N, C_p)*r^{e} \mod N
% sing with reserve sk
\\ & \xleftarrow[\rule{2cm}{0pt}]{m'}
\\ \text{sign with reserve private key:}
\\ \rho_W := \langle D_p, m' \rangle
\\ \sigma_W := \text{Ed25519.Sign}(w_s, \rho_W)
\\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W \rangle }
\\
% TODO add some kind of separator
\hline
\\
\text{malicous Merchant} & & \text{Exchange}
\\\text{knows:} & & \text{knows:}
\\& & \text{reserve public key } W_p
\\ \text{denomination public key } D_p = \langle e, N \rangle & & \text{denomination keys } d_s, D_p
\\
\\ & \xrightarrow[\rule{2cm}{0pt}]{ \langle W_p, \sigma_W, \rho_W \rangle }
\\ & & \langle D_p, m' \rangle := \rho_W
\\ & & \text{verify if } D_p \text{ is valid}
\\ & & \textbf{check } \text{Ed25519.Verify}(W_p, \rho_W, \sigma_W)
\\ & & \text{decrease balance if sufficient}
\\ & & \text{sign:}
\\ & & \sigma'_c := (m')^{d_s} \mod N
\\ & \xleftarrow[\rule{2cm}{0pt}]{\sigma'_c}
\\ \text{unblind:}
\\ \sigma_c := \sigma'_c*r^{-1}
\\ \text{verify signature:}
\\ \textbf{check if } \sigma_c = \text{FDH}(N, C_p)
\\
\\ \text{resulting coin: } \langle c_s, C_p, \sigma_c, D_p \rangle
\end{array}
\end{equation*}
\caption{untaxed payment using withdraw loophole}
\label{fig:withdraw-loophole-exploit}
\end{figure}
\subsection{Requirements For A Possible Solution}
A viable solution has to fix the withdraw loophole, while still providing a solution for tipping. In addition, Taler's security properties must not be weakened.
The underlying problem that has to be solved is to check that the person withdrawing a coin is also the owner of the reserve used in the withdraw.
This has to be solved in a way that prevents the customer and malicious merchant to work together.
% Requirements For A Perfect Solution}
% minimal adjustments to Taler
% Commitment to sk of Reserve -> constructed by customer (key owner)
% commitment to sk of coin
% how do we ensure that the customer is key owner? -> combine with reserve sk
% how do we verify? problems with blinding
% how do we ensure that the coin in the commitment is the coin that is signed?
% exchange must not learn anything about coin to prevent linking of withdraw and transaction
\subsection{Discussed Solution}
For our proposed solution, a few adjustments to Taler have to be made:
\begin{itemize}
\item The withdraw confirmation must include a commitment to the public key.
This commitment must be constructed in a way that requires the customer to know the public key.
The exception to this are special tipping reserves (to preserve the tipping feature).
\item Cut-and-choose is added to the withdraw protocol.
This means that the customer has to generate the coin and withdraw confirmation $ k $ times.
The exchange will then choose one of the $ k $ sessions.
The customer has to reveal the coin public key, blinding secret and commitment for all sessions except the chosen one.
If the customer isn't able to deliver, the reserve is locked for future withdraws until the other sessions are delivered.
Cut-and-choose is introduced to verify whether the customer honestly created the commitment and used the same coin public key for the signature creation and the commitment.
If the reserve is a special tip reserve (which has to be registered), this check is omitted.
\item An additional protocol is created that transfers the remaining value of a coin back to the reserve if anyone is able to reveal the commitment from the withdrawal.
The adjustments described up to this point lead to the customer knowing all the necessary values for using this protocol.
Besides the customer, no one must be able to reproduce the commitment, except in case of a reserve key compromise.
\item Reserves are limited (usually only one, unless justified) and bound to a customer (KYC).
% this goes further than fixing the loophole. It prevents people from creating new reserves that are then to be transfered
% TODO check if there are disadvantages to this, especially regarding privacy
\item For a coin to be refreshable, it must have been seen by the exchange before, meaning that it had to be used for a payment.
The purpose of this is to prevent a malicious merchant to simply refresh a coin after withdraw to prevent the customer from reverting the withdraw.
\item For any coin used in a payment, the subtracted value must be higher that a certain threshold (set globally or per denomination).
For example, if the threshold is $ 10\% $, at least CHF 10 of a 100 CHF coin must be used for a payment.
The goal of this change is to prevent a malicious merchant from buying a very cheap article to be able to refresh the coin.
\end{itemize}
The commitment has to fulfill the following properties:
\begin{enumerate}
\item It has to be constructed using the reserve private key and must be verifiable using the corresponding public key.
\item It has to include the coin public key.
\item It has to be constructed in a way that ensures that the customer has knowledge of the coin public key.
\item Everyone with knowledge of the two keys must be able to recreate it.
\end{enumerate}
A possible commitment that partially satisfies the properties can be constructed by hashing a signature of the coin's public key:
\begin{equation*}
H( \text{Ed25519.Sign} (w_w, C_p) )
\end{equation*}
Note that the PureEdDSA variant of Ed25519 has to be used for this.
This variant doesn't hash the message before signing (see \cite{rfc8032} for further details).\\
It is still possible for a customer and a malicious merchant to construct the commitment without the customer gaining knowledge of the coin public key.
However, the customer has to share one half of the hash of the reserve private key (which is practically one half of the private key, refer to section \ref{sec:eddsa-signature-creation} for details about EdDSA signature creation).
% was passiert wenn im Verhör und gezwungen wird, Keys herauszurücken?
There is one drawback to this solution:
In case of a reserve key compromise, coins generated by withdraw operation (not refreshed ones) can be linked to withdraw operations, thus revealing relationships between reserves and payments.
This is because an adversary (exchange or auditor) in possession of a reserve private key and coin public keys can calculate $ \text{H(Ed25519.Sign}(w_s, C_p)) $ and check in the database if there is a corresponding withdraw operation, thus linking reserve and coin.
\subsubsection{Discussion}
This is not perfect solution.
It is designed to make untaxed payments using the withdraw loophole less attractive to use for merchants.
If accepted, it should only be used in deployments where the withdraw loophole has to be prohibited.\\
The proposed modifications achieve that a malicious merchant, who wants to perform payments using the withdraw loophole, has to accept one of these drawbacks:
\begin{itemize}
\item He has to accept that the customer is able to revert the payment.
\item He has to spend the coins fully.\\
If he is registered as a merchant at an exchange, he can perform payments to himself to launder the money.
Here, Talers \ac{AML} capabilities come into play.\\
The other possibility is to buy goods at other merchants.
These goods then have to be liquidated, which requires effort.
This wouldn't be a problem (for the malicous merchant) if cryptocurrency can be bought using Taler.
\item He has to spend the coins partially to be able to refresh them (thus preventing payment reversion by the customer).
The goods that were bought using the coin fraction then would have to be liquidated (see previous point).
\item He has to add the threshold value that is lost in order to refresh the coin into the price for payments.
\end{itemize}
The commitment added to the withdrawal weakens the privacy of coins.
Blinding guarantees everlasting privacy, which would be neutralized by the commitment.
The added cut-and-choose makes withdrawing more intensive, which leads to increased infrastructure requirements (and therefore costs).
The added threshold makes coin spending less flexible.
Wallets either have to contain more coins to guarantee that there is always a coin (or multiple) available to guarantee a payment without violating the threshold limitations.
The other variant is that wallets refrain from withdrawing coins with big(ger) denominations, which leads to bigger sums of coins used per payment.
This discussed solution is submitted to the Taler team as a part of the thesis documentation, upon which they can review the protocol changes and decide whether to pursue further.
Therefore, the solution will not be implemented during this thesis.
|
