diff options
Diffstat (limited to 'articles')
| -rw-r--r-- | articles/ui/btc.bib | 10 | ||||
| -rw-r--r-- | articles/ui/ui.bib | 12 | ||||
| -rw-r--r-- | articles/ui/ui.pdf | bin | 708288 -> 727764 bytes | |||
| -rw-r--r-- | articles/ui/ui.tex | 142 |
4 files changed, 102 insertions, 62 deletions
diff --git a/articles/ui/btc.bib b/articles/ui/btc.bib index c42db9bee..148261aca 100644 --- a/articles/ui/btc.bib +++ b/articles/ui/btc.bib @@ -170,3 +170,13 @@ year={2014} } + + +@inproceedings{miers2013zerocoin, + title={Zerocoin: Anonymous distributed e-cash from bitcoin}, + author={Miers, Ian and Garman, Christina and Green, Matthew and Rubin, Aviel D}, + booktitle={Security and Privacy (SP), 2013 IEEE Symposium on}, + pages={397--411}, + year={2013}, + organization={IEEE} +} diff --git a/articles/ui/ui.bib b/articles/ui/ui.bib index 21613536c..487b3b812 100644 --- a/articles/ui/ui.bib +++ b/articles/ui/ui.bib @@ -195,3 +195,15 @@ improvements}, urldate = {2016-02-10}, note = {[Online; Accessed: 2016-02-10]} } + + +@article{chaum1981untraceable, + title={Untraceable electronic mail, return addresses, and digital pseudonyms}, + author={Chaum, David L}, + journal={Communications of the ACM}, + volume={24}, + number={2}, + pages={84--90}, + year={1981}, + publisher={ACM} +} diff --git a/articles/ui/ui.pdf b/articles/ui/ui.pdf Binary files differindex 31118ab6d..55a1c919b 100644 --- a/articles/ui/ui.pdf +++ b/articles/ui/ui.pdf diff --git a/articles/ui/ui.tex b/articles/ui/ui.tex index d05f6adcb..8f95a3674 100644 --- a/articles/ui/ui.tex +++ b/articles/ui/ui.tex @@ -1,5 +1,4 @@ - -\title{Taler: \\ Usable, privacy-preserving payments for the Web} +\title{Taler: Usable, privacy-preserving payments for the Web} % Not sure how to do authors with the % IEEEtran template correctly ... @@ -57,7 +56,7 @@ centuries to facilitate transactions, and the involvement of the state has been critical as state institutions can dampen fluctuations in the value of the currency.~\cite{dominguez1993} Controlling money supply is critical to ensure stable prices that facilitate -trade~\cite{quantitytheory1997volckart} instead of speculation.\cite{lewis_btc_is_junk} +trade~\cite{quantitytheory1997volckart} instead of speculation.~\cite{lewis_btc_is_junk} As transactions on the Internet, such as sending an e-mail or reading a Web site, tend to be of smaller value than traditional transactions @@ -117,13 +116,13 @@ Key contributions of this paper are: \section{Existing payment workflows} -Before we look at the payment workflow for Taler, we will sketch -the workflow of existing payment systems. This will establish -a common terminology, a baseline for comparison and crucially -also an indication as to how we can relate Taler's workflow to -existing {\em mental models} that users already have, thereby -allowing us to judge the mental adaptation costs required to -transition to transactions with Taler. +Before we look at the payment workflow for Taler, we will sketch the workflow +of existing payment systems. This will establish a common terminology, a +baseline for comparison and crucially also an indication as to how we can +relate Taler's workflow to existing {\em mental models} that users already +have, thereby allowing us to judge the mental adaptation costs required to +transition to transactions with Taler. Detailed interaction diagrams for some +of the payment systems discussed here can be found in the Appendix. \subsection{Cash} @@ -180,29 +179,29 @@ physical security devices like TANs~\cite{kobil2016tan} (cards with an EMV chip~\cite{emv}), and the customer's mobile phone~\cite{mtan}. A typical modern Web payment process involves -{\bf (0)} the merchant offering a ``secure'' communication channel +{(1.)} the merchant offering a ``secure'' communication channel using TLS based on the X.509 public key infrastructure,\footnote{Given numerous TLS protocol and implementation flaws as well as X.509 key management incidents in recent years~\cite{holz2014}, the security provided by TLS is at best questionable.} -{\bf (1)} selecting a {\em payment method}, -{\bf (2)} entering the credit card details like owner's name, +{(2.)} selecting a {\em payment method}, +{(3.)} entering the credit card details like owner's name, card number, expiration time, CVV code, and billing address, -{\bf (3)} (optionally) authorizing the transaction via mobile TAN, or +{(4.)} (optionally) authorizing the transaction via mobile TAN, or by authenticating against the customer's bank, often on a Web site that is operated by the payment -processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds} -shows a typical card-based payment process on the Web today using the -UML style of the W3c payment interest group~\cite{pigs}. Most of the -details are not relevant to this paper, but the figure nicely -illustrates the complexity of the common 3-D secure (3DS) process. +processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds} in the +Appendix shows a typical card-based payment process on the Web today using the +UML style of the W3c payment interest group~\cite{pigs}. Most of the details +are not relevant to this paper, but the diagram nicely illustrates the +complexity of the common 3-D secure (3DS) process. Given this process, there is an inherent risk of information leakage of customers' credentials. Fraud detection systems attempt to detect misuse of leaked credentials, and payment system providers handle disputes between customers and merchants. As a result, Web payment -processes may finish with {\bf (4)} the payment being rejected for a -variety of reasons, from false-positives in fraud detection to the +processes may finish with {(5.)} the payment being rejected for a +variety of reasons, from false positives in fraud detection to the merchant not accepting the particular card issuer. Traditionally, merchants bear most of the financial risk, and a key @@ -272,15 +271,19 @@ technologies, but usability improvements are usually achieved by adding a ``trusted'' third party, and there have been many incidents where such parties then embezzled funds from their customers \cite{BTC:demise}. The classical Bitcoin payment workflow consisted of entering payment -details into a peer-to-peer application. The user would access his +details into a peer-to-peer application. The user would access their Bitcoin {\em wallet} and instruct it to transfer a particular amount from one of his accounts to the account of the merchant, possibly including additional metadata to be associated with the transfer and -embedded into the global public ledger. The wallet application would +embedded into the global public ledger. +% Technically the following is not true, there are +% wallets that run purely in the browser and store +% the keys locally: https://github.com/frozeman/bitcoin-browser-wallet +The wallet application would then transmit the request to the Bitcoin peer-to-peer overlay network. The use of an external payment application makes wallet-based payments significantly less browser-friendly than ordinary card payments, as -illustrated in Figure~\ref{fig:bitcoin}. +illustrated in Figure~\ref{fig:bitcoin} in the Appendix. Bitcoin payments are only confirmed when they appear in the public ledger, which is updated at an average frequency of once every 10 @@ -305,9 +308,12 @@ unstable.~\cite{lehmann_btc_fools_gold,jeffries_economists_v_btc,lewis_btc_is_ju % more on massive transaction fees from blockchain.info There are several examples of Bitcoin's pseudononymity being broken -by investigators~\cite{BTC:Anonymity}. Mixnets afford protection -against this, but they require numerous transactions, exacerbating -Bitcoin's already high transaction costs. +by investigators~\cite{BTC:Anonymity}. + +Zerocoin \cite{miers2013zerocoin}, an extension of Bitcoin, affords protection +against this, but at non-trivial additional computational costs even for +spending coins. This currently makes using Zerocoin unattractive for payments +with mobile devices. % Bitcoin's pseudononymity applies equally to both customers and merchants, making Bitcoin highly amen\-able to tax evasion, money @@ -361,6 +367,7 @@ when they spend money with low transaction costs, signed digital receipts, and accurate income information to facilitate taxation and anti-corruption efforts. +% FIXME: maybe say what blind signature are Taler achieves anonymity for buyers using {\em blind signatures}~\cite{chaum1983blind}. Ever since their discovery thirty years ago, cryptographers have viewed blind signatures as the optimal @@ -408,7 +415,11 @@ hardware. \item {\em Exchanges} enable customers to withdraw anonymous digital coins and merchants to deposit digital coins, in exchange for -bank money. Exchanges learn the amounts withdrawn by customers +bank money. Coins are signed by the exchange using +a blind signing scheme \cite{chaum1983blind}. Thus only +the exchange can issue new coins, but coins can't be traced back +to the customer that withdrew them. +Furthermore, exchanges learn the amounts withdrawn by customers and deposited by merchants, but they do not learn the relationship between customers and merchants. Exchanges perform online detection of double spending, thus providing merchants instant feedback, @@ -425,6 +436,11 @@ Web shops and point-of-sale systems. \item {\em Auditors} verify that exchanges operate correctly to limit the risk that customers and merchants incur by using a particular exchange. +Auditors are typically operated by financial regulatory authorities. +Depending on local legislation, auditors mandate that exchanges +have enough financial reserves before authorizing them to create a given +volume of signed digital coins in order to compensate for potential risks due to +operational failures (such as data loss or theft of private keys) of the exchange. \end{itemize} The specific protocol between wallet and merchant depends on the @@ -432,11 +448,11 @@ setting. For a traditional store, a near field communication (NFC) protocol mig between a point-of-sale system and a mobile application. In this paper, we focus on Web payments for an online shop. -%\begin{figure}[b!] -%\includegraphics[width=0.45\textwidth]{figs/taler-withdraw.pdf} -%\caption{Withdrawing coins with Taler.} -%\label{fig:taler-withdraw} -%\end{figure} +\begin{figure*} +\includegraphics[width=0.9\textwidth]{figs/taler-withdraw.pdf} +\caption{Withdrawing coins with Taler.} +\label{fig:taler-withdraw} +\end{figure*} % \smallskip @@ -446,7 +462,7 @@ We explain how the actors in the Taler system interact by documenting a typical payment. Initially, the customer must once install the Taler wallet extension -for his browser. Naturally, this step may become superfluous if +for their browser. Naturally, this step may become superfluous if Taler is integrated tightly with browsers in the future. Regardless, installing the extension involves one or two clicks to confirm the operation once the user was pointed to the correct Web site. @@ -454,10 +470,9 @@ Restarting the browser is not required. \paragraph{Withdrawing coins} - As with cash, the customer must first withdraw digital coins (Figure~\ref{fig:taler-withdraw}). For this, the customer must first -visit the online banking portal of his bank. Here, the bank will +visit the online banking portal of their bank. Here, the bank will typically require some form of authentication, the specific method used depends on the bank (Figure~\ref{subfig:login}). @@ -487,9 +502,9 @@ used depends on the bank (Figure~\ref{subfig:login}). \end{figure} -The next step depends on the Taler support offered by the bank: +The next step depends on the level of Taler support offered by the bank: \begin{itemize} -\item If the bank does not properly integrate with Taler, the +\item If the bank does not offer integration with Taler, the customer needs use the menu of the wallet to create a {\em reserve}. The wallet will ask which amount in which {\em currency} (i.e. EUR or USD) the customer wants to withdraw and allow the customer to @@ -504,7 +519,7 @@ The next step depends on the Taler support offered by the bank: exactly the kind of interaction we would like to avoid for usability. \item Hence, if the bank properly integrates with Taler, the - customer has a form in the online banking portal where he can specify + customer has a form in the online banking portal where they can specify an amount to withdraw (Figure~\ref{subfig:withdraw}). The bank then triggers an interaction with the wallet to allow the customer to select an exchange @@ -528,11 +543,11 @@ customers and may help create a competitive market. \paragraph{Spending coins} % \tinyskip -\begin{figure}[b!] -\includegraphics[width=0.45\textwidth]{figs/taler-pay.pdf} +\begin{figure*} +\includegraphics[width=0.9\textwidth]{figs/taler-pay.pdf} \caption{Payment processing with Taler.} \label{fig:taler-pay} -\end{figure} +\end{figure*} \begin{figure}[b!] \begin{subfigure}[H]{0.5\textwidth} @@ -555,7 +570,7 @@ customers and may help create a competitive market. \end{figure} -At a later point in time, the customer can spend his coins by +At a later point in time, the customer can spend their coins by visiting a merchant that accepts digital coins in the respective currency issued by the respective exchange (Figure~\ref{fig:taler-pay}). Merchants are generally configured to @@ -569,7 +584,7 @@ merchants. If transaction fees are higher than what is covered by the merchant, the customer may choose to cover them. As with traditional Web transactions, the customer first selects which -items he wishes to buy. This can involve building a traditional +items they wish to buy. This can involve building a traditional shopping cart, or simply clicking on a particular link for the respective article (Figure~\ref{subfig:cart}). As with card payments, the Web shop may then allow the customer to select a payment method, @@ -587,16 +602,20 @@ covered by the customer, these are shown together with the rest of the proposed contract. If the customer approves the contract by clicking the ``Confirm -Payment'' button (Figure~\ref{subfig:payment}), his wallet signs the +Payment'' button (Figure~\ref{subfig:payment}), their wallet signs the contract with enough coins to cover the contract's cost, stores all of the information in its local database, and redirects the browser to a {\em fulfillment} URL provided by the merchant -(Figure~\ref{subfig:fulfillment}). The wallet cannot directly send +(Figure~\ref{subfig:fulfillment}). +% FIXME: technically this is not entirely true, if you +% allow CORS ... +The wallet cannot directly send the payment to the merchant, as the page showing the contract is provided as a background page controlled by the Web Extension\footnote{\url{https://developer.chrome.com/extensions}} and thus submitting coins from the background would not use the HTTP-context that the Web shop's page requires for session management. +% FIXME: can we do better with the description? Instead, the server-side of the fulfillment page usually first detects that the contract has not yet been paid by checking the merchant's local database and the HTTP session state. {\bf (A)} If the state @@ -633,6 +652,7 @@ client side of the result. failure persists and is between customer and merchant, the wallet will try to recover control over the coins at the exchange by effectively spending the coins first using Taler's special + % FIXME(dold): Do we properly introduce/discuss refreshing before? ``refresh'' protocol. In this case, later deposits by the merchant will simply fail. If the merchant already succeeded with the payment before the network failure, the customer can either retry the @@ -1018,7 +1038,7 @@ receiving coins by a wallet. In other words, it is the way merchants get real money on their bank accounts}. To ensure that the exchange operator does not embezzle these funds, Taler expects exchange operators to be regularly audited by an independent auditor\footnote{Auditors are typically -run by states}. The auditor can then verify that the incoming and outgoing +run by financial regulatory bodies of states}. The auditor can then verify that the incoming and outgoing transactions and the current balance of the exchange match the logs with the cryptographically secured transaction records. @@ -1144,9 +1164,9 @@ PayPal and 3DS, the user is left without a cryptographically secured receipt. Card-based payments (including 3DS) and PayPal also extensively rely -on TLS for security. The customer is expected to verify that his +on TLS for security. The customer is expected to verify that their connections to the various Web sites are properly authenticated using -X.509, and to know that it is fine to providing his bank account +X.509, and to know that it is fine to provide their bank account credentials to the legitimate \url{verifiedbyvisa.com}.\footnote{The search query ``verifiedbyvisa.com legit'' is so common that, when we entered @@ -1204,15 +1224,15 @@ simultaneously using a modern payment protocol. \section*{Acknowledgements} -Removed for anonymous submission. +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} \appendix -\section{Interation Diagrams} -\begin{figure*}[h!] +\begin{figure*} \begin{center} \includegraphics[width=0.95\textwidth]{figs/cc3ds.pdf} \end{center} @@ -1222,13 +1242,11 @@ Removed for anonymous submission. -\begin{figure}[h!] -\includegraphics[width=0.45\textwidth]{figs/bitcoin.pdf} +\begin{figure*} +\includegraphics[width=\textwidth]{figs/bitcoin.pdf} \caption{Bitcoin payment processing. (From: W3c Web Payments IG.)} \label{fig:bitcoin} -\end{figure} - -\section{Code Samples} +\end{figure*} % \tinyskip \lstdefinelanguage{JavaScript}{ @@ -1246,7 +1264,7 @@ Removed for anonymous submission. morestring=[b]" } -\begin{figure*}[h!] +\begin{figure*} \lstset{language=JavaScript} \lstinputlisting{figs/taler-presence.js} \caption{Sample code to detect the Taler wallet. Allowing the @@ -1257,7 +1275,7 @@ Removed for anonymous submission. \end{figure*} -\begin{figure*}[h!] +\begin{figure*} \lstset{language=JavaScript} \lstinputlisting{figs/taler-contract.js} \caption{Sample code to pass a contract to the Taler wallet. @@ -1268,11 +1286,11 @@ Removed for anonymous submission. \end{figure*} -\begin{figure}[b!] -\includegraphics[width=0.45\textwidth]{figs/paypal.pdf} +\begin{figure*} +\includegraphics[width=\textwidth]{figs/paypal.pdf} \caption{Payment processing with Paypal. (From: W3c Web Payments IG.)} \label{fig:paypal} -\end{figure} +\end{figure*} \end{document} |