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

edits addressing FC reviews

Browse Source
This commit is contained in:
Christian Grothoff 2017-04-07 14:59:41 +02:00
parent a2d89f2803
commit ef6d9cc56d
No known key found for this signature in database
GPG Key ID: 939E6BE1E29FC3CC
1 changed files with 78 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

120
doc/paper/taler.tex
View File

@ -393,7 +393,29 @@ assures customers and merchants that the exchange operates correctly.
\subsection{Security model} \subsection{Security model}
%\vspace{-0.3cm} %\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 Taler assumes that each participant has full control over their
system. We assume the contact information of the exchange is known to system. We assume the contact information of the exchange is known to
both customer and merchant from the start, including that the customer 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 full domain hash (FDH) to make so-called ``one-more forgery'' attacks
provably hard, assuming the RSA known-target inversion problem is provably hard, assuming the RSA known-target inversion problem is
hard~\cite[Theorem 12]{RSA-HDF-KTIvCTI}. For a withdrawn coin, 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 a random blinding factor from a random element of the group of
integers modulo the denomination key's RSA modulus, which appears integers modulo the denomination key's RSA modulus, which appears
impossible even with a quantum computers. For a refreshed coin, 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. denomination keys.
As we are dealing with financial transactions, we explicitly describe As we are dealing with financial transactions, we explicitly describe
whenever entities need to safely commit data to persistent storage. whenever entities need to safely write data to persistent storage.
As long as those commitments persist, the protocol can be safely As long as the data persists, the protocol can be safely
resumed at any step. Commitments to disk are cumulative, that is an resumed at any step. Persisting data is cumulative, that is an
additional commitment does not erase the previously committed additional persist operation does not erase the previously stored
information. Keys and thus coins always have a well-known expiration 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. expiration date of the respective public key.
Customers may discard information once the respective coins have been Customers may discard information once the respective coins have been
fully spent, so long as refunds are not required. 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 exchange and one of its public denomination public keys $K_p$ whose
value $K_v$ corresponds to an amount the customer wishes to withdraw. 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$. 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 % FIXME: These steps occur at very different points in time, so probably
% they should be restructured into more of a protocol description. % 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} \begin{enumerate}
\item The customer randomly generates: \item The customer randomly generates:
\begin{itemize} \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 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} \end{itemize}
The customer then transfers an amount of money corresponding to The customer then transfers an amount of money corresponding to
at least $K_v$ to the exchange, with $W_p$ in the subject line 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. history for the reserve.
\item The customer computes the unblinded signature $U_b(S_K(B))$ and \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))$. 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$ Finally the customer persists the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$
to their local wallet on disk. in their local wallet.
\end{enumerate} \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 to the contract indicating which services or goods the merchant will
deliver to the customer, including the merchant specific URI for the payment. 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 $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$ $r$ is a random nonce. The merchant persists $\langle \mathcal{A} \rangle$
to disk and sends $\mathcal{A}$ to the customer. and sends $\mathcal{A}$ to the customer.
\item \item
The customer should already possess a coin $\widetilde{C}$ issued by a exchange that is 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 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 one would exceed its remaining value, it sends an error
with the records from the previous transactions back to the merchant. \\ 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. and signs a message affirming the deposit operation was successful.
\item \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 customer, confirming the success or failure
of the operation. of the operation.
\end{enumerate} \end{enumerate}
@ -859,10 +883,18 @@ protocol with the exchange.
\subsection{Refreshing} \label{sec:refreshing} \subsection{Refreshing} \label{sec:refreshing}
We now describe the refresh protocol whereby a dirty coin $C'$ of We now describe the refresh protocol whereby a dirty coin $C'$ of
denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$ denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$. To
with the same denomination. In practice, Taler uses a natural simplify the description, this section describes the case where one
extension where multiple fresh coins are generated a the same time to {\em unspent} dirty coin (for example, from an aborted transaction) is
enable giving precise change matching any amount. 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 In the protocol, $\kappa \ge 2$ is a security parameter for the
cut-and-choose part of the protocol. $\kappa = 3$ is actually 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 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)})$. \item the new coin secret seed $L^{(i)} := H(c'_s T_p^{(i)})$.
\end{enumerate} \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)$ 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)$; 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. 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)$ $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$
where $C^{(i)}_p := c^{(i)}_s G$. 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$. $\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)}$ We observe that $t^{(i)}_s$ suffices to regenerate $C^{(i)}$ and $b^{(i)}$
using the same key derivation functions. using the same key derivation functions.
% \item % \item
The customer computes $B^{(i)} := B_{b^{(i)}}(\FDH_K(C^{(i)}_p))$ 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. $S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
\item % [200 OK / 409 CONFLICT] \item % [200 OK / 409 CONFLICT]
The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
marks $C'_p$ as spent by committing marks $C'_p$ as spent by persisting
$\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$ to disk. $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$.
Auditing processes should assure that $\gamma$ is unpredictable until Auditing processes should assure that $\gamma$ is unpredictable until
this time to prevent the exchange from assisting tax evasion. \\ this time to prevent the exchange from assisting tax evasion. \\
% %
The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where 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$. $K'$ is the exchange's message signing key, thereby committing the exchange to $\gamma$.
\item % [POST {\tt /refresh/reveal}] \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 Also, the customer assembles
$\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$ $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
and sends $S_{C'}(\mathfrak{R})$ to the exchange. 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*} \begin{align*}
\overline{T_p^{(i)}} :&= t_s^{(i)} G \\ \overline{T_p^{(i)}} :&= t_s^{(i)} G \\
\overline{b^{(i)}} :&= \FDH_K(\KDF_{\textrm{blinding}}(\overline{L^{(i)}})) \\ \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{align*}
\end{minipage} \end{minipage}
@ -1048,7 +1080,7 @@ amount of coins in circulation as part of the certification process.
\subsection{Refunds} \subsection{Refunds}
The refresh protocol offers an easy way to enable refunds to 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 by including a public signing key of the merchant in the transaction
details, and having the customer keep the private key of the spent details, and having the customer keep the private key of the spent
coins on file. coins on file.
@ -1105,7 +1137,11 @@ transaction.
We ran the Taler exchange v0.0.2 on an Amazon EC2 t2.micro instance 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 (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 concurrent clients performing withdraw, deposit and refresh operations
we then pushed the t2.micro instance to the resource limit we then pushed the t2.micro instance to the resource limit
%(Figure~\ref{fig:cpu}) %(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 vector over these elements. A line above indicates a value computed
by the verifier during the cut-and-choose operation. We use $f()$ to 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 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} \begin{description}
\item[$K_s$]{Denomination private (RSA) key of the exchange used for coin signing} \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$, $\langle S_M(m, f), \vec{X} \rangle$ containing the price of the offer $f$,
a transaction ID $m$ and the list of exchanges a transaction ID $m$ and the list of exchanges
$\vec{X} = \langle X_1, \ldots, X_n \rangle$ accepted by the merchant, $\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}$ \item\label{lock2} The customer must possess or acquire a coin $\widetilde{C}$
signed by a exchange that is accepted by the merchant, 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$. 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. spending to the customer.
If double spending is not found, 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. and notifies the merchant that locking was successful.
\item\label{contract2} The merchant creates a digitally signed contract \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 $\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 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. 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 \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 \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$ to disk and sends $\mathcal{D}$ to the merchant. $\langle \mathcal{A}, \mathcal{D} \rangle$ and sends $\mathcal{D}$ to the merchant.
\item\label{invoice_paid2} The merchant commits the received $\langle \mathcal{D} \rangle$ to disk. \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 \item The merchant gives $(\mathcal{D}, p, r)$ to the exchange, revealing his
payment information. payment information.
\item The exchange verifies $(\mathcal{D}, p, r)$ for its validity and \item The exchange verifies $(\mathcal{D}, p, r)$ for its validity and
checks against double spending, while of checks against double spending, while of
course permitting the merchant to withdraw funds from the amount that course permitting the merchant to withdraw funds from the amount that
had been locked for this merchant. 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: exchange performs the following transaction:
\begin{enumerate} \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 \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 given in $p$. The subject line of the transaction to $p$ must contain
$H(\mathcal{D})$. $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 the merchant has received a deposit-permission for $f$ from the previous
contract \textit{i.e.}~$f <f' \leq f_{max}$. Similarly $a'$ is the new contract \textit{i.e.}~$f <f' \leq f_{max}$. Similarly $a'$ is the new
contract data appended to older contract data $a$. contract data appended to older contract data $a$.
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 Customer commits $\langle \mathcal{A}' \rangle$ to disk, creates \item Customer persists $\langle \mathcal{A}' \rangle$, creates
$\mathcal{D}' := S_c(\widetilde{C}, \mathcal{L}, f', m, M_p, H(a'), H(p, r))$, commits $\mathcal{D}' := S_c(\widetilde{C}, \mathcal{L}, f', m, M_p, H(a'), H(p, r))$, persists
$\langle \mathcal{D'} \rangle$ and sends it to the merchant. $\langle \mathcal{D'} \rangle$ and sends it to the merchant.
\item The merchant commits the received $\langle \mathcal{D'} \rangle$ and \item The merchant persists the received $\langle \mathcal{D'} \rangle$ and
deletes the older $\mathcal{D}$. deletes the older $\mathcal{D}$.
\end{enumerate} \end{enumerate}