diff options
Diffstat (limited to 'taler-fc19/paper.tex')
| -rw-r--r-- | taler-fc19/paper.tex | 102 |
1 files changed, 47 insertions, 55 deletions
diff --git a/taler-fc19/paper.tex b/taler-fc19/paper.tex index e5f59b5..05e808e 100644 --- a/taler-fc19/paper.tex +++ b/taler-fc19/paper.tex @@ -5,6 +5,7 @@ \documentclass[runningheads]{llncs}
%
\usepackage{graphicx}
+%\usepackage{hyperref}
\usepackage{amsmath,amssymb}
% Used for displaying a sample figure. If possible, figure files should
% be included in EPS format.
@@ -21,16 +22,23 @@ \begin{abstract}
Traditional security definitions for anonymous e-cash omit properties that
- are vital for practical deployments.
-
- We argue that a protocol for unlinkable change is necessary even in schemes
- that provide divisibility. As a naive implementation of a change protocol
- opens
+ are vital for practical deployments conducting real economic transactions.
+ First, they do not protect against economic losses when protocols are aborted.
+ Second, they do not require that customers have cryptographic evidence that they
+ spent e-cash on a particular business transaction. We introduce \emph{conservation}
+ as an additional security property to anonymity and unforgeability.
+
+ Another omission of many existing e-cash schemes and their security
+ definitions is they do not provide 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 naive implementation of a change protocol opens up the
+ possibility of misusing it for tax evasion, we define an 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 provide anonymous refunds.
-
\keywords{First keyword \and Second keyword \and Another keyword.}
\end{abstract}
@@ -103,20 +111,21 @@ charged by the exchange. The spending of multiple coins is modeled non-atomically: to spend (fractions
of) multiple coins, they must be spent one-by-one. The individual
spend/deposit operations are correlated by a unique identifier for the
-transaction. In practice this identifier is the hash $\V{transactionId} =
-H(\V{contractTerms})$ of the contract terms\footnote{The contract terms
-are a digital representation of an individual offer for a certain product or service the merchant sells
-for a certain price.}. Contract terms include a nonce to make them
-unique, that merchant and customer agreed upon. Note that this transaction
-identifier and the correlation between multiple spend operations for one
-payment need not be disclosed to the exchange (it might, however, be necessary
-to reveal during a detailed tax audit of the merchant): When spending the $i$-th coin
-for the transaction with the identifier $\V{transactionId}$, messages to the
-exchange would only contain $H(i \Vert \V{transactionId})$. This is preferable
-for merchants that might not want to disclose to the exchange the individual
-prices of products they sell to customers, but only the total transaction
-volume over time. For simplicity, we do not include this extra feature in our
-model.
+transaction.
+%In practice this identifier is the hash $\V{transactionId} =
+%H(\V{contractTerms})$ of the contract terms\footnote{The contract terms
+%are a digital representation of an individual offer for a certain product or service the merchant sells
+%for a certain price.}. Contract terms include a nonce to make them
+%unique, that merchant and customer agreed upon. Note that this transaction
+%identifier and the correlation between multiple spend operations for one
+%payment need not be disclosed to the exchange (it might, however, be necessary
+%to reveal during a detailed tax audit of the merchant): When spending the $i$-th coin
+%for the transaction with the identifier $\V{transactionId}$, messages to the
+%exchange would only contain $H(i \Vert \V{transactionId})$. This is preferable
+%for merchants that might not want to disclose to the exchange the individual
+%prices of products they sell to customers, but only the total transaction
+%volume over time. For simplicity, we do not include this extra feature in our
+%model.
Customers are identified by their public key $\V{pkCustomer}$. Every customer
keeps track of the following data:
@@ -534,7 +543,6 @@ in $\mathfrak{R}$. \begin{figure}
\fbox{\begin{minipage}{\textwidth}
\small
-\bigskip
\noindent $\mathit{Exp}_{\prt{A}}^{anon}(1^\lambda, 1^\kappa, b)$:
\vspace{-0.5\topsep}
\begin{enumerate}
@@ -581,7 +589,9 @@ money. Let $\oraSet{Conserv} := \oraSet{Taler} - \{\ora{Share}\}$ stand for access to the
all Taler oracles except the sharing oracle.
-\bigskip
+\begin{figure}
+\fbox{\begin{minipage}{\textwidth}
+\small
\noindent $\mathit{Exp}_{\cal A}^{conserv}(1^\lambda, 1^\kappa)$:
\vspace{-0.5\topsep}
\begin{enumerate}
@@ -598,6 +608,8 @@ all Taler oracles except the sharing oracle. Let $v_{S}$ be the total financial value of contracts in $\V{acceptedContracts}[\V{pkCustomer}]$.
\item Return $1$ if $\V{withdrawn}[\V{pkCustomer}] > v_{C} + v_{S}$.
\end{enumerate}
+\end{minipage}}
+\end{figure}
Hence we ensure that:
\begin{itemize}
@@ -624,7 +636,9 @@ they legitimately withdraw. Let $\oraSet{Forge} := \oraSet{Taler}$ stand for access to the all Taler
oracles.
-\bigskip
+\begin{figure}
+\fbox{\begin{minipage}{\textwidth}
+\small
\noindent $\mathit{Exp}_{\cal A}^{forge}(1^\lambda, 1^\kappa)$:
\vspace{-0.5\topsep}
\begin{enumerate}
@@ -637,6 +651,8 @@ oracles. \dots, C_\ell$ exceeds the amount withdrawn by corrupted
customers, return $0$ otherwise.
\end{enumerate}
+\end{minipage}}
+\end{figure}
\subsection{Income Transparency}
@@ -658,7 +674,9 @@ without being visible as income to the exchange. Let $\oraSet{Income} := \oraSet{Taler}$ stand for access to the
all Taler oracles.
-\bigskip
+\begin{figure}
+\fbox{\begin{minipage}{\textwidth}
+\small
\noindent $\mathit{Exp}_{\cal A}^{income}(1^\lambda, 1^\kappa)$:
\vspace{-0.5\topsep}
\begin{enumerate}
@@ -682,6 +700,8 @@ all Taler oracles. $b := w - s$ gives the coins lost during refresh, that is the losses incurred attempting to hide income.
\item If $b+p \ne 0$, return $p \over b + p$, i.e. the laundering ratio for attempting to obtain untaxed income. Otherwise return $0$.
\end{enumerate}
+\end{minipage}}
+\end{figure}
\section{Security Definitions}\label{sec:security-properties}
@@ -1087,39 +1107,10 @@ deposit permissions for the locked coins. On aborted fair exchanges, the customer refreshes to obtain unlinkable coins.
+\bibliographystyle{splncs04}
+\bibliography{ref}
-
-%
-% ---- Bibliography ----
-%
-% BibTeX users should specify bibliography style 'splncs04'.
-% References will then be sorted and formatted in the correct style.
-%
-% \bibliographystyle{splncs04}
-% \bibliography{mybibliography}
-%
-\begin{thebibliography}{8}
-\bibitem{ref_article1}
-Author, F.: Article title. Journal \textbf{2}(5), 99--110 (2016)
-
-\bibitem{ref_lncs1}
-Author, F., Author, S.: Title of a proceedings paper. In: Editor,
-F., Editor, S. (eds.) CONFERENCE 2016, LNCS, vol. 9999, pp. 1--13.
-Springer, Heidelberg (2016). \doi{10.10007/1234567890}
-
-\bibitem{ref_book1}
-Author, F., Author, S., Author, T.: Book title. 2nd edn. Publisher,
-Location (1999)
-
-\bibitem{ref_proc1}
-Author, A.-B.: Contribution title. In: 9th International Proceedings
-on Proceedings, pp. 1--2. Publisher, Location (2010)
-
-\bibitem{ref_url1}
-LNCS Homepage, \url{http://www.springer.com/lncs}. Last accessed 4
-Oct 2017
-\end{thebibliography}
\end{document}
@@ -1446,3 +1437,4 @@ As for $F = \emptyset$, the return value of the game must be $0$, we conclude %
%From \cite{bellare2003onemore}. Assumption to prove security of RSA blind signatures. Equivalent to RSA-CTI.
+
|