[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[taler-exchange] branch master updated: more figures
From: |
gnunet |
Subject: |
[taler-exchange] branch master updated: more figures |
Date: |
Sun, 12 Jul 2020 20:01:00 +0200 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository exchange.
The following commit(s) were added to refs/heads/master by this push:
new 4c1c8e40 more figures
4c1c8e40 is described below
commit 4c1c8e405bdba1fafbf5cfb318b92b460e3f4855
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Jul 12 20:00:56 2020 +0200
more figures
---
doc/system/taler/coin.dot | 47 ++++++++++++++
doc/system/taler/coin.pdf | Bin 0 -> 17066 bytes
doc/system/taler/deposit.dot | 31 +++++++++
doc/system/taler/deposit.pdf | Bin 0 -> 15174 bytes
doc/system/taler/design.tex | 125 +++++++++++++++++++++++++++++++-----
doc/system/taler/implementation.tex | 2 +-
6 files changed, 189 insertions(+), 16 deletions(-)
diff --git a/doc/system/taler/coin.dot b/doc/system/taler/coin.dot
new file mode 100644
index 00000000..ab1f8139
--- /dev/null
+++ b/doc/system/taler/coin.dot
@@ -0,0 +1,47 @@
+digraph Coin {
+
+ planchet [color=blue, shape="box"];
+ fresh [color=blue, label="fresh coin", shape="box"];
+ rs [color=blue, label="refresh session", shape="box"];
+ partial [color=blue, label="dirty coin", shape="box"];
+ revoked [color=blue, label="revoked coin", shape="box"];
+ zombie [color=blue, label="zombie coin", shape="box"];
+ spent [color=blue, label="spent coin", shape="doublecircle"];
+ expired [color=blue, label="expired coin", shape="doublecircle"];
+
+ subgraph {
+ rank = same; spent; expired;
+ }
+
+ subgraph {
+ withdraw; melt;
+ }
+
+ subgraph {
+ rank = same; melt; reveal; rs;
+ }
+
+
+ planchet->withdraw;
+ planchet->melt;
+ withdraw->fresh;
+ fresh->deposit;
+ fresh->melt;
+ deposit->partial;
+ deposit->spent;
+ melt->rs;
+ rs->reveal;
+ reveal->fresh;
+ melt->partial;
+ melt->spent;
+ spent->refund;
+ refund->partial;
+ partial->expired [style=dotted];
+ partial->melt;
+ partial->deposit [color=red];
+ fresh->expired [style=dotted];
+ fresh->revoked [style=dotted];
+ revoked->recoup;
+ recoup->zombie;
+ zombie->melt;
+}
diff --git a/doc/system/taler/coin.pdf b/doc/system/taler/coin.pdf
new file mode 100644
index 00000000..a5590b75
Binary files /dev/null and b/doc/system/taler/coin.pdf differ
diff --git a/doc/system/taler/deposit.dot b/doc/system/taler/deposit.dot
new file mode 100644
index 00000000..bfe8c3bd
--- /dev/null
+++ b/doc/system/taler/deposit.dot
@@ -0,0 +1,31 @@
+digraph Deposit {
+
+ deposited [color=blue, label="deposit created", shape="box"];
+ ready [color=blue, label="deposit ready", shape="box"];
+ due [color=blue, label="deposit due", shape="box"];
+ tiny [color=blue, label="deposit tiny", shape="box"];
+ done [color=blue, label="deposit done", shape="doublecircle"];
+ wtid [color=blue, label="pending transfer", shape="box"];
+ finished [color=blue, label="finished transfer", shape="doublecircle"];
+
+ subgraph {
+ rank = same; due; tiny;
+ }
+
+ pay->deposited;
+ deposited->ready [style=dotted];
+ deposited->refund;
+ refund->deposited;
+ refund->ready;
+ refund->done;
+ ready->due [style=dotted];
+ ready->refund;
+ aggregate->tiny;
+ due->aggregate;
+ ready->aggregate;
+ tiny->aggregate;
+ aggregate->done;
+ aggregate->wtid;
+ wtid->transfer;
+ transfer->finished;
+}
diff --git a/doc/system/taler/deposit.pdf b/doc/system/taler/deposit.pdf
new file mode 100644
index 00000000..f66e3bd5
Binary files /dev/null and b/doc/system/taler/deposit.pdf differ
diff --git a/doc/system/taler/design.tex b/doc/system/taler/design.tex
index ff43376a..0d248407 100644
--- a/doc/system/taler/design.tex
+++ b/doc/system/taler/design.tex
@@ -150,16 +150,19 @@ funds. If a wire transfer to the exchange does not
include a valid reserve publ
the exchange transfers the money back to the sender.
Figure~\ref{fig:reserve:state} illustrates the state machine for a reserve.
-Long-terms states are shown in boxes, while actions are in circles. The
-final state is in a double-circle.
-A reserve is first {\em filled} by a wire transfer. The amount in it is reduced
-by withdraw operations. If the balance reaches zero, the reserve is
-{\em drained}. If a reserve is not drained after a certain amount of time,
-it is automatically closed. A reserve can also be filled via a recoup
-action in case that the denomination of an unspent coin that was
-withdrawn from the reserve is revoked.
+Long-terms states are shown in boxes, while actions are in circles. The final
+state is in a double-circle. A reserve is first {\em filled} by a wire
+transfer. The amount in it is reduced by withdraw operations. If the balance
+reaches zero, the reserve is {\em drained}. If a reserve is not drained after
+a certain amount of time, it is automatically closed. A reserve can also be
+filled via a recoup action (see Section~\ref{sec:revocation-recoup}) in case
+that the denomination of an unspent coin that was withdrawn from the reserve
+is revoked.
+
\begin{figure}
- \includegraphics{reserve.pdf}
+ \begin{center}
+ \includegraphics{taler/reserve.pdf}
+ \end{center}
\caption{State machine of a reserve.}
\label{fig:reserve:states}
\end{figure}
@@ -261,11 +264,13 @@ deposit confirmation or an error that indicates double
spending.
When a coin is used in a completed or attempted/aborted payment, the coin's
public key is revealed to the merchant/exchange, and further payments with the
remaining amount would be linkable to the first spending event. To obtain
-unlinkable change for a partially spent (or otherwise revealed coin), GNU Taler
-introduces a \emph{refresh protocol}. The refresh protocol allows the customer
-to obtain new coins for the remaining amount on a coin. The old coin is marked
-as spent after it has been refreshed into new coins. Using blind signatures to
-withdraw the refreshed coins makes them unlinkable from the old coin.
+unlinkable change for a partially spent (or otherwise revealed coin), GNU
+Taler introduces the \emph{refresh protocol}, which consists of three steps:
+\emph{melt}, \emph{reveal} and \emph{link}. The refresh protocol allows the
+customer to obtain new coins for the remaining amount on a coin. The old coin
+is marked as spent after it has been melted, while the reveal step generates
+the fresh coins. Using blind signatures to withdraw the refreshed coins makes
+them unlinkable from the old coin.
% FIXME: talk about logarithmic time, simulation
@@ -317,6 +322,7 @@ over the funds. A useful application for sharing are
peer-to-peer payments
between mutually trusting parties, such as families and friends.
\subsection{Aggregation}
+
For each payment, the merchant can specify a deadline before which the exchange
must issue a wire transfer to the merchant's bank account. Before this
deadline occurs, multiple payments from deposited coins to the same merchant
@@ -326,8 +332,38 @@ transaction. To incentivize merchants to choose a longer
wire transfer
deadline, the exchange can charge the merchant a fee per aggregated wire
transfer.
+Figure~\ref{fig:deposit:states} illustrates the state machine for processing
+deposits. Long-terms states are shown in boxes, while actions are in circles.
+The final state is in a double-circle. Dashed arrows show transitions based
+on timing and not external actions. A deposit is first {\em created} when a
+wallet makes a payment. A deposit comes with a {\em refund deadline}, and the
+wire transfer must not happen before that deadline. Once the refund deadline
+has passed, the deposit becomes {\em ready}. Even if a deposit is ready, it
+is not automatically wired. In fact, deposits may still be {\em refunded} in
+this state. A refund may be full (resulting in the deposit being {\em done})
+or partial, in which case the remaining value is left in the same deposit
+state. A deposit comes with a second deadline, the {\em wire deadline}. Once
+that deadline has passed, the deposit is {\em due} and must be {\em
+ aggregated}. Aggregation combines {\bf all} deposits that are {\em due},
+{\em tiny} or {\em ready} into one wire transfer. However, the amount of even
+an aggregated deposit may be too small to be executed by the banking
+system. In this case, the deposit transitions into the special state {\em
+ tiny} until the aggregated amount meets the amount threshold. Once
+aggregated, the deposits are {\em done}. A wire transfer is first prepared
+and then {\em pending}. The transfer is {\em finished} once the bank has
+confirmed the {\em transfer}.
+
+\begin{figure}
+ \begin{center}
+ \includegraphics[scale=0.8]{taler/deposit.pdf}
+ \end{center}
+ \caption{State machine of a deposit.}
+ \label{fig:deposit:states}
+\end{figure}
+
\subsection{Refunds}
+
The aggregation period also opens the opportunity for cheap \emph{refunds}. If
a customer is not happy with their product, the merchant can instruct the
exchange to give the customer a refund before the wire transfer deadline has
@@ -335,10 +371,10 @@ occurred. This effectively ``undoes'' the deposit of the
coin, and restores the
available amount left on it. The refresh protocol is then used by the customer
on the coins involved in a refund, so that payments remain unlinkable.
-
% FIXME: mention EU customer laws / 14 weeks?
\subsection{Fees}
+
In order to subsidize the operation of the exchange and enable a sustainable
business model, the exchange can charge fees for most operations. For
withdrawal, refreshing, deposit and refunds, the fee is dependent on the
denomination,
@@ -374,6 +410,7 @@ the total expected amount that it needs to pay for wire
fees.
\subsection{The Withdraw Loophole and Tipping}\label{taler:design:tipping}
+
The withdraw protocol can be (ab)used to illicitly transfer money, when the
receiver generates the coin's secret key, and gives the public key to the party
executing the withdraw protocol. We call this the ``withdraw loophole''. This
@@ -437,12 +474,14 @@ financial regulator, fulfilling the following
functionality:
% FIXME: discuss indian merchant scenario
\subsection{Exchange Compromise Modes}
+
The exchange is an attractive target for hackers and insider threats. We now
discuss different ways that the exchange can be compromised, how to reduce the
likelihood of such a compromise, and how to detect and react to such an event
if it happens.
\subsubsection{Compromise of Denomination Keys and
Revocation}\label{sec:revocation-recoup}
+
When a denomination key pair is compromised, an attacker can ``print money'' by
using it to sign coins of that denomination. An exchange (or its auditor) can
detect this when the number of deposits for a certain denomination exceed the
@@ -512,7 +551,10 @@ pre-programmed with a limit on the number of signatures it
can produce. This
might be mandated by certain auditors, who will also audit the operational
security of an exchange as part of the certification process.
+
+
\subsubsection{Compromise of Signing Keys}
+
When a signing key is compromised, the attacker can pretend to be a
merchant and forge deposit confirmations. To forge a deposit
confirmation, the attacker also needs to get a customer to sign a
@@ -594,6 +636,7 @@ probabilistic deposit auditing, and honest merchants have
proper
incentives to participate in the process.
\subsubsection{Compromise of the Database}
+
If an adversary would be able to modify the exchange, this would be detected
rather quickly by the auditor, provided that the database has appropriate
integrity mechanisms. An attacker could also prevent database updates to block
@@ -602,6 +645,7 @@ equivalent to the compromise of signing keys, and can be
detected with the same
strategies.
\subsubsection{Compromise of the Master Key}
+
If the master key was compromised, an attacker could de-anonymize customers by
announcing different sets of denomination keys to each of them. If the
exchange was audited, this would be detected quickly, as these denominations
@@ -669,6 +713,57 @@ that they cannot immediately spend. Unfortunately our
approach is limited to a
kidnapping scenario, and not applicable in those blackmail scenarios where the
attacker can do damage after they find out that their funds have been erased.
+\subsection{Summary}
+
+Figure~\ref{fig:coin:states} illustrates the overall state machine for
processing
+coins. Long-terms states are shown in boxes, while actions are in circles.
+The final state is in a double-circle. Dashed arrows show transitions based
+on timing and not external actions. The red arrow shows an action that is
+allowed by the exchange but should never be done by wallets as it would
+break unlinkability.
+
+A coin begins as an unsigned {\em planchet}, which is either signed as part of
+the {\em withdraw} protocol or the refresh protocol. The most common scenario
+is that the {\em fresh coin} is {\em deposited}. This payment creates a
+deposit (see Figure~\ref{fig:deposit:states}) and either a {\em dirty coin}
+(if the payment was for a fraction of the coin's value) or a {\em spent coin}.
+A spent coin can be {\em refunded} by the merchant (until the deposit is due),
+creating a {\em dirty coin}.
+
+A {\em fresh coin} may also be subject to key {\em revocation}, at which point
+the wallet ends up with a {\em revoked coin}. At this point, the wallet can
+use the {\em recoup} protocol to recover the value of the coin. If the coin
+originated from a {\em withdraw} operation, the value is added back into the
+reserve, which is {\em filled} in the process (see
+Figure~\ref{fig:reserve:states}). If the coin originated from the {\em
+ refresh} operation, this results in the old coin turning into a {\em zombie
+ coin}, which can be refreshed again.
+
+Dirty coins and fresh coins can be {\em melted}. Dirty coins should always be
+melted automatically by the wallet as soon as possible as this is the only
+good way to use them while preserving unlinkability. A wallet should also
+automatically {\em melt} any {\em fresh coins} that are in danger of their
+denomination key nearing its (deposit) {\em expiration} time. If a wallet
+fails to do so, coins may {\em expire}, resulting in a loss for the coin's
+owner. Dirty coins can also expire. In practice, this happens if the melt fee
+exceeds the residual value of the dirty coin. To {\em melt} a coin, the
+wallet must commit to one or more {\em planchets} and then demonstrate honesty
+when the committment made for the {\em refresh session} is checked during the
+{\em reveal} step. If the wallet was honest, {\em reveal} yields {\em fresh
+ coins}.
+
+\begin{figure}
+ \begin{center}
+ \includegraphics[scale=0.75]{taler/coin.pdf}
+ \end{center}
+ \caption{State machine of a coin.}
+ \label{fig:coin:states}
+\end{figure}
+
+
+
+
+
\section{Related Work}
% FIXME: Stuff to review/include:
% Blindly Signed Contracts: Anonymous On-Blockchain and Off-Blockchain Bitcoin
Transactions
diff --git a/doc/system/taler/implementation.tex
b/doc/system/taler/implementation.tex
index e9fdf799..f386228f 100644
--- a/doc/system/taler/implementation.tex
+++ b/doc/system/taler/implementation.tex
@@ -907,7 +907,7 @@ The following APIs are offered by the exchange:
the merchant additionally can use the exchange's
\texttt{/transfers/\$WTID} API that returns the list of deposits for a wire
transfer
identifier (WTID) included in the wire transfer to the merchant, as well
as the
\texttt{/deposits/\$H\_WIRE/\$MERCHANT\_PUB/\$H\_CONTRACT\_TERMS/\$COIN\_PUB}
API to look up
which wire transfer included the payment for a given deposit.
- \item[Refresh] Refreshing consists of two stages. First, using
\texttt{/coins/\$COIN\_PUB/melt} an old, possibly dirty coin is melted and thus
devaluted. The committment made by the wallet during the melt and the resulting
$\gamma$-challenge from the exchange are associated with a {\em refresh
session}. Then, using \texttt{/refreshes/$RCH/reveal} the wallet can answer
the challenge and obtain fresh coins as change. Finally,
\texttt{/coins/\$COIN\_PUB/link} provides the link deterrent [...]
+ \item[Refresh] Refreshing consists of two stages. First, using
\texttt{/coins/\$COIN\_PUB/melt} an old, possibly dirty coin is melted and thus
devaluted. The committment made by the wallet during the melt and the resulting
$\gamma$-challenge from the exchange are associated with a {\em refresh
session}. Then, using \texttt{/refreshes/\$RCH/reveal} the wallet can answer
the challenge and obtain fresh coins as change. Finally,
\texttt{/coins/\$COIN\_PUB/link} provides the link deterren [...]
\item[Refunds] The refund API (\texttt{/coins/\$COIN\_PUB/refund}) can
``undo'' a deposit if the merchant gave their signature, and the aggregation
deadline
for the payment has not occurred yet.
\item[Recoup] The recoup API (\texttt{/coins/\$COIN\_PUB/recoup}) allows
customers to be compensated
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [taler-exchange] branch master updated: more figures,
gnunet <=