taler/wallet-core
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Activity

Merge branch 'master' of ssh://taler.net/var/git/wallet-webex

Browse Source
This commit is contained in:
Marcello Stanisci 2016-05-12 11:45:09 +02:00
commit ddf7f22d8d
4 changed files with 1983 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
articles/ui/hotcrp-review-28A.txt Normal file
View File

@ -0,0 +1,71 @@
===========================================================================
SOUPS '16 Review #28A
---------------------------------------------------------------------------
Paper #28: Taler: Usable, privacy-preserving payments for the Web
---------------------------------------------------------------------------
Overall merit: 1. Reject
Reviewer expertise: 2. Some familiarity
===== Paper summary =====
This paper presents Taler, an alternative electronic payment architecture leveraging blind signature [7] that provide anonymity and privacy. The paper describes various workflows of how Taler is used by consumers, merchants, exchanges, and auditors. There are several advantages to Taler over current crypto-currencies, such as Bitcoin.
===== Comments for author(s) =====
Unfortunately, this paper is not ready for publication at SOUPS, for the following reasons:
1. While the paper makes significant claims about Taler's usability, there is no usability testing done whatsoever. Thus, all claims of Taler's usability are completely unsubstantiated. Until there is some usability testing performed for evaluating Taler's usability, SOUPS is not an appropriate venue for publication of this work.
2. There are several points made throughout the paper that are insufficiently clear, some of which include:
* "there have been many incidents where such parties then embezzled [Bitcoin] funds from their customers." Then surely citations can be provided as examples?
* The text in Figures 1, 2, 3, 5, and 7 is far too small to read and make sense of.
* "The use of an external payment application makes wallet-based payments significantly less browser-friendly than ordinary card payments..." This is not self-evident, and requires a citation or further explanation. Otherwise, couldn't a browser extension be able to provide Bitcoin transaction functionality?
* "As a result, the network must expend considerable computational resources to keep this value high. In fact, 'a single Bitcoin transaction uses roughly enough electricity to power 1.57 American households for a day'. [22] These costs are largely hidden by speculation in BTC..." This last phrase requires additional explanation, which may be out of scope for a usable privacy and security paper (rather than an economics paper). Still, something should be fixed here.
* "Mixnets afford protection against this..." What is a "mixnet"? At the very least, a citation should be provided.
* "...making Bitcoin highly amenable to tax evasion, money laundering, and sales of contraband. As a result, anonymity tools like mixnets do not enjoy particularly widespread support in the Bitcoin community where many participants seek to make the currency appear more legitimate." This doesn't quite seem to make sense; wouldn't anonymity advocates who support Bitcoin also support anonymity tools (such as mixnets)?
* "Naturally, this is exactly the kind of interaction we would like to avoid for usability." So how do you propose to resolve this usability challenge? Banks are typically slow to adopt new technology, so Taler must be usable without banks' cooperation (and with smaller banks that do not have the resources to support diverse payment systems).
* The description in Section 3.1 "Withdrawing coins" does not clearly explain how the customer's funds move from the exchange to the customer's wallet. It is also not explicitly clear how anonymity is preserved throughout the coin withdraw process.
* While it is sufficiently clear who the customers and merchants are, it is not clear in Section 3 who would run the exchanges, and why users should trust the exchanges with their money in transit from their bank account to their wallet. It is also not clear who the auditors would be.
* "Merchants can also set a ceiling for the maximum amount of transaction fees they are willing to cover. Usually these details should not matter for the customer, as we expect most merchants to allow most accredited exchange providers, and for exchanges to operate with transaction fees acceptable to most merchants." This expectation seems insufficiently substantiated, thus requiring additional explanation. Why do you expect this of merchants and exchanges? How will this be enforced?
* Since much of the customer-merchant transaction occurs on the client machine, it should be made more explicitly clear why a customer cannot (i.e., what prevents a customer from) simply add(ing) coins to their own wallet to generate currency from thin air.
* "In Taler, customers incur the risk of wallet loss or theft. We believe customers can manage this risk effectively because they manage similar risks of losing cash in a physical wallet. Unlike physical wallets, Taler's wallet could be backed up to secure against loss of a device." This confidence in users' ability to secure their computers seems unfounded, given past research that shows users are often tricked into installing malware:
** N. Christin et al. It's all about the Benjamins: An empirical study on incentivizing users to ignore security advice. Financial Cryptography and Data Security. Springer, 2011.
** H. Asghari et al. Post-mortem of a zombie: conficker cleanup after six years. USENIX Security Symposium. USENIX, 2015.
** K. Aytes, and T. Connolly. Computer security and risky computing practices: A rational choice perspective. Advanced topics in end user computing 4, 2005.
** P. Bryant, S. Furnell, and A. Phippen. Improving protection and security awareness amongst home users. Advances in Networks, Computing and Communications 4. April 2008.
Some other comments the authors may which to take into consideration include:
* "The future Internet needs a secure, usable and privacy preserving micropayment system that is not backed by a 'crypto currency'." This is a very strong and controversial statement to make, especially without having first provided evidence to support it. I'd advise putting this sentence at the end of the paragraph, after the references have been cited.
* The second paragraph in the Introduction is difficult to follow and seems a lot more controversial than a motivating paragraph needs to be.
* "These institutions also provide detailed instructions for how to validate the authenticity of the coins or bills..." Are there any citations on how difficult and seldom currency authenticity verification is performed? These may be useful lessons for developing new currencies, whereby currency authenticity needs of be an easy, quick, and straightforward task if users are expected to perform it.
* Section 2 is an interesting and appropriate framing for the paper, but it is surprising this hasn't been done before. Has no other published work ever compared the different forms of currency? For example, a similar comparison of electronic payment systems was performed by H.C. Yu et al. Electronic payment systems: an analysis and comparison of types. Technology in Society 24(3), 2002, but is not cited by this paper.
* While Bitcoin is probably the most popular, it is not the only crypto-currency. At least a brief comparison (or at least a reference to a paper discussing them) between Bitcoin and other crypto-currencies in Section 2 is warranted. Even better would be for Section 2.3 to address crypto-currencies in general, and use Bitcoin as an example.
* Referencing a PhD thesis [14] is a bit uncommon, especially for such a strong and impactful statement as "Given numerous TLS protocol and implementation flaws as well as X.509 key management incidents in recent years [14], the security provided by TLS is at best questionable." Is there no peer-reviewed conference or journal citation that can be used instead?
* "Taler achieves anonymity for buyers using blind signatures [7]. Ever since their discovery thirty years ago, cryptographers have viewed blind signatures as the optimal cryptographic primitive for consumer level transaction systems." If so, then why do you suppose it's taken 30 years for someone to propose a blind crypto transaction system?
* "Exchanges perform online detection of double spending," these concepts should be defined somewhere, for readers unfamiliar with them.
* "For a traditional store, an NFC protocol..." An acronym must be defined before or at the time it is first used.

1649
articles/ui/sigalternate.cls Normal file
View File

File diff suppressed because it is too large Load Diff

260
articles/ui/ui_short.tex Normal file
View File

@ -0,0 +1,260 @@
\title{Taler: \\ Usable, privacy-preserving payments for the Web}
\author{
Jeffrey Burdges \\ \and
Florian Dold \\ \and
Christian Grothoff \\ \and
Marcello Stanisci
}
\date{\today}
\documentclass[twoside,letterpaper]{sigalternate}
\usepackage[margin=1in]{geometry}
\usepackage[utf8]{inputenc}
\usepackage{url}
\usepackage{tikz}
\usepackage{eurosym}
\usepackage{listings}
\usepackage{graphicx}
\usepackage{wrapfig}
\usepackage{caption}
\usepackage{subcaption}
\usepackage{url}
%\usepackage{dblfloatfix}
\usetikzlibrary{shapes,arrows}
\usetikzlibrary{positioning}
\usetikzlibrary{calc}
\begin{document}
\maketitle
\section{System overview}
Content and services provided on the internet, such as reading a blog post or
sending an email, tend to be of very small monetary value compared to
traditional financial transactions. Currently the majority of online offerings
are financed via advertisements. Any alternatives must reduce the mental
and technical overheads of existing payment systems to handle micro-payments.
Addressing this problem is urgent: ad-blocking technology is eroding
advertising, and the Big Data business model where citizens pay with their
private information in combination with the deep state hastens our society's
regression towards post-democracy~\cite{rms2013democracy}.
Taler is a new electronic online payment system that provides
anonymity for customers. Here, {\em anonymous} simply means that the
payment system does not require any personal information from the
customer, and that different transactions by the same customer are
unlinkable. For strong anonymity, Taler usually needs to be used in
combination with existing techniques (such as~\cite{apod}) to avoid
circumstances leaking information about the customer's identity. The
fact that the user does not need to authenticate and that the merchant
thus never learns sensitive personal information about the customer
improves usability and security: the payment process is simplified, the
merchant's security requirements are dramatically reduced and the customer's
risk of identity theft does not accumulate with every (micro-)payment.
Taler uses blind signatures~\cite{chaum1983blind} to create digital
coins, and a novel ``refresh'' protocol to allow giving change and
refunds while maintaining unlinkability. We will not go into the
details of Taler's cryptographic protocols here\footnote{Full
documentation at \url{https://api.taler.net/}} and instead focus on the
high-level concepts to explain how the system works from the
perspective of customers and merchants in the Taler
system (Figure~\ref{fig:system}).
% "... and how it contributes to customer privacy"?
\begin{figure}[t!]
\centering
\begin{tikzpicture}
\tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
\node (origin) at (0,0) {};
\node (exchange) [def,above=of origin,draw]{Exchange};
\node (customer) [def, draw, below left=of origin] {Customer};
\node (merchant) [def, draw, below right=of origin] {Merchant};
\node (auditor) [def, draw, above right=of origin]{Auditor};
\tikzstyle{C} = [color=black, line width=1pt]
\draw [<-, C] (customer) -- (exchange) node [midway, above, sloped] (TextNode) {withdraw coins};
\draw [<-, C] (exchange) -- (merchant) node [midway, above, sloped] (TextNode) {deposit coins};
\draw [<-, C] (merchant) -- (customer) node [midway, above, sloped] (TextNode) {spend coins};
\draw [<-, C] (exchange) -- (auditor) node [midway, above, sloped] (TextNode) {verify};
\end{tikzpicture}
\caption{Taler system overview.}
\label{fig:system}
\end{figure}
\section{Customer perspective}
In Taler, customers use a {\em wallet} to withdraw, hold, and spend coins.
Withdrawing coins requires the customer to authenticate and to optionally
authorize the specific transaction, e.g. via a PIN/TAN method as commonly used
by banks. Afterwards, the customer can anonymously spend their coins by visiting
merchants without having to authenticate for each transaction.
The wallet is implemented as a cross-platform browser extension. All
cryptographic operations and access to sensitive data are executed in a
component that is isolated from websites the user visits.
By necessity, the wallet leaks one bit of information to websites that the user
visits, namely whether the wallet is installed and activated by the user.
Websites cannot access the customer's balance or purchase history. This
however also means that all cryptographic tokens of value are kept locally, and
the customer is responsible for not losing them. Future versions of the wallet
will provide encrypted backups and synchronization between the wallets of a
user.
A common activity for online content is sharing and bookmarking.
Taler specifically provides support to make this easy for the user.
A resource that was purchased is identified by a unique \emph{fulfillment URL}
for each purchase of the resource.
\begin{figure*}[h!]
\begin{center}
\begin{tikzpicture}[
font=\sffamily,
every matrix/.style={ampersand replacement=\&,column sep=2cm,row sep=2cm},
source/.style={draw,thick,rounded corners,fill=green!20,inner sep=.3cm},
process/.style={draw,thick,circle,fill=blue!20},
sink/.style={source,fill=green!20},
datastore/.style={draw,very thick,shape=datastore,inner sep=.3cm},
dots/.style={gray,scale=2},
to/.style={->,>=stealth',shorten >=1pt,semithick,font=\sffamily\footnotesize},
every node/.style={align=center}]
% Position the nodes using a matrix layout
\matrix{
\node[source] (wallet) {Taler Wallet};
\& \node[process] (browser) {Browser};
\& \node[process] (shop) {Web shop};
\& \node[sink] (backend) {Taler backend}; \\
};
% Draw the arrows between the nodes and label them.
\draw[to] (browser) to[bend right=50] node[midway,above] {(4) signed contract}
node[midway,below] {(signal)} (wallet);
\draw[to] (wallet) to[bend right=50] node[midway,above] {(signal)}
node[midway,below] {(5) signed coins} (browser);
\draw[<->] (browser) -- node[midway,above] {(3,6) custom}
node[midway,below] {(HTTP(S))} (shop);
\draw[to] (shop) to[bend right=50] node[midway,above] {(HTTP(S))}
node[midway,below] {(1) proposed contract / (7) signed coins} (backend);
\draw[to] (backend) to[bend right=50] node[midway,above] {(2) signed contract / (8) confirmation}
node[midway,below] {(HTTP(S))} (shop);
\end{tikzpicture}
\end{center}
\caption{Both the customer's client and the merchant's server execute
sensitive cryptographic operations in a secured
background/backend that is protected against direct access.
Interactions between the Taler components
(Figure~\ref{fig:system}) are not shown. Existing system
security mechanisms are used to isolate the cryptographic
components (boxes) from the complex rendering logic
of existing Web applications (circles).}
\label{fig:frobearch}
\end{figure*}
% maybe mention division into two phases (a) contract offer/accept
% and (b) contract execution/replay
% How far does this allow the merchant
Should the session state that allows the user to access the content be lost,
visiting the fulfillment URL will transparently restore the session state by
transparently replaying the payment with the same digital value tokens from the
user's wallet. Replaying a contract is only allowed from the domain that the
contract originated from, and thus does not allow arbitrary websites to obtain
information about previous purchases that the customer made. Sharing the
fulfillment URL with a user that did not pay for the associated digital
contract will result in the expected behavior, namely that they receiving a new
instance of the digital contract with the opportunity to pay for it.
% idea while writing this: why do we need a correlation id
% if we already have the url? i.e. the non-fulfillment URL
% that just identifies the resource ...
The case where a user already payed for a resource and then visits
the resource URL (instead of the fulfillment URL) after losing temporary
session state is also handled as expected, since the wallet component will
look for contracts that refer to the same resource.
While Taler is designed to work well with digital resources on the web,
it can also be used for more traditional purchases. The resource that
is being payed for then represents the shopping cart of items that
are being purchased.
%\newpage
\section{Merchant perspective}
%\begin{figure}[b!]
%\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf}
%\caption{Payment processing with Taler.}
%\label{fig:taler-pay}
%\end{figure}
A new payment system must also be easy to integrate and deploy for merchants.
Figure~\ref{fig:frobearch} shows how the security critical payment components of
Taler interact with the logic of existing Web shops. First, the Web shop
front-end is responsible for constructing the shopping cart. For this,
the shop front-end generates the usual Web pages which are shown to the
user's browser client front-end. Once the order has been constructed,
the shop front-end gives a {\em proposed contract} in JSON format to
the payment backend, which signs it and returns it to the front-end.
The front-end then transfers the signed contract over the network, and
passes it to the wallet. Here, the wallet operates from a secure
background context on the client side, which allows the user to securely
accept the payment, and to perform the cryptographic operations in a
context that is protected from the Web shop. If the user accepts, the
resulting signed coins are transferred from the client to the server,
again by a protocol that the merchant can customize to fit the
existing infrastructure.
Instead of adding any cryptographic logic to the merchant front-end,
the generic Taler merchant backend allows the implementor to delegate
handling of the coins to the payment backend, which validates the
coins, deposits them at the exchange, and finally validates and
persists the receipt from the exchange. The merchant backend then
communicates the result of the transaction to the front\-end, which is
then responsible for executing the business logic to fulfill the
order.
As a result of this setup, the cryptographic details of the
Taler protocol do not have to be re-implemented by each merchant.
Instead, existing Web shops implemented in a multitude of programming
languages can rather trivially add support for Taler by {\bf (1)} upon
request, generating a contract in JSON based on the shopping cart,
{\bf (2)} allowing the backend to sign the contract before sending it
to the client, {\bf (7)} passing coins received in payment for a
contract to the backend and {\bf (8)} executing fulfillment business
logic if the backend confirms the validity of the payment.
To setup a Taler backend, the merchant only needs to configure it with the
respective wire transfer routing details, such as an IBAN number. The
customer's authentication of the Web shop continues to rely upon
\mbox{HTTPS}/X.509.
\section{Conclusion}
We encourage everyone to try our prototype for Taler
at \url{https://demo.taler.net/}.
% These APIs are all RESTful in the modern sense because that greatly
% simplify integrating Taler with web shops and browsers.
\section*{Acknowledgements}
This work benefits from the financial support of the Brittany Region
(ARED 9178) and a grant from the Renewable Freedom Foundation.
\bibliographystyle{abbrv}
\bibliography{ui,btc,taler,rfc}
\end{document}

3
test/run_tests.js
View File

@ -24,6 +24,9 @@ let emsc = require("../lib/emscripten/libwrapper.js");
let System = require("systemjs");
// When instrumenting code with istanbul,
// automatic module type detection fails,
// thus we specify it here manually.
System.config({
defaultJSExtensions: true,
meta: {