diff options
| -rw-r--r-- | introduction.tex | 2 | ||||
| -rw-r--r-- | taler/design.tex | 184 | ||||
| -rw-r--r-- | taler/implementation.tex | 75 | ||||
| -rw-r--r-- | thesis.tex | 1 |
4 files changed, 186 insertions, 76 deletions
diff --git a/introduction.tex b/introduction.tex index 5c4767f..dc444d9 100644 --- a/introduction.tex +++ b/introduction.tex @@ -493,7 +493,7 @@ 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 +the bank's signature cannot 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 diff --git a/taler/design.tex b/taler/design.tex index ebb575b..f28a3ed 100644 --- a/taler/design.tex +++ b/taler/design.tex @@ -103,7 +103,7 @@ Taler assumes that each participant has full control over their system. We assume the contact information of the exchange is known to both customer and merchant from the start, including that the customer can authenticate the merchant, for example by using X.509 -certificates~\cite{rfc6818}. A Taler merchant is trusted to deliver +certificates~\cite{rfc6818}. A Taler merchant is expected to deliver the service or goods to the customer upon receiving payment. The customer can seek legal relief to achieve this, as the customer receives cryptographic evidence of the contract and the associated @@ -114,30 +114,58 @@ payment. \subsection{Reserves} A \emph{reserve} refers to a customer's (non-anonymous) funds at an exchange, -identified by a reserve public key. When a customer wants to transfer money -via their bank to an exchange with the intent to convert it into anonymized -digital coins, the customer first creates a reserve public/private key pair. -The wire transfer instruction to the bank then includes the public key. In -order to withdraw coins from a reserve, the customer must authenticate +identified by a reserve public key. Suppose a customer wants to convert money +into anonymised digital coins. To do that, the customer first creates a +reserve private/public key pair, and then transfers money via their bank to the +exchange. The wire transfer instruction to the bank must include the reserve +public key. To withdraw coins from a reserve, the customer authenticates themselves using the corresponding reserve private key. Typically each wire transfer is made with a fresh reserve public key and thus creates a new reserve, but making another wire transfer with the same reserve -public key simply adds funds to the existing reserve. - -% FIXME: explain if/when/why you can throw alway the reserve private key -% (Allan asked this question) - -The exchange automatically transfers any funds that have been left for an -extended amount of time in a customer's reserve or that do not contain a valid -reserve public key back to the customer's bank account. - -To make the creation of reserves more convenient, banks can offer tight -integration with the Taler wallet software. When banks do not offer tight integration, -the user instructs their wallet manually to generate a reserve key pair. The public key -must then be included in a bank transaction to the exchange. When supported by the bank, -the wallet generates a QR code or link that automatically pre-fills the transaction details, -including the exchange's bank account details and the reserve public key. +public key simply adds funds to the existing reserve. Even after all funds +have been withdrawn from a reserve, customers should keep the reserve key pair +until all coins from the corresponding reserve have been spent, as in the event +of a denomination key revocation (see Section \ref{sec:revocation-payback}) the +customer needs this key to recover their funds. + +The exchange automatically transfers back to the customer's bank account any +funds that have been left in a reserve for an extended amount of time, allowing +customers that lost their reserve private key to eventually recover their +funds. If a wire transfer to the exchange does not include a valid reserve public key, +the exchange transfers the money back to the sender. + +% FIXME: this really needs a diagram + +Instead of requiring the customer to manually generate reserve key pairs and +copy them onto a wire transfer form, banks can offer tight integration with the +GNU Taler wallet software. In this scenario, the bank's website or banking app +provides a ``withdraw to GNU Taler wallet'' action. After selecting this +action, the user is asked to choose the amount to withdraw from their bank +account into the wallet. The bank then instructs the GNU Taler wallet software +to create a corresponding reserve, containing the anticipated amount, the +reserve key pair and the URL of the exchange to be used. When invoked by the +bank, the wallet asks the customer to select an exchange and to confirm the +reserve creation. The exchange chosen by the customer must support the wire +transfer method used by the bank, which will be automatically checked by the +wallet. Typically an exchange is already selected by default, as banks can +suggest a default exchange provider to the wallet, and additionally wallets +have a pre-defined list of trusted exchange providers. Subsequently the wallet +hands the reserve public key and the bank account information of the selected +reserve back to the bank, which will automatically include it in the wire +transfer details. + +When the customer's bank does not offer tight integration with GNU Taler, the +customer can still manually instruct their wallet create a reserve. The public +key must then be included in a bank transaction to the exchange. When the +customer's banking app supports pre-filling wire transfer details from URLs or +QR code, the wallet can generate such a URL or QR code that includes the +pre-filled bank account details of the exchange as well as the reserve public +key. The customer clicks on this link or scans the QR code to invoke their +banking app with pre-filled transaction details. Since there currently is no +standardized format for pre-filled wire transfer details, we are proposing the +\texttt{payto://} URI format explained in section \ref{sec:payto}, currently +under review for acceptance as an IETF Internet Standard. % FIXME: withdrawal strategy, coin selection @@ -153,17 +181,18 @@ for blind-signing coins of different financial values. Denomination keys have an expiration date, before which any coins signed with it must be spent or exchanged into newer coins (using the refresh protocol -explained later). This allows the exchange to eventually discard records of -old transactions, thus limiting the records that the exchange must retain and -search to detect double-spending attempts. If a private denomination key were -to be compromised, the exchange can detect this once more coins are redeemed -than the total that was signed into existence using that denomination key. In -this case, the exchange can allow authentic customers to redeem their unspent -coins that were signed with the compromised private key, while refusing further -deposits involving coins signed by the compromised denomination key (see -Section~\ref{sec:payback}). As a result, the financial damage of losing a -private signing key is limited to at most the amount originally signed with -that key, and denomination key rotation can be used to bound that risk. +explained in Section \ref{sec:design-refresh}). This allows the exchange to +eventually discard records of old transactions, thus limiting the records that +the exchange must retain and search to detect double-spending attempts. If a +private denomination key were to be compromised, the exchange can detect this +once more coins are redeemed than the total that was signed into existence +using that denomination key. In this case, the exchange can allow authentic +customers to redeem their unspent coins that were signed with the compromised +private key, while refusing further deposits involving coins signed by the +compromised denomination key (see Section~\ref{sec:payback}). As a result, the +financial damage of losing a private signing key is limited to at most the +amount originally signed with that key, and denomination key rotation can be +used to bound that risk. To prevent the exchange from deanonymizing users by signing each coin with a fresh denomination key, exchanges publicly announce their denomination keys @@ -190,13 +219,13 @@ beforehand, as this blurs the correlation between the non-anonymous withdrawal event and the anonymous spending event, increasing the anonymity set. A customer spends a coin at a merchant by cryptographically signing a -\emph{deposit permission} with the coin's private key. Coins can be +\emph{deposit permission} with the coin's private key. A deposit permission +contains the hash of the \emph{contract terms}, i.e. the details of the +purchase agreement between the customer and mechant. Coins can be \emph{partially} spent, and a deposit permission specifies the fraction of the -coin's value to be paid to the merchant, in addition to a \emph{contract terms -hash}, which is a hash of the business agreement details between the customer -and merchant. As digital coins are trivial to copy, the merchant must -immediately deposit them with the exchange, in order to get a deposit -confirmation or an error that indicates double spending. +coin's value to be paid to the merchant. As digital coins are trivial to copy, +the merchant must immediately deposit them with the exchange, in order to get a +deposit confirmation or an error that indicates double spending. When a coin is used in a completed or attempted/aborted payment, the coin's public key is revealed to the merchant/exchange, and further payments with the @@ -209,7 +238,7 @@ withdraw the refreshed coins makes them unlinkable from the old coin. % FIXME: talk about logarithmic time, simulation -\subsection{Refreshing and Taxability} +\subsection{Refreshing and Taxability}\cite{sec:design-refresh} % FIXME: maybe put section on how to avoid withdraw loophole here! One goal of Taler is to make merchants' income transparent to state auditors, so that income can be taxed appropriately. Naively implemented, however, a simple @@ -263,16 +292,17 @@ deadline occurs, multiple payments from deposited coins to the same merchant can be \emph{aggregated} into one bigger payment. This reduces transaction costs from underlying banking systems, which often charge a fixed fee per transaction. To incentivize merchants to choose a longer wire transfer -deadline, the exchange charges the merchant a fee per aggregated wire transfer. +deadline, the exchange can charge the merchant a fee per aggregated wire +transfer. \subsection{Refunds} The aggregation period also opens the opportunity for cheap \emph{refunds}. If -a customer is not happy with their product, the exchange can offer a refund -before the wire transfer deadline has occured. This effectively ``undoes'' the -deposit of the coin, and restores the available amount left on it. The refresh -protocol is then used by the customer on the coins involved in a refund, so -that payments remain unlinkable. +a customer is not happy with their product, the merchant can instruct the +exchange to give the customer a refund before the wire transfer deadline has +occured. This effectively ``undoes'' the deposit of the coin, and restores the +available amount left on it. The refresh protocol is then used by the customer +on the coins involved in a refund, so that payments remain unlinkable. % FIXME: mention EU customer laws / 14 weeks? @@ -280,15 +310,15 @@ that payments remain unlinkable. \subsection{Fees} In order to subsidize the operation of the exchange and enable a sustainable business model, the exchange can charge fees for most operations. For -withdrawal, refreshing and deposit, the fee is dependend on the denomination, +withdrawal, refreshing, deposit and refunds, the fee is dependant on the denomination, as different denominations might have different key sizes, security and storage requirements. -Most payments hide fees from the customer and put them on the merchant. This -is also possible with Taler. As different exchanges (and denominations) can -charge different fees, the merchant can specify a maximum amount of fees it is -willing to cover. Fees exceeding this amount must be paid by the customer -directly. +Most payment systems hide fees from the customer by put them to the merchant. +This is also possible with Taler. As different exchanges (and denominations) +can charge different fees, the merchant can specify a maximum amount of fees it +is willing to cover. Fees exceeding this amount must be explicitly paid by the +customer. Another consideration for fees is the prevention of denial-of-service attacks. To prevent ``useless'' operations, such as repeated refreshing on coins @@ -321,7 +351,7 @@ the following approach would be possible: Normal withdraw operations and unregistered reserves are disabled, except for special tip reserves that are registered by the merchant as part of a tipping campaign. Customers are required to pre-register at the exchange and obtain a special withdraw key pair -against a small safety deposit. The customer obtains new coins via a refresh operation +against a small safety deposit. Customer obtain new coins via a refresh operation from the withdraw key to a new coin. If customers want to abuse refreshing for untaxed payents, they either need to risk losing money by lying during the commit phase of refresh, or give their withdraw private key to the payee. In order to disourage the latter, @@ -342,8 +372,9 @@ financial regulator, fulfilling the following functionality: \item It accepts samples of certain protocol responses from merchants, to verify that what the exchange signed corresponds to what it stored in its database. \item It certifies exchanges that fulfill the operational and financial requirements - demanded by the auditor. - \item It regularly runs anonymous checks if certain protocol endpoints of the exchange are available. + demanded by regulators. + \item It regularly runs anonymous checks to ensure that the required protocol + endpoints of the exchange are available. \item In some deployment scenarios, merchants need to pre-register with exchanges to fulfill know-your-customer (KYC) requirements. The auditor provides a list of certified exchanges to merchants, to which the merchant then can automatically KYC-register. @@ -368,7 +399,7 @@ if it happens. \subsubsection{Compromise of Denomination Keys} When a denomination key pair is compromised, an attacker can ``print money'' by using it to sign coins of that denomination. An exchange (or its auditor) can -detect this, when the deposits for a certain denomination exceed the +detect this when the deposits for a certain denomination exceed the withdrawals for that same denomination. We allow the exchange to revoke denomination keys, and wallets periodically @@ -388,9 +419,10 @@ might be mandated by certain auditors, who will also audit the operational security of an exchange as part of the certification process. \subsubsection{Compromise of Signing Keys} -When a signing key is compromised, the attacker can forge deposit confirmations -(even if that deposit would have been a double spend and rejected by the -exchange), pretend to be a merchant and demand payment from the exchange. +When a signing key is compromised, an attacker pretending to be a merchant can +forge deposit confirmations (even if that deposit would have been a double +spend and rejected by the exchange), pretend to be a merchant and demand +payment from the exchange. In order to limit the damage of this attack, auditors work together with merchants to perform a \emph{probabilistic deposit auditing} of the exchange. @@ -402,6 +434,24 @@ database (after performing the next synchronization with the exchange's database), it signals the exchange that the signing key has been compromised, which then revokes it. +After the signing key has been revoked, the question remains which of the +merchants' deposit confirmations should be considered legitimate and should +thus result in a payment to the merchant. It can be argued that a merchant +that did not submit at least a certain ratio of their deposit confirmations to +the auditor should not be fully compensated, as failing to properly report +deposit confirmation to the auditor aids the adversary by delaying the +discovery of a signing key compromise. Thus to profit from a signing key compromise, + +% FIXME: can we somehow make it so that relatively big merchants can't profit from this +% by making mandatory the submission of deposit permissions with certain properties? I.e. +% their hash? +% => merchants must verify signatures on coins +% => to make up these deposit confirmations, merchants would have to make up +% valid coins + + +% FIXME: how do distribute remaining funds to merchants? + If the exchange had separate short-term signing keys just for signing deposit confirmations, it could also employ hardware security modules with a counter, and check if the value of the counter matches matches the deposit confirmations @@ -450,14 +500,16 @@ in~\cite{fc2014murdoch}. In particular, in providing the cryptographic proofs as evidence none of the participants have to disclose their core secrets. \subsection{Perfect Crime Scenarios} -The key revokation and emergency payback mechanism described in Section \ref{sec:revocation-payback} -can also be used in perfect crime / kidnapping scenarios where the adversary demands to be paid -a ransom in anonymous e-cash. After the attacker has been paid the ransom, -we simply revoke all denominations. Normal users can use the payback protocol -to obtain back the money they've previously had in revoked denominations. The kidnapper -does not have the withdraw or refresh transcripts, and thus can not recover their lost funds. -Should the kidnapper demand these transcripts as well (instead of demanding blind signatures on -coins they keep secret), the exchange can simply block operations that involve these coins. +The key revokation and emergency payback mechanism described in Section +\ref{sec:revocation-payback} can also be used against criminals in perfect +crime / kidnapping scenarios where the adversary demands to be paid a ransom in +anonymous e-cash. After the attacker has been paid the ransom, we simply +revoke all denominations. Normal users can use the payback protocol to obtain +back the money they've previously had in revoked denominations. The kidnapper +does not have the withdraw or refresh transcripts, and thus can not recover +their lost funds. Should the kidnapper demand these transcripts as well +(instead of demanding blind signatures on coins they keep secret), the exchange +can simply block operations that involve these coins. We believe that this is more practical than the approaches based on tracing, since in a scheme with tracing, the attacker can always ask for a plain blind diff --git a/taler/implementation.tex b/taler/implementation.tex index b7ec807..e754760 100644 --- a/taler/implementation.tex +++ b/taler/implementation.tex @@ -23,10 +23,10 @@ This chapter describes the implementation of GNU Taler in detail. Concrete design decisions, protocol details and the reference implementation are discussed. -We implemented the GNU Taler protocol in the context of a payment system -for the Web, as shown in Figure~\ref{fig:taler-arch}. The system was -designed for real-world usage with current Web technology and within -the existing financial system. +We implemented the GNU Taler protocol in the context of a payment system for +the Web, as shown in Figure~\ref{fig:taler-arch}. The system was designed for +real-world usage with current Web technologies and within the existing +financial system. % FIXME: maybe analyze instead how the high-level goals are achieved? % FIXME: maybe split into goals for wallet, exchange and merchant? @@ -66,7 +66,7 @@ The following goals influenced the design of the concrete protocol and implement failures in the payment process. \item Authorization should be preferred to authentication. In particular, there should be no situations in which the user must enter confidential - information on a page that can't be clearly identified as secure. + information on a page that cannot be clearly identified as secure. \item No flickering or unnecessary redirects. To complete a payment, the number of request, especially in the user's navigation context, should be reduced. @@ -262,8 +262,8 @@ validity and associated fees. The following information is signed by the exchan \begin{itemize} \item the RSA public key \item the start date, after which coins of this denomination can be withdrawn and deposited - \item the withdraw expiration date, after which coins can't be withdrawn anymore, must be after the start date - \item the deposit expiration date, after which coins can't be deposited anymore, must be after the withdraw expiration date + \item the withdraw expiration date, after which coins cannot be withdrawn anymore, must be after the start date + \item the deposit expiration date, after which coins cannot be deposited anymore, must be after the withdraw expiration date \item the legal expiration date, after which the exchange can delete all records about operations with coins of this denominations, must be (typically quite a long time!) after the deposit expiration date \item the fees for a withdraw, deposit, refresh and refund operation with this coin respectively @@ -892,10 +892,67 @@ Cryptographic operations run in an isolated process implemented as a WebWorker. \section{Experimental results} + +\subsection{Wallet} +We provide a microbenchmark for the performance of cryptographic operations in the wallet. + +\begin{table} + \centering + \begin{subtable}[t]{0.4\linewidth} + \centering{ + \begin{tabular}{lr} + \toprule + Operation & Time (ms) \\ + \midrule + eddsa create & 9.69 \\ + eddsa sign & 22.31 \\ + eddsa verify & 19.28 \\ + hash big & 0.05 \\ + hash small & 0.13 \\ + rsa 2048 blind & 3.35 \\ + rsa 2048 unblind & 4.94 \\ + rsa 2048 verify & 1.97 \\ + rsa 4096 blind & 10.38 \\ + rsa 4096 unblind & 16.13 \\ + rsa 4096 verify & 6.57 \\ + \bottomrule + \end{tabular}} + \caption{Wallet microbenchmark on a Laptop (Intel i7-4600U) G3 with Firefox} + \end{subtable} + \qquad + \begin{subtable}[t]{0.4\linewidth} + \centering{ + \begin{tabular}{lr} + \toprule + Operation & Time (ms) \\ + \midrule + eddsa create & 34.80 \\ + eddsa sign & 78.55 \\ + eddsa verify & 72.50 \\ + hash big & 0.51 \\ + hash small & 1.37 \\ + rsa 2048 blind & 14.35 \\ + rsa 2048 unblind & 19.78 \\ + rsa 2048 verify & 9.10 \\ + rsa 4096 blind & 47.86 \\ + rsa 4096 unblind & 69.91 \\ + rsa 4096 verify & 29.02 \\ + \bottomrule + \end{tabular}} + \caption{Wallet microbenchmark on Android Moto G3 with Firefox} + \end{subtable} + +\end{table} + + +\subsection{Merchant} + +\subsection{Exchange} We implemented a benchmarking tool that starts a single exchange and a bank process for the taler-test wire transfer protocol. It then generates workload -on the exchange it with a configurable number of concurrent clients and operations. -At the end, the benchmark outputs the number of ``transactions'' per second. +on the exchange with a configurable number of concurrent clients and +operations. At the end, the benchmark outputs the number of ``transactions'' +per second and latency statistics. We ran our experiments were on a 96-core AMD EPYC 7451 with with 250GB RAM. @@ -28,6 +28,7 @@ % bold math \usepackage{bm} +\usepackage{booktabs} \usepackage{adjustbox} \usepackage{array} |