taler/exchange
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

implement feedback in cs thesis

Browse Source
This commit is contained in:
Lucien Heuzeveldt 2022-02-16 21:59:41 +01:00
parent ef938e0f7a
commit b73be40ccd
No known key found for this signature in database
GPG Key ID: F92EA78E19F4E49E
6 changed files with 14 additions and 209 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/cs/content/4_1_design.tex
View File

@ -48,8 +48,8 @@ The following protocols currently use \gls{RSABS}:
\item Customer
\item Exchange
\end{itemize}
\item \textbf{Payback Protocol:}
The payback protocol distinguishes three different cases, which either use the refresh protocol or disclose either the withdraw transcript or refresh protocol transcript to the exchange.
\item \textbf{Recoup Protocol:}
The recoup protocol distinguishes three different cases, which either use the refresh protocol or disclose either the withdraw transcript or refresh protocol transcript to the exchange.
\\ Components:
\begin{itemize}
\item Customer
@ -96,7 +96,7 @@ The coin and denomination private keys can be used as long-term secrets due to t
Another question evolved around which key to use for the derivation of $ r_0, r_1 $.
Obvious options are the denomination key or the exchange's online signing key.
The denomination key was chosen because it has the payback protocol in place that would handle coin recovery in case of a key compromise and subsequent revocation.
The denomination key was chosen because it has the recopu protocol in place that would handle coin recovery in case of a key compromise and subsequent revocation.
\begin{figure}[htp]
\begin{equation*}
@ -376,7 +376,7 @@ In the reveal phase, the RSA signing and unblinding is exchanged with Schnorr's
\\ & & \textbf{check } h_C = h_C'
\\ & & r_b := \text{HKDF}(256,n_r || d_s, \text{"r}b\text{"})
\\ & & \overline{s}_{C_p}^{(\gamma)} = r_b + \overline{c_{b_\gamma}} d_s \mod p
\\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
\\ & & \text{persist } \langle \rho_L, \sigma_L, S \rangle
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{b, \overline{s}_C^{(\gamma)}} &
% Check coin signature and persist coin
% unblind signature
@ -444,8 +444,8 @@ To re-obtain the derived coin, the same calculations as in \ref{fig:refresh-deri
\subsection{Tipping}
Tipping remains unchanged, except for the content of the message $ \rho_W = D_p, c_0, c_1 $ signed by the merchant using its reserve private key.
\subsection{Payback Protocol}
The payback protocol distinguishes three different cases, which all depend on the state of a coin whose denomination key has been revoked.
\subsection{Recoup Protocol}
The recoup protocol distinguishes three different cases, which all depend on the state of a coin whose denomination key has been revoked.
The following listing outlines the necessary changes on the protocol, please refer to Dold's documentation section 2.2.1 \cite{dold:the-gnu-taler-system} for details regarding the different cases.
\begin{itemize}
\item \textbf{The revoked coin has never been seen by the exchange}:

12
doc/cs/content/5_discussion.tex
View File

@ -192,9 +192,9 @@ The disk space comparison for a wallet can be found in \ref{tab:comp-wallet-spac
\textbf{Signature Scheme} & \textbf{Disk Space} & \textbf{Factor} & \textbf{Disk Space 1M coins}\\\hline
CS 256 bits & 150 bytes & 1x & 150 MB\\\hline
RSA 1024 bit & 416 bytes & 2.7x & 416 MB \\\hline
RSA 2048 bit & 800 bits & 5.3x & 800 MB\\\hline
RSA 3072 bit & 1184 bits & 7.9x & 1184 MB\\\hline
RSA 4096 bit & 1568 bits & 10.4x & 1568 MB\\\hline
RSA 2048 bit & 800 bytes & 5.3x & 800 MB\\\hline
RSA 3072 bit & 1184 bytes & 7.9x & 1184 MB\\\hline
RSA 4096 bit & 1568 bytes & 10.4x & 1568 MB\\\hline
\end{tabular}
\caption{Comparison disk space wallet}
\label{tab:comp-wallet-space}
@ -225,9 +225,9 @@ Depending on the hash size another 32 byte (or 64 byte) value is transmitted.
\textbf{Signature Scheme} & \textbf{Bandwith used} & \textbf{Factor} & \textbf{1M coins}\\\hline
CS 256 bits & 356 bytes & 1x & 324 MB\\\hline
RSA 1024 bit & 448 bytes & 1.3x & 448 MB \\\hline
RSA 2048 bit & 832 bits & 2.5x & 832 MB\\\hline
RSA 3072 bit & 1216 bits & 3.75x & 1216 MB\\\hline
RSA 4096 bit & 1600 bits & 4.9x & 1600 MB\\\hline
RSA 2048 bit & 832 bytes & 2.5x & 832 MB\\\hline
RSA 3072 bit & 1216 bytes & 3.75x & 1216 MB\\\hline
RSA 4096 bit & 1600 bytes & 4.9x & 1600 MB\\\hline
\end{tabular}
\caption{Bandwith comparison withdrawal}
\label{tab:comp-band-withd}

2
doc/cs/content/appendix/rsa-redesign.tex
View File

@ -159,7 +159,7 @@ The changes to the refresh protocol are related to the derivation of transfer se
\\ & & h_C' = H(h_T', h_{\overline{m}}')
\\ & & \textbf{check } h_C = h_C'
\\ & & \overline{\sigma}_C^{(\gamma)} := \overline{m}^{d_{s(t)}}
\\ & & \text{persist } \langle \rho_L, \sigma_L \rangle
\\ & & \text{persist } \langle \rho_L, \sigma_L, S \rangle
\\ & \xleftarrow[\rule{2.5cm}{0pt}]{\overline{\sigma}_C^{(\gamma)}} &
% Check coin signature and persist coin
\\ \sigma_C^{(\gamma)} := r^{-1}\overline{\sigma}_C^{(\gamma)}

35
doc/cs/content/chapter_01.tex
View File

@ -1,35 +0,0 @@
%!TEX root = ../dokumentation.tex
\chapter{Das erste Kapitel}
\section{Hello}
Erste Erwähnung eines Akronyms wird als Fußnote angezeigt. Jede weitere wird
nur verlinkt: \ac{AGPL}. Zweite Erwähnung \ac{AGPL}
Verweise auf das Glossar: \gls{Glossareintrag}, \glspl{Glossareintrag}
Nur erwähnte Literaturverweise werden auch im Literaturverzeichnis gedruckt:
\cite{baumgartner:2002}, \cite{dreyfus:1980}
\Gls{Glossareintrag}
Meine erste Fußnote\footnote{Ich bin eine Fußnote}
\begin{wrapfigure}{r}{.4\textwidth}
\includegraphics[height=.4\textwidth]{taler.png}
\vspace{-15pt}
\caption{Das Logo der Musterfirma\footnotemark}
\end{wrapfigure}
%Quelle muss in Fußnote stehen (da sonst aufgrund eines Fehlers nicht kompiliert
% wird)
\footnotetext{aus \cite{mustermann:2012}}
Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer
Text, der das Bild umfließt. Ein ganz langer Text, der das Bild umfließt. Ein
ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der das Bild
umfließt. Ein ganz langer Text, der das Bild umfließt. Ein ganz langer Text, der
das Bild umfließt.

160
doc/cs/content/withdraw_loophole_remediation.tex
View File

@ -1,160 +0,0 @@
\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.

2
doc/cs/thesis.tex
View File

@ -56,7 +56,7 @@
%------------ Eidesstattliche Erklärung
\includepdf[pages=1]{ads/Erklaerung}
% \includepdf[pages=1]{ads/Erklaerung}
%------------ History
% \input{ads/history}