mostly intro

1 files changed, 340 insertions, 49 deletions

diff --git a/introduction.tex b/introduction.tex
index 293e674..ed1c7ad 100644
--- a/introduction.tex
+++ b/introduction.tex
@@ -1,68 +1,335 @@
 \chapter{Introduction}\label{chapter:introduction}
+The design of payment systems shapes economies and societies.  In the world of
+online payments, credit cards and a sprawling number of smaller, proprietary
+payment processors are currently dominant, and market shares vary widely
+between different countries \cite{adyen2016global,paypers2016ecommerce}.
 
-The design of payment systems shapes economies and societies.  Strong,
-developed nation states have adopted highly transparent payment systems, such
-as the MasterCard and VisaCard credit card schemes and computerized bank
-transactions such as SWIFT.  These systems enable mass surveillance by both
-governments and private companies.  Aspects of this surveillance sometimes
-benefit society by providing information about tax evasion or crimes like
-extortion.
+Cryptocurrencies based on Blockchains gained immense popularity over the last
+years, and promise a universal, global and decentralized payment system that is
+independent from country boundaries and legislations.  In practice, however,
+current incarnations of these technologies can only handle a handful of
+transactions, and are suprisingly centralized
+\cite{beikverdi2015trend,bohme2015bitcoin}.  Bitcoin, the most popular
+cryptocurrency, can handle around 3-7 transactions per second, globally.  While
+there are various plans to make blockchains more scalable, there is no concrete
+evidence that any of them will work without sacrificing the existing advantages
+of decentralization.
 
-At the other extreme, weaker developing nation states have economic
-activity based largely on coins, paper money or even barter.  Here,
-the state is often unable to effectively monitor or tax economic
-activity, and this limits the ability of the state to shape the
-society.
+As the Internet has no standardized payment system, especially not one that is
+capable of instantly, efficiently and securely settling small transactions
+(so-called micropayments), most content on the Web is financed by
+advertisments.  This has not only resulted in a loss of independence of content
+providers, who need to cater to the needs of advertisers, but also in a
+situation where micro-targeted ads are so wide-spread, that they have been
+suspected to have influenced multiple major elections.  Ads are also a vector
+for malware \cite{provos2007ghost}.  Due to the prevalence of ad blockers, ads
+are not guaranteed to be a sustainable business model.
 
-% account vs register based
+Especially if a payment system is to be used for microtransactions for online
+content, the privacy of buyers becomes important, as if micropayments were more
+commonplace, the transaction data could be used to collect extremely detailled
+profiles of users.  Unfortunately practically no commercially used payment
+system has strong anonymity guarantees.  With most Blockchains, the transaction
+history of all participants is publicly available.
 
-Payment systems shape our society.
+This thesis is about the design, implementation and security analysis of a
+privacy-friendly payment system that is designed to be practical for usage as
+an online (micro-)payment method, and at the same socially and ethically
+responsible.  The implementation is part of the GNU
+project\footnote{\url{http://gnu.org/}}, and called GNU Taler.
 
-Mention GDPR, data minimization
+Payment systems can generally be divided in two types:  Register-based and
+value-based \cite{riksbank2017riksbank}.  A register-based system associates
+value with identities (e.g. bank account balances with customers), while a
+value-based system associates value with typically anonymous, digital or
+physical tokens (such as cash or prepaid credit cards).  In practice, these two
+types of systems are combined, as different layers have different (and often
+conflicting) requirements:  the payment system used to pay for a cappucchino in
+a coffee shop is most likely not suitable to buy real estate.  Value-based
+payment systems typically provide more anonymity and convenience but also more
+risk, while register-based systems provide more security to customers and
+cannot be as easily used for illicit activities.
 
-blockchain + e-cash/taler as full-stack payment system that can be deployed by everybody
+With GNU Taler, we primarily focus on the token-based payment system,
+operating on top of an existing register-based system.
 
-% FIXME:  say that one payment system is not enough, coffee example
-
-% FIXME:  say why it's "GNU Taler", GNU project context
+We also discuss one component that is needed to efficiently maintain the
+transaction ledger for a register-based system in a decentralized and robust
+manner, namely a Byzantine consensus protocol.  The variation of Byzantine
+consensus, called Byzantine set union consensus (BSC), can be used (among other
+applications we discuss) to asymptotically speed up the implementation of such
+transaction ledgers, compared to classic Byzantine consensus protocols.
 
-% FIXME: demo walk-through of GNU Taler as user
 
-% FIXME:  give the whole blind sigatures as carbon paper signing analogy
+% FIXME:  I could include payment system stacks and other properties of payment systems here
 
-% FIXME: dependency graph between chapters
+% blockchain + e-cash/taler as full-stack payment system that can be deployed by everybody
 
-\section{Requirement for Payment Systems}
-(Discuss different requirements, stress that payment systems are typically
-used as stacks of multiple systems, and that no one size fits all)
+% FIXME:  say that one payment system is not enough, coffee example
 
-\section{Existing Payment Systems}
-Or:  Why another payment system?
+% FIXME: demo walk-through of GNU Taler as user
+% FIXME: gives some of the results achieved later
+% FIXME: mention the 4 security properties
 
 \section{Design Goals for GNU Taler}
+The following are the high-level design goals for our payment system.  They are
+ranked by the importance we give to them, and when a trade-off must be made, the one
+that supports the more highly ranked goal is preferred.
 
+% what about micropayments
 \begin{enumerate}
-  \item \textbf{GNU Taler must be implemented as free software.}
-  \item \textbf{GNU Taler must protect the privacy of buyers.}
+  \item \textbf{GNU Taler must be implemented as free software}
+
+    Free refers to ``free as in free speech'', as opposed to ``free as in free beer''.
+    More specifically, the four essential freedoms of free software
+    \cite{stallman2002free} must be respected, namely users must have the
+    freedom to (1) run the software, (2) study and modify it, (3) redistribute
+    copies, and (4) distribute copies of the modified version.
+
+    For merchants this prevents vendor lock-in, as another payment provider can
+    take over, should the current one run out of business.  As the software of
+    the payment provider itself is free, smaller or disadvantaged countries or
+    organizations can run the payment system without being controlled by a
+    foreign company.  Customers benefit from this freedom, as the wallet
+    software can be made to run on a variety of platform, and user-hostile
+    features such as tracking or telemetry can be removed from wallet software.
+
+    We furthermore note that this rules out the mandatory usage of specialized
+    hardware such as smartcards or other hardware security modules, as the
+    software they run cannot be modified by the user.  These components can,
+    however, be voluntarily used by merchants, customers or payment processors
+    to increase their operational security.
+
+  \item \textbf{GNU Taler must protect the privacy of buyers}\label{item:privacy}
+
+    Ideally, privacy is guaranteed via technical measures, as opposed to mere
+    policies.  Especially with micropayments for online content, a
+    disproportionate of rather private data about buyers would be revealed, if
+    the payment system does not have privacy protections.
+
+    In legislations with data protection regulations (such as the recently introduced GDPR in Europe),
+    merchants benefit from this as well, as no data breach of customers can happen if this information
+    is, by design, not collected in the first place.  Obviously some private data, such as the shipping
+    address for a physical delivery, must still be collected according to business needs.
+
+    The security of the payment systems also benefits from this, as the model
+    shifts from authentication of customers to mere authorization of payments.
+    This approach rules out whole classes of attacks such as phishing or theft
+    of credit card information.
+
   \item \textbf{GNU Taler must enable the state to tax income and crack down on
     illegal business activities.}
+
+    As a payment system must still be legal to operate and use, it must comply
+    with these requirements.  Furthermore, we consider levying of taxes as
+    beneficial to society.
+
+  \item \textbf{GNU Taler must prevent payment fraud.}
+
+    This imposes requirements on the security of the system, as well as on the
+    general design, as payment fraud can also happen through misleading user
+    interface design or the lack of cryptographic evidence for certain
+    processes.
+
   \item \textbf{GNU Taler must only disclose the minimal amount of information
     necessary.}
-  \item \textbf{GNU Taler must prevent payment fraud.}
+
+    The reason behind this goal is similar to (\ref{item:privacy}).  The
+    privacy of buyers is given priority, but other parties such as merchants
+    still benefit from it, for example by keeping details about the merchant's financials
+    hidden from competitors.
+
+
   \item \textbf{GNU Taler must be usable.}
+
+    Specifically it must be useable for non-expert customers.  Usability also
+    applies to the integration with mechants, and informs choices about the
+    architecture, such as encapsulating procedures that require cryptographic
+    operations into an isolated component with a simple API.
   \item \textbf{GNU Taler must be efficient.}
+
+    This rules out the use of approaches such as proof-of-work.  Efficiency is
+    necessary for GNU Taler to be used for micropayments.
   \item \textbf{GNU Taler must avoid single points of failure.}
+
+    While the design we present later is rather centralized, avoiding single
+    points of failure is still a goal.  This manifests in architectural choices such as
+    the isolation of certain components, and auditing procedures.
+
   \item \textbf{GNU Taler must foster competition.}
+
+    It must be relatively easy for competitors to join the systems.  While the
+    barriers for this in traditional financial systems are rather high, the the
+    technical burden for new competitors to join must be minimized. Another
+    design choice that supports this is to split the whole system into smaller
+    components that can be operated, developed and improved upon independently,
+    instead of having one completely monolithic system.
+
 \end{enumerate}
 
-\section{Making a Payment with GNU Taler}
+\section{User Experience and Performance}
+We now show how GNU Taler works from the perspective of an end user in the
+context of web payments, in a desktop browser (Chromium).  To use GNU Taler,
+the user must first install a browser extension (Figure
+\ref{fig:ux:install-prompt}).  Once installed, the user can open a pop-up
+window by clicking on the Taler logo, to see the initially empty wallet
+balance (Figure \ref{fig:ux:installed}).
+
+The customer logs into their online bank---a simple demo bank in our case--to
+withdraw digital cash from their bank account into their wallet (Figures
+\ref{fig:ux:bank-login} and \ref{fig:ux:bank-profile}).  Our demo uses
+\textsc{Kudos} as an imaginary currency.  Before the user is asked to confirm,
+they are given the option to view details about or change the default exchange
+provider, the GNU Taler payment service provider \ref{fig:ux:select-exchange}.
+
+With a real bank, a second factor (such as a mobile TAN) would now requested
+from the user.  Our demo instead asks the user to solve a simple CAPTCHA
+(Figure \ref{fig:ux:pin-tan}).  The amount withdrawn--minus withdrawal
+fees---is now available as e-cash in the wallet (Figure
+\ref{fix:ux:withdraw-done}).
+
+The customer can now go to an online shop to spend their digital cash.  We've
+implemented a shop that sells single chapter from Richard Stallman's essay
+collection ``Free Software, Free Society'' \cite{stallman2002essays} (Figure
+\ref{fig:ux:essay-landing}).  The user selects an essay, and is then
+immediately presented with a confirmation page rendered by the wallet (Figure \ref{fig:ux:essay-pay)}.
+After paying, the user can immediately read the article (Figure \ref{fix:ux:essay-done}).
+
+Our benchmarks, discussed in Chapter \ref{chapter:implementation} show that a
+single machine can support around 1000 payments per second, and our
+implementation is easily amenable to further scaling.
+
+The extra computation required in the customer's wallet is in the order of a
+few hundered milliseconds even on typical mobile or tablet devices, and thus
+barely noticeable.
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/wallet-install-prompt.png}
+\caption{The user is promoted to install the wallet.}
+\label{fig:ux:install}
+\end{figure}
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/wallet-installed.png}
+\caption{The wallet popup shows an empty balance.}
+\label{fig:ux:installed}
+\end{figure}
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/bank-login.png}
+\caption{The bank asks for login details.}
+\label{fig:ux:bank-login}
+\end{figure}
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/bank-profile.png}
+\caption{Account page of the bank.}
+\label{fig:ux:bank-profile}
+\end{figure}
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/withdraw-confirm.png}
+\caption{Account page of the bank.}
+\label{fig:ux:select-exchange}
+\end{figure}
 
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/pin-tan.png}
+\caption{Account page of the bank.}
+\label{fig:ux:pin-tan}
+\end{figure}
 
-\section{Features of E-Cash}
-This section discusses our requirements for a privacy-preserving e-cash system.
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/withdraw-done.png}
+\caption{Account page of the bank.}
+\label{fig:ux:pin-tan}
+\end{figure}
 
-\subsection{Change and Divisibility}
-\subsection{Offline Payments}
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/essay-landing.png}
+\caption{Account page of the bank.}
+\label{fig:ux:essay-landing}
+\end{figure}
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/essay-pay.png}
+\caption{Account page of the bank.}
+\label{fig:ux:essay-landing}
+\end{figure}
+
+\begin{figure}
+\centering
+\includegraphics[width=\textwidth]{taler-screenshots/essay-done.png}
+\caption{Account page of the bank.}
+\label{fig:ux:essay-landing}
+\end{figure}
+
+%\begin{figure}
+%\begin{subfigure}{.5\textwidth}
+%  \centering
+%  \includegraphics[width=.8\linewidth]{taler-screenshots/wallet-installed.png}
+%  \caption{1a}
+%  \label{fig:sfig1}
+%\end{subfigure}%
+%\begin{subfigure}{.5\textwidth}
+%  \centering
+%  \includegraphics[width=.8\linewidth]{taler-screenshots/bank-login.png}
+%  \caption{1b}
+%  \label{fig:sfig2}
+%\end{subfigure}
+%\caption{plots of....}
+%\label{fig:fig}
+%\end{figure}
+
+% FIXME: perf results
+
+\section{The Foundation of GNU Taler: Anonymous E-Cash}
+
+GNU Taler is based on anonymous e-cash.  Anonymous e-cash was invented by David
+Chaum in the 1980s \cite{chaum1983blind}.  The idea behind Chaumian e-cash is
+both simple and ingenious, and can be best illustrated
+with the carbon paper\footnote{%
+  Carbon paper is a paper coated with pigment (originally carbon) on one side.
+  When put face-down between two sheets of normal paper, the pressure from
+  writing with a pen or typewriter on the first layer causes pigment to be
+  deposited on the paper beneath, allowing a copy to be made.
+} analogy:  A long, random serial number is generated, for example by throwing
+a die a few dozen times, and written on a piece of paper.  A carbon paper is
+placed on top, with the pigmented side facing down, and both pieces of paper
+are put into an opaque envelope.  The envelope is now sealed and brought to a
+bank.  The bank draws a signature on the outside of the envelope, which presses
+through to the piece of paper with the serial number.  In exchange for the
+signed envelope, the bank deducts a fixed amount (say five dollars) from the
+customer's bank account.  Under the (admittedly rather strong) assumption that
+the bank's signature can't be forged, the signed piece of paper with the serial
+number is now an untraceable bank note worth five dollars, as the bank signed
+it without seeing the serial number inside the envelope!  Since the signed
+paper can be easily copied, merchants that accept it as payment must check the
+bank's signature, call the bank and transmit the serial number.  The bank keeps
+a register of all serial numbers that have been used as payment before.  If the
+serial number is already in the bank's register, the bank informs the merchant
+about the attempted double spending, and the merchant then rejects the payment.
+
+The digital analogue of this process is called a \emph{blind signature},
+where the signer knows that it gave a digital signature, but does not know the value
+that it signed.
+
+\subsection{E-Cash Variations}
+We now give an overview on existing variations of Chaum's original protocol in the context
+of our design goals.
+
+\paragraph{Signatures vs Zero Knowledge}
+\paragraph{Change and Divisibility}
+\paragraph{Offline vs Online Payments}
 Anonymous digital cash schemes since Chaum were frequently designed
 to allow the merchant to be offline during the transaction,
 by providing a means to deanonymize customers involved in
@@ -73,38 +340,62 @@ unreliable proposition.  Worse, there are unacceptable risks that
 a customer may accidentally deanonymize herself, for example by
 double-spending a coin after restoring from backup.
 
-\subsection{Income Transparency}
-\subsection{Traceability and Anonymity Control}
-\subsection{Refunds}
-\subsection{Tipping}
-\subsection{Transferability}
-\subsection{User Suspension}
+\paragraph{Traceability and Anonymity Control}
+\paragraph{Transferability}
+\paragraph{User Suspension}
 Electronic Cash with Anonymous User Suspension
-\subsection{Recoverability}
+\paragraph{Recoverability}
 (Ecash vs off-line recovery)
 
 FIXME:  discuss ways to handle extortion / perfect crime / kidnapping
-\subsection{Atomic Swaps}
+\paragraph{Atomic Swaps}
+
+\paragraph{Refunds}
+\paragraph{Tipping}
+\paragraph{Income Transparency}
 
 \section{Contributions}
 
 \begin{itemize}
-  \item we design, implement and analyze an efficient byzantine consensus
-    protocol on set structures that allows the optimized implementation of
+  \item we design, implement and analyze an efficient Byzantine consensus
+    protocol on set structures that allows an optimized implementation of
     permissioned blockchains
-  \item Notion of income transparency, with an instantiation in chaum-style
+  \item Notion of income transparency, with an instantiation in Chaum-style
     e-cash and proofs
   \item consideration of practical aspects including aborts, network failures,
     refunds, multi-coin payments, faults from synchronization and their effects
     on anonymity; showing the necessity of a refresh operation
   \item seamless/native integration of e-cash into web architecture, discussion
     of pitfalls / security and privacy problems
-  \item implementation of Taler with performance evaluation
+  \item implementation of GNU Taler with performance evaluation
 \end{itemize}
 
-Thesis statement: Permissioned blockchains and income-transparent e-cash can be used to implement a complete (?) payment system that is efficient (?), socially responsible (in the sense of taxes), usable (has practical implementation, web integration, ...) and provides anonymity to customers.
-
 
 \section{Roadmap}
 
+Our overall thesis statement is the following:
+\begin{quote}
+  New networking and cryptograpy protocols can substantially improve electronic
+  online payment systems.  Specifically, the GNU Taler protocol provides income
+  transparency and conservation of balance in the presents of protocol aborts
+  and certain faults, and an auditor component can be used to increase the
+  robustness of the system against insider and outsider attacks.  Furthermore,
+  Byzantine Set Union Consensus can be used as a building block for a secure
+  and asymptotically efficient transaction ledger.
+\end{quote}
+
+Chapter \ref{chapter:design} describes the high-level design of GNU Taler, and
+compares it to payment systems found in the academic literature and real-world
+usage.  Chapter \ref{chapter:security} first gives a gentle introduction to
+provable security (which can be skipped by readers with a background in
+cryptography), and then defines security properties for income-transparent,
+anonymous e-cash.  The cryptographic protocols for GNU Taler are defined in
+detail, and proofs are given that our protocols satisfy the security properties
+defined earlier.  In Chapter \ref{chapter:implementation}, the implementation
+of GNU Taler is described in detail, and the performance and scalability is
+evaluated.  Chapter \ref{chapter:consensus} is about the design, implementation
+and evaluation of our Byzantine set union consensus protocol.  Chapter
+\ref{chapter:future-work} discusses future work and missing pieces to deploy
+GNU Taler in production.  Chapter \ref{chapter:conclusion} concludes with an
+outlook on the potential impact and practical relevance of this work.