updates sec 1-3
This commit is contained in:
parent
334561a07d
commit
240f5085bb
@ -131,7 +131,7 @@ micropayment system, which is not backed by a ``crypto currency''.
|
|||||||
Payment systems involving state-issued currencies have been used for
|
Payment systems involving state-issued currencies have been used for
|
||||||
centuries to facilitate transactions, and the involvement of the state
|
centuries to facilitate transactions, and the involvement of the state
|
||||||
has been critical as state institutions can dampen fluctuations in the
|
has been critical as state institutions can dampen fluctuations in the
|
||||||
value of the currency.~\cite{dominguez1993} Controlling money supply
|
value of the currency~\cite{dominguez1993}. Controlling money supply
|
||||||
is critical to ensure stable prices that facilitate
|
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}.
|
||||||
|
|
||||||
@ -216,7 +216,7 @@ based on resources from the W3C payment interest group.
|
|||||||
Cash has traditionally circulated by being passed directly from buyers
|
Cash has traditionally circulated by being passed directly from buyers
|
||||||
to sellers with each seller then becoming a buyer. Thus, cash is
|
to sellers with each seller then becoming a buyer. Thus, cash is
|
||||||
inherently a {\em peer-to-peer} payment system as participants all
|
inherently a {\em peer-to-peer} payment system as participants all
|
||||||
appear in the both buyer and seller roles, just at different times.
|
appear in both buyer and seller roles, just at different times.
|
||||||
However, this view is both simplified and
|
However, this view is both simplified and
|
||||||
somewhat dated.
|
somewhat dated.
|
||||||
|
|
||||||
@ -251,7 +251,7 @@ to the amount of cash that they carry or accept at a given
|
|||||||
time~\cite{Bankrate}. Additionally, customers are advised to choose
|
time~\cite{Bankrate}. Additionally, customers are advised to choose
|
||||||
the ATMs they use carefully, as malicious ATMs may attempt to
|
the ATMs they use carefully, as malicious ATMs may attempt to
|
||||||
{\em steal} their customer's credentials~\cite{ECB:TRoCF2014}. Authentication with an
|
{\em steal} their customer's credentials~\cite{ECB:TRoCF2014}. Authentication with an
|
||||||
TM can involve a special ATM card, or the use of credit or
|
ATM can involve a special ATM card, or the use of credit or
|
||||||
debit cards. In all these cases, these physical security tokens are
|
debit cards. In all these cases, these physical security tokens are
|
||||||
issued by the customer's bank.
|
issued by the customer's bank.
|
||||||
|
|
||||||
@ -269,26 +269,30 @@ issued by the customer's bank.
|
|||||||
|
|
||||||
Credit and debit card payments operate by the customer providing their
|
Credit and debit card payments operate by the customer providing their
|
||||||
credentials to the merchant. Many different authentication and
|
credentials to the merchant. Many different authentication and
|
||||||
authorization schemes are in use in various combinations including
|
authorization schemes are in use in various combinations. Secure
|
||||||
both secret information, which are usually PINs, and physical security
|
systems typically combine multiple forms of authentication including
|
||||||
devices such as TANs~\cite{kobil2016tan}, cards with an EMV
|
secret information, such as personal identification numbers (PINs),
|
||||||
chip~\cite{emv}, and the customer's mobile phone~\cite{mtan}. A
|
transaction numbers (TANs)~\cite{kolbil2016tan} or credit card
|
||||||
typical modern Web payment process involves: {(1.)} the merchant
|
verification (CCV) codes, and physical security devices such cards
|
||||||
offering a secure communication channel using TLS based on the X.509
|
with an EMV chip~\cite{emv}, TAN generators, or the customer's mobile
|
||||||
public key infrastructure;\footnote{Given numerous TLS protocol and
|
phone~\cite{mtan}. A typical modern Web payment process involves:
|
||||||
implementation flaws as well as X.509 key management incidents in
|
{(1.)} the merchant offering a secure communication channel using TLS
|
||||||
recent years~\cite{holz2014}, one cannot generally assume that the
|
based on the X.509 public key infrastructure;\footnote{Given numerous
|
||||||
security provided by TLS is adequate under all circumstances.}
|
TLS protocol and implementation flaws as well as X.509 key
|
||||||
{(2.)} selecting a {\em payment method}; {(3.)} entering the credit
|
management incidents in recent years~\cite{holz2014}, one cannot
|
||||||
card details like the owner's name, card number, expiration time, CVV
|
generally assume that the security provided by TLS is adequate under
|
||||||
code, and billing address; and {(4.)} (optionally) authorizing the
|
all circumstances.} {(2.)} selecting a {\em payment method}; {(3.)}
|
||||||
transaction via mobile TAN, or by authenticating against the
|
entering the credit card details like the owner's name, card number,
|
||||||
customer's bank, often on a Web site that is operated by the payment
|
expiration time, CCV code, and billing address; and {(4.)}
|
||||||
processor and {\em not} the customer's bank. Figure~\ref{fig:cc3ds}
|
(optionally) authorizing the transaction via mobile TAN, or by
|
||||||
shows a typical card-based payment process on the Web using the
|
authenticating against the customer's bank. Due to the complexity
|
||||||
UML style of the W3C payment interest group~\cite{pigs}. Most of the details
|
of this the data entry is often performed on a Web site that
|
||||||
are not relevant to this paper, but the diagram nicely illustrates the
|
is operated by a third-party payment processor and {\em not} the merchant or
|
||||||
complexity of the common 3-D secure (3DS) process.
|
the customer's bank. Figure~\ref{fig:cc3ds} shows a typical card-based payment
|
||||||
|
process on the Web 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
|
Given this process, there is an inherent risk of information leakage
|
||||||
of customers' credentials. {\em Fraud detection} systems attempt to detect
|
of customers' credentials. {\em Fraud detection} systems attempt to detect
|
||||||
@ -383,7 +387,7 @@ details into a peer-to-peer application. The user would access their
|
|||||||
Bitcoin {\em wallet} and instruct it to transfer a particular amount
|
Bitcoin {\em wallet} and instruct it to transfer a particular amount
|
||||||
from one of his accounts to the account of the merchant. He could
|
from one of his accounts to the account of the merchant. He could
|
||||||
possibly include additional metadata to be associated with the
|
possibly include additional metadata to be associated with the
|
||||||
transfer and embedded into the global public ledger. The wallet
|
transfer to be embedded into the global public ledger. The wallet
|
||||||
application would then transmit the request to the Bitcoin
|
application would then transmit the request to the Bitcoin
|
||||||
peer-to-peer overlay network. The use of an external payment
|
peer-to-peer overlay network. The use of an external payment
|
||||||
application makes payments significantly less
|
application makes payments significantly less
|
||||||
@ -443,7 +447,7 @@ globally on
|
|||||||
average.\footnote{\url{http://hackingdistributed.com/2016/08/04/byzcoin/}}
|
average.\footnote{\url{http://hackingdistributed.com/2016/08/04/byzcoin/}}
|
||||||
There are a variety of efforts to confront Bitcoin's scaling problems
|
There are a variety of efforts to confront Bitcoin's scaling problems
|
||||||
with off-blockchain techniques, like side-chains. % \cite{???}
|
with off-blockchain techniques, like side-chains. % \cite{???}
|
||||||
Amongst these, the Blind Off-chain Lightweight Transactions (BOLT)
|
Amongst these, the blind off-chain lightweight transactions (BOLT)
|
||||||
proposal~\cite{BOLT} provides anonymity by routing off-blockchain
|
proposal~\cite{BOLT} provides anonymity by routing off-blockchain
|
||||||
transfers through bank-like intermediaries. Although interesting,
|
transfers through bank-like intermediaries. Although interesting,
|
||||||
there are numerous seemingly fragile aspects of the BOLT protocol,
|
there are numerous seemingly fragile aspects of the BOLT protocol,
|
||||||
@ -506,7 +510,7 @@ anti-corruption efforts.
|
|||||||
Taler achieves anonymity for buyers using {\em blind
|
Taler achieves anonymity for buyers using {\em blind
|
||||||
signatures}~\cite{chaum1983blind}. Since their discovery thirty years
|
signatures}~\cite{chaum1983blind}. Since their discovery thirty years
|
||||||
ago, cryptographers have viewed blind signatures as the optimal
|
ago, cryptographers have viewed blind signatures as the optimal
|
||||||
cryptographic primitive for consumer-level transaction systems.
|
cryptographic primitive for privacy-preserving consumer-level transaction systems.
|
||||||
However, previous transaction systems based on blind signatures have
|
However, previous transaction systems based on blind signatures have
|
||||||
failed to see widespread adoption. This paper details strategies for
|
failed to see widespread adoption. This paper details strategies for
|
||||||
hiding the cryptography from users and integrating smoothly with the
|
hiding the cryptography from users and integrating smoothly with the
|
||||||
@ -515,7 +519,7 @@ cryptography and real-world deployment.
|
|||||||
|
|
||||||
%\subsection{Design overview}
|
%\subsection{Design overview}
|
||||||
|
|
||||||
\begin{figure}[t!]
|
\begin{figure}[b!]
|
||||||
\centering
|
\centering
|
||||||
\begin{tikzpicture}
|
\begin{tikzpicture}
|
||||||
\tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
|
\tikzstyle{def} = [node distance=3em and 5em, inner sep=1em, outer sep=.3em];
|
||||||
@ -538,7 +542,7 @@ cryptography and real-world deployment.
|
|||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
|
|
||||||
There are four components of the Taler system (Figure~\ref{fig:system}):
|
There are four key roles in the Taler system (Figure~\ref{fig:system}):
|
||||||
|
|
||||||
\begin{figure*}[b!]
|
\begin{figure*}[b!]
|
||||||
\includegraphics[width=0.9\textwidth]{figs/taler-withdraw.pdf}
|
\includegraphics[width=0.9\textwidth]{figs/taler-withdraw.pdf}
|
||||||
@ -552,14 +556,14 @@ There are four components of the Taler system (Figure~\ref{fig:system}):
|
|||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
\item
|
\item
|
||||||
{\em Customers} use a digital wallet to withdraw,
|
{\em Customers} use a digital wallet to withdraw,
|
||||||
hold, and spend coins. Wallets also manage the customer's accounts
|
hold, and spend coins. Wallets manage the customer's accounts
|
||||||
at the exchange, and keep receipts in a transaction history. Wallets can be
|
at the exchange, and keep receipts in a transaction history. Wallets can be
|
||||||
realized as browser extensions, mobile Apps or even in custom
|
realized as browser extensions, mobile Apps or even in custom
|
||||||
hardware. If a user's digital wallet is compromised, the current
|
hardware. If a user's digital wallet is compromised, the current
|
||||||
balance may be lost, just like with an ordinary wallet containing cash.
|
balance may be lost, just like with an ordinary wallet containing cash.
|
||||||
A wallet also includes a list of acceptable auditors, and will warn
|
A wallet includes a list of trusted auditors, and will warn
|
||||||
users against using an exchange that is not certified by one of these
|
users against using an exchange that is not certified by a trusted
|
||||||
auditors.
|
auditor.
|
||||||
|
|
||||||
\begin{figure}[t!]%[36]{R}{0.5\linewidth}
|
\begin{figure}[t!]%[36]{R}{0.5\linewidth}
|
||||||
\subfloat[Bank login. (Simplified for demonstration.)]{
|
\subfloat[Bank login. (Simplified for demonstration.)]{
|
||||||
@ -610,9 +614,9 @@ Web shops and point-of-sale systems.
|
|||||||
{\em Auditors} verify that exchanges operate correctly to limit the risk
|
{\em Auditors} verify that exchanges operate correctly to limit the risk
|
||||||
that customers and merchants incur by using a particular exchange.
|
that customers and merchants incur by using a particular exchange.
|
||||||
Auditors are typically operated by or on behalf of financial regulatory authorities.
|
Auditors are typically operated by or on behalf of financial regulatory authorities.
|
||||||
Depending on local legislation, auditors mandate that exchanges
|
Depending on local legislation, auditors may mandate that exchanges
|
||||||
have enough financial reserves before authorizing them to create a given
|
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
|
volume of signed digital coins to provide a buffer against potential risks due to
|
||||||
operational failures (such as data loss or theft of private keys) of the exchange.
|
operational failures (such as data loss or theft of private keys) of the exchange.
|
||||||
Auditors certify exchanges that they audit using digital signatures. The
|
Auditors certify exchanges that they audit using digital signatures. The
|
||||||
respective signing keys of the auditors are distributed to customer and
|
respective signing keys of the auditors are distributed to customer and
|
||||||
|
Loading…
Reference in New Issue
Block a user