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

Corrections on section 4

Browse Source
This commit is contained in:
Jeff Burdges 2015-10-13 18:39:43 +02:00
parent 99865ad6d4
commit 47b4193317
1 changed files with 103 additions and 97 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

200
doc/paper/taler.tex
View File

@ -203,7 +203,7 @@ We give a concise example of how these properties interact:
A customer may want to pay \EUR{49,99} using a \EUR{100,00} coin. A customer may want to pay \EUR{49,99} using a \EUR{100,00} coin.
the system must thus support giving change in the form of spendable coins, the system must thus support giving change in the form of spendable coins,
say a \EUR{0,01} coin and a \EUR{50,00} coin. say a \EUR{0,01} coin and a \EUR{50,00} coin.
A merchant cannot simply give the customer their coins in another transaction, A merchant cannot simply give the customer their coins in another transaction;
however, as this reverses the role of merchant and customer, and however, as this reverses the role of merchant and customer, and
our taxability requirement would deanonymize the customer. The customer our taxability requirement would deanonymize the customer. The customer
also cannot withdraw exact change from his account from the mint, as this also cannot withdraw exact change from his account from the mint, as this
@ -642,20 +642,19 @@ construct a transaction.
% In this section, we describe the protocols for Taler in detail. % In this section, we describe the protocols for Taler in detail.
For the sake of brevity, we assume that a recipient of a signed We shall assume for the sake of brevity that a recipient of a signed
message always first checks that the signature is valid, even though message always first checks that the signature is valid, aborting the
this is not explicitly stated below. Also, whenever a signed message operation if not. Additionally, we assume that the receiver of a
is transmitted, it is assumed that the receiver is told the public key signed message is either told the public key, or knows it from the
(or knows it from the context) and that the signature contains context, and that the signature contains additional identification as
additional identification as to the purpose of the signature, making to the purpose of the signature, making it impossible to use a signature
it impossible to use a signature in a different context. in a different context.
When the mint signs messages (not coins), an {\em online message The mint has an {\em online message signing key} used for signing
signing key} of the mint is used. The mint's long-term offline key messages, as opposed to coins. The mint's long-term offline key is used
is used to certify both the coin signing keys as well as the online to certify both the coin signing keys and the online message signing key
message signing key of the mint. The mint's long-term offline key is of the mint. The mint's long-term offline key is assumed to be known to
assumed to be well-known to both customers and merchants, for example both customers and merchants and is certified by the auditors.
because it is certified by the auditors.
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 commit data to persistent storage.
@ -667,10 +666,9 @@ date; information committed to disk can be discarded after the
expiration date of the respective public key. Customers can also expiration date of the respective public key. Customers can also
discard information once the respective coins have been fully spent, discard information once the respective coins have been fully spent,
and merchants may discard information once payments from the mint have and merchants may discard information once payments from the mint have
been received (assuming records are also no longer needed for tax been received, assuming the records are also no longer needed for tax
authorities). The mint's bank transfers dealing in traditional purposes. The mint's bank transfers dealing in traditional currency
currency are expected to be recorded for tax authorities to ensure are expected to be recorded for tax authorities to ensure taxability.
taxability.
\subsection{Withdrawal} \subsection{Withdrawal}
@ -687,7 +685,7 @@ the mint:
\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 commits $\langle W, C, b \rangle$ to disk.
\end{itemize} \end{itemize}
\item The customer transfers an amount of money corresponding to (at least) $K_p$ to the mint, with $W_p$ in the subject line of the transaction. \item The customer transfers an amount of money corresponding to at least $K_p$ to the mint, with $W_p$ in the subject line of the transaction.
\item The mint receives the transaction and credits the $W_p$ reserve with the respective amount in its database. \item The mint receives the transaction and credits the $W_p$ reserve with the respective amount in its database.
\item The customer sends $S_W(B_b(C_p))$ to the mint to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with blinding factor $b$. \item The customer sends $S_W(B_b(C_p))$ to the mint to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with blinding factor $b$.
\item The mint checks if the same withdrawal request was issued before; in this case, it sends $S_{K}(B_b(C_p))$ to the customer.\footnote{Here $S_K$ \item The mint checks if the same withdrawal request was issued before; in this case, it sends $S_{K}(B_b(C_p))$ to the customer.\footnote{Here $S_K$
@ -700,10 +698,10 @@ the mint:
\end{enumerate} \end{enumerate}
and then sends $S_{K}(B_b(C_p))$ to the customer. and then sends $S_{K}(B_b(C_p))$ to the customer.
If the guards for the transaction fail, the mint sends a descriptive error back to the customer, If the guards for the transaction fail, the mint sends a descriptive error back to the customer,
with proof that it operated correctly (i.e. by showing the transaction history for the reserve). with proof that it operated correctly.
\item The customer computes (and verifies) the unblinded signature $S_K(C_p) = U_b(S_K(B_b(C_p)))$. Assuming the signature was valid, this would involve showing the transaction history for the reserve.
The customer writes $\langle S_K(C_p), c_s \rangle$ to disk (effectively adding the coin to the \item The customer computes and verifies the unblinded signature $S_K(C_p) = U_b(S_K(B_b(C_p)))$.
local wallet) for future use. The customer saves the coin $\langle S_K(C_p), c_s \rangle$ to local wallet on disk.
\end{enumerate} \end{enumerate}
We note that the authorization to create and access a reserve using a We note that the authorization to create and access a reserve using a
withdrawal key $W$ is just one way to establish that the customer is withdrawal key $W$ is just one way to establish that the customer is
@ -719,36 +717,33 @@ merchant trusts the specific mint that minted the coin. Merchants are
identified by their key $M := (m_s, M_p)$ where the public key $M_p$ identified by their key $M := (m_s, M_p)$ where the public key $M_p$
must be known to the customer a priori. must be known to the customer a priori.
The following steps describe the protocol between customer, merchant and mint We now describe the protocol between the customer, merchant, and mint
for a transaction involving a coin $C := (c_s, C_p)$, which was previously signed for a transaction in which the customer spends a coin $C := (c_s, C_p)$
by a mint's denomination key $K$, i.e. the customer possesses with signature $\widetilde{C} := S_K(C_p)$
$\widetilde{C} := S_K(C_p)$: where $K$ is the mint's demonination key.
\begin{enumerate} \begin{enumerate}
\item\label{contract} Let $\vec{D} := D_1, \ldots, D_n$ be the list of \item\label{contract}
mints accepted by the merchant where each $D_j$ is a mint's public Let $\vec{D} := D_1, \ldots, D_n$ be the list of mints accepted by
key. The merchant creates a digitally signed contract $\mathcal{A} the merchant where each $D_j$ is a mint's public key.
:= S_M(m, f, a, H(p, r), \vec{D})$ where $m$ is an identifier for this The merchant creates a digitally signed contract
transaction, $a$ is data relevant to the contract indicating which services $\mathcal{A} := S_M(m, f, a, H(p, r), \vec{D})$
or goods the merchant will deliver to the customer, $f$ is the price of the offer, where $m$ is an identifier for this transaction, $a$ is data relevant
and $p$ is the merchant's payment information (e.g. his IBAN number) and $r$ is to the contract indicating which services or goods the merchant will
a random nonce. The merchant commits $\langle \mathcal{A} deliver to the customer, $f$ is the price of the offer, and
\rangle$ to disk and sends $\mathcal{A}$ to the customer. $p$ is the merchant's payment information (e.g. his IBAN number), and
\item\label{deposit} The customer must possess or acquire a coin minted by a mint that is $r$ is a random nonce. The merchant commits $\langle \mathcal{A} \rangle$
accepted by the merchant, i.e. $K$ should be publicly signed by some $D_j to disk and sends $\mathcal{A}$ to the customer.
\in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$. (The customer \item\label{deposit}
can of course also use multiple coins where the total value adds up to The customer should already possess a coin minted by a mint that is
the cost of the transaction and run the following steps for each of accepted by the merchant, meaning $K$ should be publicly signed by
the coins. However, for simplicity of the exposition here we will some $D_j \in \{D_1, D_2, \ldots, D_n\}$, and has a value $\geq f$.
assume that one coin is sufficient.) \item The customer generates a \emph{deposit-permission} $\mathcal{D} :=
%
The customer then generates a \emph{deposit-permission} $\mathcal{D} :=
S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$ S_c(\widetilde{C}, m, f, H(a), H(p,r), M_p)$
and sends $\langle \mathcal{D}, D_j\rangle$ to the merchant, and sends $\langle \mathcal{D}, D_j\rangle$ to the merchant,
where $D_j$ is the mint which signed $K$. where $D_j$ is the mint which signed $K$.
\item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing $p$ \item The merchant gives $(\mathcal{D}, p, r)$ to the mint, revealing $p$
only to the mint. only to the mint.
\item The mint validates $\mathcal{D}$ and checks for double spending. \item The mint validates $\mathcal{D}$ and checks for double spending.
If the coin has been involved in previous transactions and the new If the coin has been involved in previous transactions and the new
one would exceed its remaining value, it sends an error one would exceed its remaining value, it sends an error
@ -756,15 +751,21 @@ $\widetilde{C} := S_K(C_p)$:
% %
If double spending is not found, the mint commits $\langle \mathcal{D} \rangle$ to disk If double spending is not found, the mint commits $\langle \mathcal{D} \rangle$ to disk
and notifies the merchant that the deposit operation was successful. and notifies the merchant that the deposit operation was successful.
\item The merchant commits and forwards the notification from the mint to the \item The merchant commits and forwards the notification from the mint to the
customer, confirming the success (or failure) of the operation. customer, confirming the success or failure of the operation.
\end{enumerate} \end{enumerate}
We have simplified the exposition by assuming that one coin suffices, but
in practice a customer can use multiple coins from the same mint where
the total value adds up to $f$ by running the following steps for
each of the coins. There is a risk of metadata leakage if a customer
acquires a coin in responce to the merchant, or if a customer uses
coings issued by multiple mints together.
If a transaction is aborted after Step~\ref{deposit}, If a transaction is aborted after Step~\ref{deposit},
subsequent transactions with the same coin could be linked to the coin, subsequent transactions with the same coin could be linked to the coin,
but not directly to the coin's owner. The same applies to partially but not directly to the coin's owner. The same applies to partially
spent coins (where $f$ is smaller than the actual value of the coin). spent coins where $f$ is smaller than the actual value of the coin.
To unlink subsequent transactions from a coin, the customer has to To unlink subsequent transactions from a coin, the customer has to
execute the coin refreshing protocol with the mint. execute the coin refreshing protocol with the mint.
@ -803,34 +804,40 @@ execute the coin refreshing protocol with the mint.
\subsection{Refreshing} \label{sec:refreshing} \subsection{Refreshing} \label{sec:refreshing}
The following refreshing protocol is executed in order to melt a dirty We now describe the refresh protocol whereby a dirty coin $C'$ of
coin $C'$ of denomination $K$ to obtain a fresh coin $\widetilde{C}$ denomination $K$ is melted to obtain a fresh coin $\widetilde{C}$
with the same denomination. In practice, Taler uses a natural with the same denomination. In practice, Taler uses a natural
extension where multiple fresh coins are generated a the same time to extension where multiple fresh coins are generated a the same time to
enable giving precise change matching any amount. In the enable giving precise change matching any amount.
protocol, $\kappa \ge 3$ is a security parameter and $G$ is the In the protocol, $\kappa \ge 3$ is a security parameter and $G$ is the
generator of the elliptic curve. generator of the elliptic curve.
\begin{enumerate} \begin{enumerate}
\item For each $i = 1,\ldots,\kappa$, the customer randomly generates \item For each $i = 1,\ldots,\kappa$, the customer randomly generates
\begin{itemize} \begin{itemize}
\item transfer key $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$ where $T^{(i)}_p := t^{(i)}_s G$, \item transfer key $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$
\item coin key pair \\ $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$ where $C^{(i)}_p := c^{(i)}_s G$, where $T^{(i)}_p := t^{(i)}_s G$,
\item coin key pair $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$
where $C^{(i)}_p := c^{(i)}_s G$, and
\item blinding factors $b^{(i)}$. \item blinding factors $b^{(i)}$.
\end{itemize} \end{itemize}
The customer then computes $E^{(i)} := E_{K_i}\left(c_s^{(i)}, b^{(i)}\right)$ where $K_i := H(c'_s T_p^{(i)})$. (The encryption key $K_i$ is The customer then computes
computed by multiplying the private key $c'_s$ of the original coin with the point on the curve $E^{(i)} := E_{K_i}\left(c_s^{(i)}, b^{(i)}\right)$
that represents the public key $T^{(i)}_p$ of the transfer key $T^{(i)}$. This is basically DH between coin and transfer key.), where $K_i := H(c'_s T_p^{(i)})$, and
and commits $\langle C', \vec{T}, \vec{C}, \vec{b} \rangle$ to disk. commits $\langle C', \vec{T}, \vec{C}, \vec{b} \rangle$ to disk.
Our computation of $K_i$ is a effectively a Diffie-Hellman operation
between the private key $c'_s$ of the original coin with
the public transfer key $T_p^{(i)}_p$.
\item The customer computes $B^{(i)} := B_{b^{(i)}}(C^{(i)}_p)$ for $i \in \{1,\ldots,\kappa\}$ and sends a commitment \item The customer computes $B^{(i)} := B_{b^{(i)}}(C^{(i)}_p)$ for $i \in \{1,\ldots,\kappa\}$ and sends a commitment
$S_{C'}(\vec{E}, \vec{B}, \vec{T_p}))$ to the mint. $S_{C'}(\vec{E}, \vec{B}, \vec{T_p}))$ to the mint.
\item The mint generates a random\footnote{Auditing processes need to assure $\gamma$ is unpredictable until this time to \item The mint generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
prevent the mint from assisting tax evasion.} $\gamma$ with $1 \le \gamma \le \kappa$ and
marks $C'_p$ as spent by committing marks $C'_p$ as spent by committing
$\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T}) \rangle$ to disk. $\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T}) \rangle$ to disk.
\item The mint sends $S_K(C'_p, \gamma)$ to the customer.\footnote{Instead of $K$, it is also Auditing processes should assure that $\gamma$ is unpredictable until
possible to use any equivalent mint signing key known to the customer here, as $K$ merely this time to prevent the mint from assisting tax evasion.
serves as proof to the customer that the mint selected this particular $\gamma$.} \item The mint sends $S_{K'}(C'_p, \gamma)$ to the customer where
$K'$ is the mint's message signing key.
\item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk. \item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk.
\item The customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$ \item The customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
and sends $S_{C'}(\mathfrak{R})$ to the mint. and sends $S_{C'}(\mathfrak{R})$ to the mint.
@ -920,31 +927,30 @@ client should record the interaction and enable the user to file a
bug report. bug report.
The second case is a faulty mint service provider. Such faults will The second case is a faulty mint service provider. Such faults will
be detected because of protocol violations (for example, by providing be detected because of protocol violations, such as providing
a faulty proof or no proof). In this case, the client is expected to a faulty proof or no proof. In this case, the client is expected to
notify the auditor, providing a transcript of the interaction. The notify the auditor, providing a transcript of the interaction. The
auditor can then (anonymously) replay the transaction, and either auditor can then anonymously replay the transaction, and either
provide the (now) correct response to the client or take appropriate provide the now correct response to the client or take appropriate
legal action against the faulty provider. legal action against the faulty provider.
The third case are transient failures, such as network failures or The third case are transient failures, such as network failures or
temporary hardware failures at the mint service provider. Here, the temporary hardware failures at the mint service provider. Here, the
client may receive an explicit protocol indication (such as an HTTP client may receive an explicit protocol indication, such as an HTTP
response code 500 ``internal server error'') or simply no response. response code 500 ``internal server error'' or simply no response.
The appropriate behavior for the client is to automatically retry The appropriate behavior for the client is to automatically retry
(after 1s, twice more at randomized times within 1 minute). If those after 1s, and twice more at randomized times within 1 minute.
three attempts fail, the user should be informed about the delay. The If those three attempts fail, the user should be informed about the
client should then retry another three times within the next 24h, and delay. The client should then retry another three times within the
after that time the auditor be informed about the outage. next 24h, and after that time the auditor be informed about the outage.
Using this process, short term failures should be effectively obscured Using this process, short term failures should be effectively obscured
from the user, while malicious behavior is reported to the auditor who from the user, while malicious behavior is reported to the auditor who
can then presumably rectify the situation, for example by shutting can then presumably rectify the situation, such as by shutting down
down the operator (while providing an opportunity for customers to the operator and helping customers to regain refunds for coins in
receive refunds for the coins in circulation). To ensure that such their wallets. To ensure that such refunds are possible, the operator
refunds are possible, the operator is expected to always provide is expected to always provide adequate securities for the amount of
adequate securities for the amount of coins in circulation as part of coins in circulation as part of the certification process.
the certification process.
\subsection{Refunds} \subsection{Refunds}
@ -955,29 +961,29 @@ details, and having the customer keep the private key of the spent
coins on file. coins on file.
Given this, the merchant can simply sign a {\em refund confirmation} Given this, the merchant can simply sign a {\em refund confirmation}
and share it with the mint (and the customer). Assuming the mint has and share it with the mint and the customer. Assuming the mint has
a way to recover the funds from the merchant (or simply not performed a way to recover the funds from the merchant, or has not yet performed
the wire transfer yet), the mint can simply add the value of the the wire transfer, the mint can simply add the value of the refunded
refunded transaction back to the original coin, re-enabling those transaction back to the original coin, re-enabling those funds to be
funds to be spent again by the original customer. spent again by the original customer.
The (anonymous) customer -- but nobody else -- can then use the This anonymous customer can then use the refresh protocol to melt the
refresh protocol to melt the refunded coin and create a fresh coin refunded coin and create a fresh coin that is unlinkable to the
that is unlinkable to the refunded transaction. refunded transaction.
\section{Discussion} \section{Discussion}
Taler's security is largely equivalent to that of Chaum's original Taler's security is largely equivalent to that of Chaum's original
design without online checks (and without the cut-and-choose design without online checks or the cut-and-choose revelation of
revelation of double-spending customers for offline spending). We double-spending customers for offline spending.
specifically note that the digital equivalent of the ``Columbian Black We specifically note that the digital equivalent of the ``Columbian
Market Exchange''~\cite{fatf1997} is a theoretical problem for both Black Market Exchange''~\cite{fatf1997} is a theoretical problem for
Chaum and Taler, as individuals with a strong mutual trust foundation both Chaum and Taler, as individuals with a strong mutual trust
can simply copy electronic coins and thereby establish a limited form foundation can simply copy electronic coins and thereby establish a
of black transfers. However, unlike the situation with physical limited form of black transfers. However, unlike the situation with
checks with blank recipients in the Columbian black market, the physical checks with blank recipients in the Columbian black market,
transitivity is limited as each participant can deposit the electronic the transitivity is limited as each participant can deposit the electronic
coins and thereby cheat any other participant, while in the Columbian coins and thereby cheat any other participant, while in the Columbian
black market each participant only needs to trust the issuer of the black market each participant only needs to trust the issuer of the
check and not also all previous owners of the physical check. check and not also all previous owners of the physical check.