summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--taler-fc19/paper.tex63
1 files changed, 44 insertions, 19 deletions
diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex
index 5fcc910..81038f0 100644
--- a/taler-fc19/paper.tex
+++ b/taler-fc19/paper.tex
@@ -23,19 +23,17 @@
\begin{abstract}
We present an anonymous e-cash protocol that protects against economic losses
when protocols are aborted. Furthermore, we ensure that customers have
- cryptographic evidence that they
- spent e-cash on a particular business transaction and introduce \emph{conservation}
- as an additional security property to anonymity and unforgeability, and
- preserve anonymity when wallets are restored from
- backup or synchronized with other devices. We argue from this position that
- a protocol for unlinkable change is necessary even in schemes that provide
- divisibility. As a na\"ive implementation of a change protocol opens up the
- possibility of abuse for tax evasion, we define a new \emph{income transparency}
- security property.
+ cryptographic evidence that they spent e-cash on a particular business
+ transaction and introduce \emph{conservation} as an additional security
+ property to anonymity and unforgeability, and preserve anonymity when wallets
+ are restored from backup or synchronized with other devices. We argue from
+ this position that a protocol for unlinkable change is necessary even in
+ schemes that provide divisibility. As a na\"ive implementation of a change
+ protocol opens up the possibility of abuse for tax evasion, we define a new
+ \emph{income transparency} security property.
We furthermore show that an e-cash protocol that fulfills these properties
- can be used to implement Camenisch-style fair exchange, tick payments,
- and
+ can be used to implement Camenisch-style fair exchange, tick payments, and
can be used to provide anonymous refunds.
\keywords{E-cash \and blind signature \and key exchange}
\end{abstract}
@@ -74,10 +72,39 @@
%\theoremstyle{corollary}
%\newtheorem{corollary}{Corollary}[section]
+\section{Introduction}
+Anonymous e-cash, originally invented by Chaum in 1982 \cite{chaum1983blind},
+enables customers to withdraw digital cash tokens from a bank and then
+anonymously spend them with merchants. Cryptographic protocols allow
+the withdrawal of coins to remain unlinkable to the spending operations.
+Coins are either checked online for double-spending, or double-spending
+reveals the identity of the culprit.
+
+In recent years, many advances have been made on e-cash, improving the efficiency
+for withdrawing/spending arbitary values to constant time and proving security
+in the standard model \cite{pointcheval2017cut}. Most attention was given to schemes
+that allow offline spending.
+
+With the rising ubiquity of mobile Internet, IoT and smart phones, online
+e-cash could gain importance, as it does not suffer from the difficulty of
+prosecuting double-spenders or convicting users with faulty hardware as
+double-spenders. On mobile devices, backup and synchronization is especially
+important, and unlike smart-cards that interact with payment terminals or ATMs,
+communication is asynchronous and likely to be interrupted. E-cash protocols
+need to be robust in these failure scenarios and preserve anonymity properties, even
+when the wallet's state is synchronized with other devices or restored from backup.
+
+We describe new security properties for e-cash that preserve anonymity without
+loss of funds in certain failure scenarios, which are made possible with an
+anonymous change protocol \cite{brickell1995trustee}. We improve a na\"ive
+change protocol so that is cannot be used for hiding transaction from tax
+authorities as a merchant.
+
+
\section{Model and Syntax}
We consider a Chaum-style~\cite{chaum1983blind}
-payment system with an exchange (Chaum: mint) and multiple,
+payment system with an exchange (Chaum: bank) and multiple,
dynamically created customers and merchants.
We model withdrawing digital coins, spending them with
merchants and subsequently depositing them at the exchange, as well as
@@ -369,13 +396,11 @@ adversary can send and receive messages.
\item $\ora{AddCustomer}() \mapsto \V{pkCustomer}$:
Generates a key pair $(\V{skCustomer}, \V{pkCustomer})$ using the
\algo{CustomerKeygen} algorithm, and sets
- \begin{align*}
- \V{withdrawn}[\V{pkCustomer}] &:= 0\\
- \V{acceptedContracts}[\V{pkCustomer}] &:= \{ \}\\
- \V{wallet}[\V{pkCustomer}] &:= \{\} \\
- \V{withdrawIds}[\V{pkCustomer}] &:= \{\} \\
- \V{refreshIds}[\V{pkCustomer}] &:= \{\}.
- \end{align*}
+ $\V{withdrawn}[\V{pkCustomer}] := 0,
+ \V{acceptedContracts}[\V{pkCustomer}] := \{ \},
+ \V{wallet}[\V{pkCustomer}] := \{\},
+ \V{withdrawIds}[\V{pkCustomer}] := \{\},
+ \V{refreshIds}[\V{pkCustomer}] := \{\}$.
Returns the public key of the newly created customer.
There is no separate oracle for creating merchants, since no information is