**diff options**

author | Lucien Heuzeveldt <lucienclaude.heuzeveldt@students.bfh.ch> | 2022-02-16 21:59:41 +0100 |
---|---|---|

committer | Lucien Heuzeveldt <lucienclaude.heuzeveldt@students.bfh.ch> | 2022-02-16 21:59:41 +0100 |

commit | b73be40ccd9ad0ef4a985f252099c867f698896d (patch) | |

tree | 156a89f23cf4b49ac1d51ed927aafac4512e5113 /doc/cs | |

parent | ef938e0f7aca4232cbae322fdc7b68ed21fcd679 (diff) | |

download | exchange-b73be40ccd9ad0ef4a985f252099c867f698896d.tar.gz exchange-b73be40ccd9ad0ef4a985f252099c867f698896d.tar.bz2 exchange-b73be40ccd9ad0ef4a985f252099c867f698896d.zip |

implement feedback in cs thesis

Diffstat (limited to 'doc/cs')

-rw-r--r-- | doc/cs/content/4_1_design.tex | 12 | ||||

-rw-r--r-- | doc/cs/content/5_discussion.tex | 12 | ||||

-rw-r--r-- | doc/cs/content/appendix/rsa-redesign.tex | 2 | ||||

-rw-r--r-- | doc/cs/content/chapter_01.tex | 35 | ||||

-rw-r--r-- | doc/cs/content/withdraw_loophole_remediation.tex | 160 | ||||

-rw-r--r-- | doc/cs/thesis.tex | 2 |

6 files changed, 14 insertions, 209 deletions

diff --git a/doc/cs/content/4_1_design.tex b/doc/cs/content/4_1_design.tex index 272f8da7..1d22b151 100644 --- a/doc/cs/content/4_1_design.tex +++ b/doc/cs/content/4_1_design.tex @@ -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}: diff --git a/doc/cs/content/5_discussion.tex b/doc/cs/content/5_discussion.tex index 1e1bcd5d..c68b4a79 100644 --- a/doc/cs/content/5_discussion.tex +++ b/doc/cs/content/5_discussion.tex @@ -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} diff --git a/doc/cs/content/appendix/rsa-redesign.tex b/doc/cs/content/appendix/rsa-redesign.tex index 463b9735..4f66d907 100644 --- a/doc/cs/content/appendix/rsa-redesign.tex +++ b/doc/cs/content/appendix/rsa-redesign.tex @@ -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)} diff --git a/doc/cs/content/chapter_01.tex b/doc/cs/content/chapter_01.tex deleted file mode 100644 index 5bb35445..00000000 --- a/doc/cs/content/chapter_01.tex +++ /dev/null @@ -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. diff --git a/doc/cs/content/withdraw_loophole_remediation.tex b/doc/cs/content/withdraw_loophole_remediation.tex deleted file mode 100644 index 9e466aa7..00000000 --- a/doc/cs/content/withdraw_loophole_remediation.tex +++ /dev/null @@ -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. diff --git a/doc/cs/thesis.tex b/doc/cs/thesis.tex index 1e4bfb87..b6abb0d7 100644 --- a/doc/cs/thesis.tex +++ b/doc/cs/thesis.tex @@ -56,7 +56,7 @@ %------------ Eidesstattliche Erklärung -\includepdf[pages=1]{ads/Erklaerung} +% \includepdf[pages=1]{ads/Erklaerung} %------------ History % \input{ads/history} |