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

unconfuse mixed discussion of wallet and merchant security architectures

Browse Source
This commit is contained in:
Christian Grothoff 2016-08-12 16:47:29 +02:00
parent 0f055c6f51
commit 0e37ed3b68
1 changed files with 52 additions and 45 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

97
articles/ui/ui.tex
View File

@ -704,6 +704,23 @@ the information in its local database, and redirects the browser to a
% FIXME: technically this is not entirely true, if you % FIXME: technically this is not entirely true, if you
% allow CORS ... % allow CORS ...
\subsection{Browser security}
The Taler wallet operates from a secure {\em background} context on
the client side. From this background context the wallet allows the
user to securely accept the payment. If the user accepts, the
resulting signed coins are transferred from the client to the
merchant's server.
By running in the background context, the wallet can perform the
cryptographic operations protected from the main process of the Web
site. In particular, this architecture is secure against a merchant
that generates a page that looks like the wallet's payment page
(Figure~\ref{subfig:payment}), as such a page would still not have
access to the private keys of the coins that are exclusive to the
background context.
\subsection{Managing browser context} \subsection{Managing browser context}
% FIXME: this is where we probably want to revise quite a bit, % FIXME: this is where we probably want to revise quite a bit,
@ -908,7 +925,7 @@ anonymous payment system.
\subsection{Usability for merchants} \subsection{Usability for merchants}
Payment system security and usability is not only a concern for Payment system security is not only a concern for
customers, but also for merchants. For consumers, existing schemes customers, but also for merchants. For consumers, existing schemes
may be inconvenient and not provide privacy, but remembering to may be inconvenient and not provide privacy, but remembering to
protect a physical token (e.g. the card) and to guard a secret protect a physical token (e.g. the card) and to guard a secret
@ -920,31 +937,32 @@ hard challenge, as evidenced by large-scale break-ins with millions of
consumer card records being illicitly copied~\cite{target}. consumer card records being illicitly copied~\cite{target}.
Taler simplifies the deployment of a secure payment system for Taler simplifies the deployment of a secure payment system for
merchants. The high-level cryptographic design merchants. The high-level cryptographic design provides the first
provides the first major advantage, as merchants never major advantage, as merchants never receive sensitive payment-related
receive sensitive payment-related customer information. Thus, they do customer information. Thus, they do not have to be subjected to
not have to be subjected to costly audits or certified hardware, as is costly audits or certified hardware, as is commonly the case for
commonly the case for processing card payments~\cite{pcidss}. In fact, processing card payments~\cite{pcidss}. In fact, the exchange does not
the exchange does not need to have a formal business relationship with need to have a formal business relationship with the merchant at all.
the shop at all. According to our design, the exchange's contract According to our design, the exchange's contract with the state
with the state regulator or auditor and the customers ought to state regulator or auditor and the customers ought to state that it must
that it must honor all (legal and valid) deposits it receives. Hence, honor all (legal and valid) deposits it receives. Hence, a merchant
a merchant supplying a valid deposit request should be able to enforce supplying a valid deposit request should be able to enforce this in
this in court without a prior business agreement with the exchange. court without a prior direct business agreement with the exchange.
This dramatically simplifies setting up a shop to the point that the This dramatically simplifies setting up a shop to the point that the
respective software only needs to be provided with the merchant's wire respective software only needs to be provided with the merchant's wire
transfer routing information to become operational. transfer routing information to become operational.
Figure~\ref{listing:presence} shows how easy it is for a Web shop to Figure~\ref{listing:presence} shows how easy it is for a Web site to
detect the presence of a Taler wallet. The process requires a few detect the presence of a Taler wallet. The payment process requires a
cryptographic operations on the side of the merchant, such as signing few cryptographic operations on the side of the merchant, such as
a contract and verifying the customer's and the exchange's signatures. signing a contract and verifying the customer's and the exchange's
The merchant also needs to store transaction data as well as to match signatures. The merchant also needs to store transaction data, in
sales with incoming wire transfers from the exchange. Taler particular so that the store can match sales with incoming wire
simplifies this for merchants by providing a generic payment transfers from the exchange. Taler simplifies this for merchants by
processing {\em backend} for the Web shops. providing a generic payment processing {\em backend} for the Web
shops.
\begin{figure*}[b!] \begin{figure*}[t!]
\begin{center} \begin{center}
\begin{tikzpicture}[ \begin{tikzpicture}[
font=\sffamily, font=\sffamily,
@ -994,24 +1012,13 @@ processing {\em backend} for the Web shops.
Figure~\ref{fig:frobearch} shows how the secure payment components Figure~\ref{fig:frobearch} shows how the secure payment components
interact with the existing Web shop logic. First, the Web shop interact with the existing Web shop logic. First, the Web shop
frontend is responsible for constructing the shopping cart. For this, frontend is responsible for constructing the shopping cart. For this,
the shop frontend generates the usual Web pages, which are transmitted to the the shop frontend generates the usual Web pages, which are transmitted
customer's browser. Once the order has been constructed, to the customer's browser. Once the order has been constructed, the
the shop frontend provides a {\em proposed contract} in JSON format to the shop frontend provides a {\em proposed contract} in JSON format to the
payment backend, which signs it and returns it to the frontend. The frontend payment backend, which signs it and returns it to the frontend. The
then transfers the signed contract over the network, and passes it to the frontend then transfers the signed contract over the network, and
wallet (sample code for this is shown in Figure~\ref{listing:contract}). passes it to the wallet (sample code for this is shown in
Here, the wallet operates from a secure {\em background} context on the Figure~\ref{listing:contract}).
client side. From this background context the wallet allows the user to
securely accept the payment. By running in the background context,
the wallet can performs the cryptographic operations protected from the
Web shop. In particular, the architecture is secure against a merchant that
generates a page that looks like the wallet's payment page
(Figure~\ref{subfig:payment}), as such a page would still not have
access to the private keys of the coins that are exclusive to the background
context. If
the user accepts, the resulting signed coins are transferred from the
client to the server again using a protocol that the merchant can
customize to fit the existing infrastructure.
Instead of adding any cryptographic logic to the merchant frontend, Instead of adding any cryptographic logic to the merchant frontend,
the generic Taler merchant backend allows the implementor to delegate the generic Taler merchant backend allows the implementor to delegate
@ -1031,12 +1038,12 @@ sending it to the client; {\bf (7)} passing coins received in payment
for a contract to the backend; and, {\bf (8)} executing fulfillment for a contract to the backend; and, {\bf (8)} executing fulfillment
business logic if the backend confirms the validity of the payment. business logic if the backend confirms the validity of the payment.
To setup a Taler backend, the merchant only needs to let it know his wire To setup a Taler backend, the merchant only needs to configure the
transfer routing details, such as his IBAN number. Ideally, the wire transfer routing details, such as the merchant's IBAN number.
merchant might also want to obtain a certificate for the public key Ideally, the merchant might also want to obtain a certificate for the
generated by the backend for improved authentication. Otherwise, the public key generated by the backend for improved authentication.
customer's authentication of the Web shop simply continues to rely Otherwise, the customer's authentication of the Web shop simply
upon HTTPS/X.509. continues to rely upon HTTPS/X.509.
\section{Discussion} \section{Discussion}