From ef6d9cc56d3e3830750d76df1db48bc3d7d10f41 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Fri, 7 Apr 2017 14:59:41 +0200 Subject: [PATCH] edits addressing FC reviews --- doc/paper/taler.tex | 120 ++++++++++++++++++++++++++++---------------- 1 file changed, 78 insertions(+), 42 deletions(-) diff --git a/doc/paper/taler.tex b/doc/paper/taler.tex index a94669b22..9b2bb8993 100644 --- a/doc/paper/taler.tex +++ b/doc/paper/taler.tex @@ -393,7 +393,29 @@ assures customers and merchants that the exchange operates correctly. \subsection{Security model} %\vspace{-0.3cm} -% FIXME: Is this too obvious for a crypto paper? +As a payment system, Taler naturally needs to make sure that coins are +unforgeable and prevent double-spending. More precisely, as the same +coin is allowed to be involved in multiple operations, Taler needs to +ensure that the amounts spent per coin remain below the denomination +value and amounts credited to the coin from refunds. Furthermore, +transactions should be unlinkable; in particular, if a coin has been +partially spent or if a transaction was aborted, Taler must provide a +mechanism for customers to spend the remaining value in another +transaction that remains unlinkable to the first transaction. Finally, +this mechanism must not introduce a new loophole that might be used to +hide transactions in a way that would enable tax-evasion. + +As a practical system, Taler needs to be concerned with transient +network failures or loss of power. Thus, it must be possible to +resume protocols and recover from such failures at any point in time, +without any party suffering financial losses. We require that parties +are able to securely persist information and assume that after +errors they can resume from the previous state that was persisted. +We will explicitly state in the protocol when what state has +to be persisted. Participants that fail to recover data they were +expected to persist may suffer financial losses in proportion to the +value of the transactions involved. + Taler assumes that each participant has full control over their system. We assume the contact information of the exchange is known to both customer and merchant from the start, including that the customer @@ -419,7 +441,7 @@ On the cryptographic side, a Taler exchange demands that coins use a full domain hash (FDH) to make so-called ``one-more forgery'' attacks provably hard, assuming the RSA known-target inversion problem is hard~\cite[Theorem 12]{RSA-HDF-KTIvCTI}. For a withdrawn coin, -violating the customers anonymity cryptographily requires recognizing +violating the customers anonymity cryptographically requires recognizing a random blinding factor from a random element of the group of integers modulo the denomination key's RSA modulus, which appears impossible even with a quantum computers. For a refreshed coin, @@ -678,12 +700,12 @@ Auditors must sign all the exchange's keys including, the individual denomination keys. As we are dealing with financial transactions, we explicitly describe -whenever entities need to safely commit data to persistent storage. -As long as those commitments persist, the protocol can be safely -resumed at any step. Commitments to disk are cumulative, that is an -additional commitment does not erase the previously committed +whenever entities need to safely write data to persistent storage. +As long as the data persists, the protocol can be safely +resumed at any step. Persisting data is cumulative, that is an +additional persist operation does not erase the previously stored information. Keys and thus coins always have a well-known expiration -date; information committed to disk can be discarded after the +date; information persisted can be discarded after the expiration date of the respective public key. Customers may discard information once the respective coins have been fully spent, so long as refunds are not required. @@ -703,7 +725,9 @@ To withdraw anonymous digital coins, the customer first selects an exchange and one of its public denomination public keys $K_p$ whose value $K_v$ corresponds to an amount the customer wishes to withdraw. We let $K_s$ denote the exchange's private key corresponding to $K_p$. -Now the customer carries out the following interaction with the exchange: +We use $FDH_K$ to denote a full-domain hash where the domain is the +public key $K_p$. Now the customer carries out the following +interaction with the exchange: % FIXME: These steps occur at very different points in time, so probably % they should be restructured into more of a protocol description. @@ -713,9 +737,9 @@ Now the customer carries out the following interaction with the exchange: \begin{enumerate} \item The customer randomly generates: \begin{itemize} - \item reserve key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p$, + \item reserve key $W := (w_s,W_p)$ with private key $w_s$ and public key $W_p := w_sG$, \item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$, - \item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk. + \item blinding factor $b$, and persists $\langle W, C, b \rangle$. \end{itemize} The customer then transfers an amount of money corresponding to at least $K_v$ to the exchange, with $W_p$ in the subject line @@ -747,8 +771,8 @@ Now the customer carries out the following interaction with the exchange: history for the reserve. \item The customer computes the unblinded signature $U_b(S_K(B))$ and verifies that $S_K(\FDH_K(C_p)) = U_b(S_K(B))$. - Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$ - to their local wallet on disk. + Finally the customer persists the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$ + in their local wallet. \end{enumerate} @@ -783,8 +807,8 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$ to the contract indicating which services or goods the merchant will deliver to the customer, including the merchant specific URI for the payment. $p$ is the merchant's payment information (e.g. his IBAN number), and - $r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$ - to disk and sends $\mathcal{A}$ to the customer. + $r$ is a random nonce. The merchant persists $\langle \mathcal{A} \rangle$ + and sends $\mathcal{A}$ to the customer. \item The customer should already possess a coin $\widetilde{C}$ issued by a exchange that is accepted by the merchant, meaning $K$ of $\widetilde{C}$ should be publicly signed by @@ -803,10 +827,10 @@ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$ one would exceed its remaining value, it sends an error with the records from the previous transactions back to the merchant. \\ % - If double spending is not found, the exchange commits $\langle \mathcal{D} \rangle$ to disk + If double spending is not found, the exchange persists $\langle \mathcal{D} \rangle$ and signs a message affirming the deposit operation was successful. \item - The merchant commits and forwards the notification from the exchange to the + The merchant persists the response and forwards the notification from the exchange to the customer, confirming the success or failure of the operation. \end{enumerate} @@ -859,10 +883,18 @@ protocol with the exchange. \subsection{Refreshing} \label{sec:refreshing} We now describe the refresh protocol whereby a dirty coin $C'$ of -denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$ -with the same denomination. In practice, Taler uses a natural -extension where multiple fresh coins are generated a the same time to -enable giving precise change matching any amount. +denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$. To +simplify the description, this section describes the case where one +{\em unspent} dirty coin (for example, from an aborted transaction) is +exchanged for a fresh coin of the same denomination. In practice, +Taler uses a natural extension where multiple fresh coins of possibly +many different denominations are generated at the same time. For this, +the wallet simply specifies an array of coins wherever the protocol +below specifies only a single coin. The different denominations of the +fresh coins must be chosen by the wallet such that their value adds up +to the remaining balance of the dirty coin. This way, refreshing +enables giving precise change matching any amount, assuming the +exchange offers an adequate value range in its denominations. In the protocol, $\kappa \ge 2$ is a security parameter for the cut-and-choose part of the protocol. $\kappa = 3$ is actually @@ -885,7 +917,7 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}. \item the transfer public key $T^{(i)}_p := t^{(i)}_s G$ and \item the new coin secret seed $L^{(i)} := H(c'_s T_p^{(i)})$. \end{enumerate} - We have computed $L_i$ as a Diffie-Hellman shared secret between + We have computed $L^{(i)}$ as a Diffie-Hellman shared secret between the transfer key pair $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$ and old coin key pair $C' := \left(c_s', C_p'\right)$; as a result, $L^{(i)} = H(t^{(i)}_s C'_p)$ also holds. @@ -898,26 +930,26 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}. $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$ where $C^{(i)}_p := c^{(i)}_s G$. - The customer saves to disk $\langle C', \vec{t}\rangle$ where + The customer persists $\langle C', \vec{t}\rangle$ where $\vec{t} = \langle t^{(1)}_s, \ldots, t^{(\kappa)}_s \rangle$. We observe that $t^{(i)}_s$ suffices to regenerate $C^{(i)}$ and $b^{(i)}$ using the same key derivation functions. % \item The customer computes $B^{(i)} := B_{b^{(i)}}(\FDH_K(C^{(i)}_p))$ - for $i \in \{1,\ldots,\kappa\}$ and sends a commitment + for $i \in \{1,\ldots,\kappa\}$ and sends a signed commitment $S_{C'}(\vec{B}, \vec{T_p})$ to the exchange. \item % [200 OK / 409 CONFLICT] The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and - marks $C'_p$ as spent by committing - $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$ to disk. + marks $C'_p$ as spent by persisting + $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$. Auditing processes should assure that $\gamma$ is unpredictable until this time to prevent the exchange from assisting tax evasion. \\ % The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where $K'$ is the exchange's message signing key, thereby committing the exchange to $\gamma$. \item % [POST {\tt /refresh/reveal}] - The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk. + The customer persists $\langle C', S_K(C'_p, \gamma) \rangle$. Also, the customer assembles $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$ and sends $S_{C'}(\mathfrak{R})$ to the exchange. @@ -937,7 +969,7 @@ than the comparable use of zk-SNARKs in ZeroCash~\cite{zerocash}. \begin{align*} \overline{T_p^{(i)}} :&= t_s^{(i)} G \\ \overline{b^{(i)}} :&= \FDH_K(\KDF_{\textrm{blinding}}(\overline{L^{(i)}})) \\ - \overline{B^{(i)}} :&= B_{\overline{b^{(i)}}}(\overline{C_p^{(i)}}) + \overline{B^{(i)}} :&= B_{\overline{b^{(i)}}}(\FDH_K\overline{C_p^{(i)}}) \end{align*} \end{minipage} @@ -1048,7 +1080,7 @@ amount of coins in circulation as part of the certification process. \subsection{Refunds} The refresh protocol offers an easy way to enable refunds to -customers, even if they are anonymous. Refunds can be supported +customers, even if they are anonymous. Refunds are supported by including a public signing key of the merchant in the transaction details, and having the customer keep the private key of the spent coins on file. @@ -1105,7 +1137,11 @@ transaction. We ran the Taler exchange v0.0.2 on an Amazon EC2 t2.micro instance (10\% of a Xeon E5-2676 at 2.4 GHz) based on Ubuntu 14.04.4 LTS, using -a db.t2.micro instance with Postgres 9.5 for the database. Using 16 +a db.t2.micro instance with Postgres 9.5 for the database. We used +1024-bit RSA keys for blind signatures, Curve25519 for DH, EdDSA +for non-blind signatures and SHA-512 for hashing. For the KDF and +FDH operations we used~\cite{rfc5869} with SHA-512 as XTR and SHA-256 +for PRF as suggested in~\cite{rfc5869}. Using 16 concurrent clients performing withdraw, deposit and refresh operations we then pushed the t2.micro instance to the resource limit %(Figure~\ref{fig:cpu}) @@ -1269,7 +1305,7 @@ during the cut-and-choose protocol. Bold-face is used to indicate a vector over these elements. A line above indicates a value computed by the verifier during the cut-and-choose operation. We use $f()$ to indicate the application of a function $f$ to one or more arguments. Records of -data being committed to disk are represented in between $\langle\rangle$. +data being persisted are represented in between $\langle\rangle$. \begin{description} \item[$K_s$]{Denomination private (RSA) key of the exchange used for coin signing} @@ -1403,7 +1439,7 @@ coin first. $\langle S_M(m, f), \vec{X} \rangle$ containing the price of the offer $f$, a transaction ID $m$ and the list of exchanges $\vec{X} = \langle X_1, \ldots, X_n \rangle$ accepted by the merchant, - where each $X_j$ is a exchange's public key. + where each $X_j$ is an exchange's public key. \item\label{lock2} The customer must possess or acquire a coin $\widetilde{C}$ signed by a exchange that is accepted by the merchant, i.e.\ $K$ should be signed by some $X_j$ and has a value $\geq f$. @@ -1423,27 +1459,27 @@ coin first. spending to the customer. If double spending is not found, - the exchange commits $\langle \mathcal{L} \rangle$ to disk + the exchange persists $\langle \mathcal{L} \rangle$ and notifies the merchant that locking was successful. \item\label{contract2} The merchant creates a digitally signed contract $\mathcal{A} := S_M(m, f, a, H(p, r))$ where $a$ is data relevant to the contract indicating which services or goods the merchant will deliver to the customer, and $p$ is the merchant's payment information (e.g. his IBAN number) and $r$ is an random nonce. - The merchant commits $\langle \mathcal{A} \rangle$ to disk and sends it to the customer. + The merchant persists $\langle \mathcal{A} \rangle$ and sends it to the customer. \item The customer creates a - \emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, \widetilde{L}, f, m, M_p, H(a), H(p, r))$, commits - $\langle \mathcal{A}, \mathcal{D} \rangle$ to disk and sends $\mathcal{D}$ to the merchant. -\item\label{invoice_paid2} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk. + \emph{deposit-permission} $\mathcal{D} := S_c(\widetilde{C}, \widetilde{L}, f, m, M_p, H(a), H(p, r))$, persists + $\langle \mathcal{A}, \mathcal{D} \rangle$ and sends $\mathcal{D}$ to the merchant. +\item\label{invoice_paid2} The merchant persists the received $\langle \mathcal{D} \rangle$. \item The merchant gives $(\mathcal{D}, p, r)$ to the exchange, revealing his payment information. \item The exchange verifies $(\mathcal{D}, p, r)$ for its validity and checks against double spending, while of course permitting the merchant to withdraw funds from the amount that had been locked for this merchant. - \item If $\widetilde{C}$ is valid and no equivalent \emph{deposit-permission} for $\widetilde{C}$ and $\widetilde{L}$ exists on disk, the + \item If $\widetilde{C}$ is valid and no equivalent \emph{deposit-permission} for $\widetilde{C}$ and $\widetilde{L}$ exists, the exchange performs the following transaction: \begin{enumerate} - \item $\langle \mathcal{D}, p, r \rangle$ is committed to disk. + \item $\langle \mathcal{D}, p, r \rangle$ is persisted. \item\label{transfer2} transfers an amount of $f$ to the merchant's bank account given in $p$. The subject line of the transaction to $p$ must contain $H(\mathcal{D})$. @@ -1470,11 +1506,11 @@ incremental amount up to $f_{max}$: the merchant has received a deposit-permission for $f$ from the previous contract \textit{i.e.}~$f