commit 233fe0bb2cdbf466121f50be37933ad2633ead1e Author: Özgür Kesim Date: Mon May 2 16:53:23 2022 +0200 init diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..a136337 --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +*.pdf diff --git a/Age_restriction_and_legal_issues.pdf b/Age_restriction_and_legal_issues.pdf new file mode 100644 index 0000000..581fac3 Binary files /dev/null and b/Age_restriction_and_legal_issues.pdf differ diff --git a/escrow-flow.png b/escrow-flow.png new file mode 100644 index 0000000..cced389 Binary files /dev/null and b/escrow-flow.png differ diff --git a/ngi-ap3-m2-report.tex b/ngi-ap3-m2-report.tex new file mode 100644 index 0000000..6f0a6bf --- /dev/null +++ b/ngi-ap3-m2-report.tex @@ -0,0 +1,954 @@ +\documentclass{scrarticle} +\usepackage[a4paper]{geometry} +\usepackage{hyperref} +\usepackage{xcolor} +\hypersetup{ + colorlinks = true, + allcolors = {black}, + linkcolor = [rgb]{0.6 0.1 0.1}, + urlcolor = [rgb]{0.1 0.1 0.7} +} +\usepackage{url} +\usepackage{amssymb} +\usepackage{amsmath} +\usepackage{pdfpages} +\usepackage{graphicx} + +\begin{document} + +\title{AP³\\ +Report for Milestone II\\ +NGI Pointer} +\author{Özgür Kesim\\ +Christan Grothoff\\ +Florian Dold\\ +Stefan Kügel\\ +Belén Barros Pena\\[\bigskipamount] +\normalsize Mentor: Mirko Ross \href{mailto:m.ross@digital-worx.de}{}\\[\medskipamount] +} + +\date{May 1, 2022} + +\maketitle + +\section*{Management summary} +\begin{abstract} +The AP³ project presents here the report for the milestone II for NGI Pointer. + The deliverables for this milestone are: + +\begin{description} + \item[Age restriction] -- Extending GNU Taler with an mechanism for + anonymous age restriction based on the principle subsidiarity + and bound to particular coins. + \item[P2P payments] -- Extending GNU Taler with the ability to transfer + funds between wallets. + \item[Anonymous auction] -- Design of an extension to GNU Taler to + support for anonymous auctions. +\end{description} +\end{abstract} + +\vfill +\hfill {\footnotesize Version: 1.0} + +\thispagestyle{empty} +\newpage + +\tableofcontents + +\newpage + +\section{Age restriction} + +We layed out the design for age restriction in our design document no. 24, +\url{https://docs.taler.net/design-documents/024-age-restriction.html} and +implemented the parts accordingly. Conceptually, the age restriction works as +follows: + +Parents/warden can choose to \textbf{commit} a certain maximum age out of a +predefined list of age groups and bind that commitment to a particular coin. +The minors receive those coins and can now \textbf{attest} a required minimum +age (provided that age is less or equal to the committed age of the coins) to +merchants, who can \textbf{verify} the minimum age. For the rest values +(change) after an transaction, the minor/ward can \textbf{derive} new +age-restricted coins. The exchange can \textbf{compare} the equality of the +age-restriction of the old coin with the new coin (in a zero-knowledge +protocol, that gives the minor a 1/$\kappa$ chance to raise the minimum age for +the new coin). + +The main building blocks are: + +\begin{itemize} + \item The exchange defines and publishes M+1 different \textit{age + groups} of increasing order: $0 < a_1 < \ldots < a_M$ with $a_i + \in \mathbb{N}$. The zeroth age group is $\{0,\ldots,a_1-1\}$. + + \item An \textit{unrestricted age commitment} is defined as a vector of + length M of pairs of Edx25519~(\ref{gnunet}) public and + private keys on Curve25519. In other words: one key pair for + each age group after the zeroth: $\bigl\langle (p_1, s_1), + \ldots, (p_M, s_M) \bigr\rangle$ + + \item A \textit{restricted age commitment} to age group m (or m-th age + group) is derived from an unrestricted age commitment by + removing all private keys for indices larger than m: + \[ + \bigl\langle (p_1, s_1), \ldots, (p_m, s_m), \, (p_{m+1}, + \perp), \ldots, (p_M, \perp )\bigr\rangle \] F.e. if none of + the private keys is provided, the age commitment would be + restricted to the zeroth age group. + + \item An \textit{age commitment} (without prefix) is just the vector of + public keys: $\vec{Q} := \langle p_1, \ldots, p_M \rangle$. + Note that from just the age commitment one can not deduce if it + was originated from an unrestricted or restricted age + commitment (and what age). + + \item An attestation of age group k is essentially the signature to any + message with the private key for slot k, if the corresponding + private key is available in a restricted age commitment. + (Unrestricted age commitments can attest for any age group). + + \item An age commitment is bound to a particular coin by incorporating + the SHA256 hash value of the age commitment (i.e. the M public + keys) into the signature of the coin. So instead of signing + $\text{FDH}_N(C_p)$ with the RSA private key of a denomination + with support for age restriction, we sign $\text{FDH}_N(C_p, + h_a)$. Here, $C_p$ is the EdDSA public key of a coin and $h_a$ + is the hash of the age commitment. +\end{itemize} + +The proposed solution maintains the guarantees of GNU Taler with respect to +anonymity and unlinkability. + +\subsection{Exchange support} + +For age restriction suppport the exchange had to be extended at various places: + +\begin{itemize} + \item SQL database schema + \item Extension support + \item REST endpoints \verb|/keys|, \verb|/deposit|, \verb|/melt|, \verb|/reveal|, \verb|/recoup|. +\end{itemize} + +\subsubsection{SQL database schema} + +Various tables (for denominations, coins, deposits etc.) in the database have +been extended in order to maintain information about the age restriction +support of denominations and particular coins. Code locations: + +\begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/exchangedb/common.sql} + \item \url{https://git.taler.net/exchange.git/tree/src/exchangedb/exchange-0001.sql} + \item \url{https://git.taler.net/exchange.git/tree/src/exchangedb/plugin_exchangedb_postgres.c} +\end{itemize} + +\subsubsection{Extension and -configuration} + +Age restriction is added to GNU Taler as an \textit{extension}, an optional +feature that can be enabled at startup time. The concept of extensions has +been introduced as part of this project. The design document no. 6 under +\url{https://docs.taler.net/design-documents/006-extensions.html} describes the +current solution. For an extension to become active, its configuration must be +signed with the offline-signing-tool. + +Code locations: +\begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/extensions/} + code location for the general framework for extensions + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_management_extensions.c} + management handler for extensions + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_extensions.c} + utility functions for extensions +\end{itemize} + +\subsubsection{Endpoint \texttt{/keys}} + +When age restriction is configured and enabled in the exchange and some +denominations are configured to support age restrictions, the REST endpoint +\verb|/keys| on the exchange will return the definition of the age groups in +form of a bitmask \verb|age_mask| and the array of denominations with support +for age restriction in \verb|age_restricted_denominations|. Code location: + +\url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_keys.c}, + functions \verb|load_age_mask|, \verb|create_krd|, \verb|finish_keys_response|. + +\subsubsection{Deposit operation} + +The deposit of a coin with age restriction now requires the hash of the age +commitment that is bound to the coin to be passed along to the REST endoint +\verb|/deposit|. The exchange can then verify the signature of the coin with +age restriction. Code locations: + + +\begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_deposit.c}, REST endpoint handler \verb|TEH_handler_deposit| + \item \url{https://git.taler.net/exchange.git/tree/src/util/wallet_signatures.c}, function \verb|TALER_wallet_deposit_verify| +\end{itemize} + +\subsubsection{Refresh operation} + +Also coins with age restriction which have been spent and have residual value +left can be refreshed in an unlinkable manner by using a cut\&choose protocol. + +\paragraph{Melt phase} + +The refresh process starts with the melting phase and the wallet has to provide +the hash of the original age commitment for the endpoint +\verb|/coins/$COIN_PUB/melt|. Code locations: + +\begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_melt.c}, REST endpoint handler \verb|TEH_handler_melt| + \item \url{https://git.taler.net/exchange.git/tree/src/util/wallet_signatures.c}, function \verb|TALER_wallet_melt_verify| +\end{itemize} + +\paragraph{Reveal phase} + +In the reveal phase of the refresh operation, the wallet has to provide all +secrets - except for one - from the melting phase to fullfill the cut\&choose +protocol. For coins with age restrictions, it provides the full age commitment +of the original coin from which the exchange can derive the age commitments of +the disclosed fresh coins and ensure that they have the hash values as +(refresh-)committment during the melting phase. + +The code locations are in\\ +\url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_refreshes_reveal.c}: +REST endpoint handler \verb|TEH_handler_reveal| and functions +\begin{itemize} + \itemsep-0.5em + \item \verb|check_commitment| + \item \verb|resolve_refreshes_reveal_denominations| + \item \verb|handle_refreshes_reveal_json| +\end{itemize} + +\subsubsection{Recoup operation} + +This API is only used if the exchange is either about to go out of business or +has had its private signing keys compromised. This endpoint needs to be able +to handle age restricted coins as well. The code locations are + +\begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_recoup.c} for the REST endpoint handler \verb|TEH_handler_recoup| + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_recoup-refresh.c} for the REST endpoint handler \verb|TEH_handler_recoup_refresh| +\end{itemize} + + +\subsubsection{Tests} + +Unittests are implemented in +\begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/util/test_crypto.c} + \item \url{https://git.taler.net/exchange.git/tree/src/util/test_age_restriction.c} + \item \url{https://git.taler.net/exchange.git/tree/src/util/tv_age_restriction.c} + \item \url{https://git.taler.net/exchange.git/tree/src/testing/test_exchange_api.c} +\end{itemize} + +More complex scenarios are part of the integrationtests in the wallet +codebase~\ref{wallet-tests}. + +\subsection{Merchant support} + +For age restriction support in the merchant two protocols need to be adjusted: +During \textit{purchase}, the merchant signals and verifies minimum age +requirements and for \textit{deposits} of coins with age restrictions with the +exchange, it provides the hashes of the age commitments. + + +\subsubsection{SQL schema} + +The table \verb|merchange_inventory| as been extended and now carries a +\verb|minimum_age| per entry. Code locations: + +\begin{itemize} + \item \url{https://git.taler.net/merchant.git/tree/src/backenddb/merchant-0001.sql} + \item \url{https://git.taler.net/merchant.git/tree/src/backenddb/plugin_merchantdb_postgres.c} +\end{itemize} + +\paragraph{Purchase and deposit} + +A non-zero minimum age is now beeing sent to the client as part of the contract +of an order. On purchase, the merchant verifies that a non-zero minimum age +requirement is fullfilled when coins with age restrictions are used. Coins from +denominations \textit{without} restriction support are considered to fullfill +any minimum age requirement. Successfully verified coins with age restriction +are then deposited with the exchange. + +Code location: +\url{https://git.taler.net/merchant.git/tree/src/backend/taler-merchant-httpd_post-orders-ID-pay.c} +functions \verb|process_pay_with_exchange| and \verb|parse_pay| + + + +\subsection{Wallet support} + +For the age restriction support in the cross-platform (TypeScript) wallet, the +following parts were implemented: + +\subsubsection{Low-level cryptographic primitives (Edx25519)} + +The low-level cryptographic primitives for Edx25519 (key generation, signature +generation/verification, public/private key derivation) were implemented in the +wallet in pure TypeScript as an extension of the \verb|nacl-fast.js| library. +The \verb|nacl-fast.js| library is a JavasScript-native implementation of various +cryptographic primitives (Ed25519, X25519, Salsa20). + +Since \verb|nacl-fast.js| does not support scalar-scalar multiplication% +\footnote{Like the \texttt{crypto\_core\_ed25519\_scalar\_mul} operation in +libsodium}, we resorted to using the \verb|bigint.js| library (which falls back +to the native BigInteger support of JavaScript on supported platforms) for +scalar-scalar multiplication in the private key derivation function of +Edx25519. + +Code locations: +\begin{itemize} + \item \url{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/nacl-fast.ts} (\verb|crypto_edx25519*|) + \item \url{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.ts#n851} (\verb|namespace Edx25519|) +\end{itemize} + +\subsubsection{High-level cryptographic primitives} +\label{high} + +The high-leve age restriction primitives (generating commitments, deriving +commitments, making attestments) were implemented in the wallet code base, +analogous to the operations found in the C implementation. Note that not all +primitives are implemented (e.g. commitment verification is missing), as this +functionality is not required in the wallet. + +Code location: +\url{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.ts#n966} (namespace \verb|AgeRestrictions|) + +\subsubsection{API changes to wallet-core RPC API} + +The wallet offers a high-level API for clients (such as user interfaces or +CLIs). This API was extended with optional "restrictAge" fields for operations +related to withdrawal (accepting withdrawals, computing fees for withdrawals). + +Code location: +\url{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/walletTypes.ts} (\verb|restrictAge|) + +\subsubsection{Integration into withdrawal and refresh primitives} + +The high-level age restriction operations from \ref{high} where put into use in +the cryptographic primitives used by the withdrawal/refresh operations +(\verb|signDepositPermission| / \verb|deriveRefreshSession| / \verb|createPlanchet|). + +Code location: +\url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/crypto/cryptoImplementation.ts} + +Furthermore, the binary format for signatures has to be changed to accomodate +for the age restriction hash in various messages. + +\subsubsection{Integration into wallet database requests and HTTP requests} + +The database of the wallet was adjusted to store age commentment proofs in +coins/planchets. + +The HTTP requests made by the wallet in the withdrawal/refresh operations were +adjusted to send additional fields for age restrictions. + +Code locations: +\begin{itemize} + \item \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/db.ts} + \item \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/withdraw.ts} + \item \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/refresh.ts} +\end{itemize} + +\subsubsection{Coin/denomination selection} + +The wallet selects denominations during withdrawal and coins during payment. +The implementation had to be made aware of age restrictions, so that e.g. +age-restricted contracts are only paid with coins that have a corresponding age +proof, because otherwise the payment would fail. + +Code location: +\url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/util/coinSelection.ts} + +\subsubsection{Integration test} +\label{wallet-tests} + +In order to test the implementation, a new integration test was added to the +wallet's integration test harness. The harness launches all required +components and makes a payment with age restrictions enabled. + +Code location: +\url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-cli/src/integrationtests/test-age-restrictions.ts} + +\subsection{Edx25519 in GNUnet} +\label{gnunet} + +Our implementation of attestation of minimal age and derivation of age +commitments from existing ones is based on the asymmetric ciphers. For the +derivability of new commitments from existing ones, the underlying +cryptographic primitive must allow for independent derivation of private/public +keys from given private/public keys. + +EcDSA (\url{https://datatracker.ietf.org/doc/html/rfc6979}) has that property +due to its homomorphism of the key generation function, but has its challenges +in terms of secure implementation and performance of existing implementations. +On the other hand, pure EdDSA +(\url{https://datatracker.ietf.org/doc/html/rfc8032}) is not homomorphic, but +is designed more resilient against insecure implementations and fast +implementations are available. + +We therefore decided to define and implement a variant of EdDSA that we call +Edx25519, which is based on ideas from +\href{https://lsd.gnunet.org/lsd0001/#name-pkey}{GNUnet GNS}. We claim that it +maintains all security properties of EdDSA but allows for succesive derivation +of private/public keys from existing ones. + +An pseudo-code definition of Edx25519 is given in appendix \ref{edx25519} and +the implementation in GNUnet is located at +\url{https://git.gnunet.org/gnunet.git/tree/src/util/crypto_edx25519.c} + + +\subsubsection{Test vector generation} + +To ensure that the JavaScript/TypeScript implementation of Edx25519 is +compatible with the implementation in the C codebase (exchange/merchant) on a +binary / wire format level, we added test vectors for Ed25519 operations to the +test vector generation tool (\verb|gnunet-crypto-tvg|, part of the GNUnet library +package). + +Unit tests in the wallet check against test vectors generated with the +\verb|gnunet-crypto-tvg| tool. + +Code locations: +\begin{itemize} + \item \url{https://git.gnunet.org/gnunet.git/tree/src/util/gnunet-crypto-tvg.c#n1204} (\verb|edx25519_derive|) + \item \url{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.test.ts#n410} ("edx test vector") +\end{itemize} + + + +\subsection{User interface and interaction} + +In terms of user interaction with respect to age restriction, a key aspect is +the activation of age restriction during the withdrawal of coins. GNU Taler +has chosen to follow the principle subdiarity and put the decision for age +restriction of coins into the hands of parents/wardends. + +Furthermore, GNU Taler wants to support a relationship of trust and +communication between parents and children. We have therefore adapted a simple +model in which the \textit{child} -- in negotiation and presence of the parent +-- selects the negotiated maximum age (group) of the coin in his/her wallet, +before the parent then transfers money to the corresponding reserve from +his/her bank account. The actual user interface on the wallet therefore is a +simple dropdown menu with the list of available age groups and a description of +their meaning. + +A more vivid narrative for that scenario is given in appendix \ref{scenario}. + +\subsection{Legal considerations} + +The current draft of the full report for the legal considerations with respect +to age restriction in GNU Taler is available in appendix \ref{legal}. Here, we +quote from the conclusions of the report: + +\paragraph{Conclusion to: Legal requirements for merchants to allow Taler’s age + restriction} + +\begin{quotation} + \itshape + To our mind’s eyes, the legal situation and jurisdiction in Germany + allow for the kind of age restriction a Taler payment system offers. + How judges would refer to precedent cases when they consider new cases + involving Taler tokens is subject to further discussion. On one side, + it depends on the intensity and severeness of unlawful behaviour of + merchants, but on the other side responsibility and negligence of + parents and wardens also play a role. In some cases governed by the + German Youth Protection Act, merchants are even held responsible for + negligence of parents who grossly violate their duty to educate the + children by giving consent, offering, providing, making accessible or + presenting media that could harm a child (chapter 4 of § 27 JuSchG14) + + Merchants who are acting lawful and avoid negligence (by taking a look + at delivery addresses and prevent deliveries of explicit adult + material or alcohol to kindergardens for ex- ample) can accept Taler + tokens with age restrictions and feel assured to commit no crime - + under the condition that the merchant’s article database clearly + identifies and differentiates all prohibited / restricted goods. + + Merchants who are acting unlawful cannot so easily transfer the + liability for their own violations to the Taler payment system. This is + in the end also due to the fact that merchants face income transparency + with the acceptance of Taler tokens (think of the auditors’ role in the + Taler system!) and therefore cannot sweep traces of their income + through teenagers who bought adult goods, especially due to the other + fact that teenage clients receive a receipt of purchase into their + wallets and by that could testify the delivery of prohibited goods with + a timestamp that corresponds to the deposit of the spent coins at the + Taler Exchange. For these reasons we believe that merchants who obey + the law will fulfil all requirements for the Taler age restriction to + be legally acceptable. + + The situation in other countries in the EU has to be examined in + further iterations of this document. +\end{quotation} + +\paragraph{Conclusion to: Minors pay with cheated coins} + +\begin{quotation} + \itshape + Legally, Taler’s terms of service should clarify about this + method in order to avoid liability on the Exchange’s side. But the + complicated explanation of the sophisticated mathematical solution + might scare away users and merchants. So, an idea to mitigate this + issue could be to deprecate the explanation and to let Exchange + providers set the security parameter k high enough if cases of abuse + occur. In any case, merchants cannot be held liable for purchases with + forged tokens. This would also not be viable even if Taler’s Terms of + service shift liability to the merchants. It is more or less a question + how much responsibility parents or wardens carry over when their + children or wards try to pay with tampered Taler coins. A comparable + situation exists where minor steal cash from a purse being easily + accessible in a household and the minor pays with the money for adult + goods. + + For these reasons we believe that even if persons exist that + might use unlawful methods to circumvent legality with tokens + replicating pocket money, all other legal requirements for the Taler + age restriction are still fulfilled to be juridically acceptable.\\[\smallskipamount] + + \textbf{Outlook: Next steps}\\ + The following steps for refinement of the legal expertise in this + document will comprise: + \begin{itemize} + \item retrieval of verdicts from law case databases, + \item perception of legal requirements for merchants in different European countries, + \item discussion of literature on automated age verification, laws and cases, + \item further discussion with lawyers and legal experts and + \item a deeper market analysis of competing approaches. + \end{itemize} + + These refinements will be taken into consideration for this document. The Taler + AP3 project will present its results at the upcoming milestone meetings with + NGI Pointer. +\end{quotation} + +\newpage + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\section{P2P payments} + +For the P2P payments, we distinguish three parts of the implementation: +\begin{enumerate} + \item push payments, + \item pull payments, + \item general support logic. +\end{enumerate} + +A basic implementation of all three parts now exists in the exchange, but some +error handling, support logic and more testing remain to be done. Nevertheless, +the API is stable. A general design document is at + \url{https://docs.taler.net/design-documents/013-peer-to-peer-payments.html} +A (possibly slightly out-of-date) API specification draft is at + \url{https://docs.taler.net/core/api-exchange.html#wallet-to-wallet-transfers}. + +While modifications were done in various parts of the Taler exchange logic, we +will here only point out to the main files of the new implementation. In +general, there are always three parts: the server-side logic, the client-side +implementation (in C, a TypeScript client will be implemented in the next +milestone), and a test "command" used to build test cases involving the new +logic. + +\subsection{Push payments} +Push payments are implemented primarily using two endpoints: + +\begin{description} + \item[a] The purse creation places the funds of the payer into a 'purse': + \begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_purses_create.c} + \item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_purse_create_with_deposit.c} + \item \url{https://git.taler.net/exchange.git/tree/src/testing/testing_api_cmd_purse_create_deposit.c} + \end{itemize} + \item[b] With the merge operation, the recipient can accept the funds: + \begin{itemize} + \item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_purses_merge.c} + \item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_purse_merge.c} + \item \url{https://git.taler.net/exchange.git/tree/src/testing/testing_api_cmd_purse_merge.c} + \end{itemize} +\end{description} + + +\subsection{Pull payments} + +Pull payments are also implemented using two similar endpoints. + + +\begin{description} + \item[(a)] Pull payments begin with a payment request tied to the recipient: + + \begin{itemize} +\item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_reserves_purse.c} +\item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_purse_create_with_merge.c} +\item \url{https://git.taler.net/exchange.git/tree/src/testing/testing_api_cmd_reserve_purse.c} + \end{itemize} + + \item[(b)] With a deposit operation, the payer satisfies the request: + + \begin{itemize} +\item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_purses_deposit.c} +\item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_purse_deposit.c} +\item \url{https://git.taler.net/exchange.git/tree/src/testing/testing_api_cmd_purse_deposit.c} + \end{itemize} +\end{description} + + +\subsection{Supporting APIs} + +\begin{description} + \item[(a)] Parties may use the exchange to communicate the actual contract that is the +basis for the payment. This API allows the non-initiating party to receive the details: + + \begin{itemize} +\item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_contract.c} +\item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_contracts_get.c} +\item \url{https://git.taler.net/exchange.git/tree/src/testing/testing_api_cmd_contract_get.c} + \end{itemize} + +\item[(b)] After the business is concluded, the initiating party may want to check that the +process has completed. This is done by long-polling on the purse: + + \begin{itemize} +\item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_purses_get.c} +\item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_purses_get.c} + \end{itemize} + +\item[(c)] The operator needs to be able to configure fees and other key parameters of the +operation. This is done using the management endpoint: + + \begin{itemize} +\item \url{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_management_global_fees.c} +\item \url{https://git.taler.net/exchange.git/tree/src/lib/exchange_api_management_set_global_fee.c} +\item \url{https://git.taler.net/exchange.git/tree/src/testing/testing_api_cmd_offline_sign_global_fees.c} + \end{itemize} +\end{description} + +\subsection{Integration tests} +Finally, an (incomplete) integration test is here: + +\url{https://git.taler.net/exchange.git/tree/src/testing/test_exchange_p2p.c} + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\newpage +\section{Anonymous auctions} + +We did an extensive survey of the current scientific literature on anonymous, +sealed-bid auctions and decided to follow the works of +\cite{Brandt02,Brandt06,BraSan08} and the recent implementation from +\cite{Teich20}. In particular, we propose +\begin{enumerate} + \item an escrow service as extenstion to Taler exchange + \item to design and implement an auction service based on \texttt{libbrandt} +\end{enumerate} + + +\begingroup +\subsubsection*{References} +\renewcommand{\section}[2]{}% +\begin{thebibliography}{9} + \bibitem{Brandt02} + Felix Brandt, + \textit{A verifiable, bidder-resolved Auction Protocol}, in + Proceedings of the 5th International Workshop on Deception, + Fraud and Trust in Agent Societies (Special Track on Privacy + and Protection with Multi-Agent Systems), 2002, DOI: + \url{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.18.1380&rep=rep1&type=pdf} + \bibitem{Brandt06} + Felix Brandt, \textit{How to obtain full privacy in auctions}, + in International Journal of Information Security, 2006, volume + 5, issue 4,pages 201-216, DOI: + \url{http://www.springerlink.com/openurl.asp?genre=article&id=doi:10.1007/s10207-006-0001-y} + \bibitem{BraSan08} + Felix Brandt and Tuomas Sandholm, \textit{On the existence of + unconditionally privacy-preserving auction protocols}, in ACM + Transactions on Information and System Security, volume 11, + issue 2, 2008, DOI: + \url{http://doi.acm.org/10.1145/1330332.1330338} + \bibitem{Teich20} + Markus Teich, \textit{Implementing Privacy Preserving Auction Protocols}, + Master's thesis, 2020, TU München +\end{thebibliography} +\endgroup + +\subsection{Escrow service in the exchange} + +The current draft of the design document for the escrow service is published under +\url{https://docs.taler.net/design-documents/028-proof-of-escrow.html}. + +An escrow service is a intermediary between two parties and must trusted by +both. In the GNU Taler payment system, this role is per definition played by +the exchange for buyers and sellers during purchases. The auditor controls the +exchange and is also a mediator between buyers and selles. + +The role of the exchange can be therefore extended to the specific needs of +escrow. In contrast to purchase/deposit, for escrow, particular coins are +locked, but not spent. This prohibits their spending for a specific timespan +and until a valid order of release is provided. + +However, in the context of auctions, we want the parties to be able to verify +the fairness of the participants. For example, a seller of goods during an +auction shall only be able to relase the money for the winning bidder and not +for the others. On the other hand, both, sellers and bidders should be able +provide evidence to the exchange and auditor if the other party wasn’t honest, +f.e. if the winning bidder hasn’t released the money. + +We propose a the following endpoints: + +\begin{description} + \item[\texttt{POST /escrows/\$ESCROW\_ID/register}] -- Register an escrow + account under the provided EdDSA public key \verb|$ESCROW_ID|. + The required parameters are: + \begin{itemize} + \item a starttime + \item an endttime + \item an interval $[m, M]$ of minimum and maximum + amounts, where $M$ can also be $\infty$. + \end{itemize} + \item[\texttt{GET /escrows/\$ESCROW\_ID}] -- Return the terms of the escrow + and the current list of depositor IDs. + \item[\texttt{POST /escrows/\$ESCROW\_ID/deposit/\$DEPOSIT\_ID}] -- Deposit a + specific amount with a particular list of coins. The required + parameters are: + \begin{itemize} + \item the amount a to be deposited (must lie in $[m, M]$) + \item the list of coins to be used for the deposit (the + sum of the values must be at least a) + \item signatures from each coin over the SHA512 hash of + the amount a, the \verb|$DEPOSIT_ID| and the + \verb|$ESCROW_ID|. + + \end{itemize} + The \verb|$DEPOSIT_ID| is the SHA512 hash over all the coins. + + \item[\texttt{POST /escrows/\$ESCROW\_ID/claim/\$DEPOSIT\_ID}] -- The owner + of the private key for \verb|$ESCROW_ID| can claim the + deposited coins. It has to provide + \begin{itemize} + \item the particular amount a' to be claimed + \item the list of coins to be claimed from the deposit + \item signatures over the SHA512 hash of the amount a', + \verb|$ESCROW_ID| and the \verb|$DEPOSIT_ID|, + signed by each coin + \end{itemize} +\end{description} + +An sketch of the protocol flow of the escrow services is given in +figure~\ref{escrow-flow}. + +\begin{figure}[htbp] + \label{escrow-flow} + \centering \includegraphics[height=20cm]{escrow-flow.png} + \caption{Flow of the escrow service} +\end{figure} + +\subsection{Auction service based on \texttt{libbrandt}} + +After finalizing the escrow service for the exchange, we plan to implement a +proof-of-concept auction system based on the implementation in +\url{https://git.gnunet.org/libbrandt.git/}. + +The service will provide an API of roughly the following endoints: + +\begin{description} + \item[/create] -- Initiate an auction as a seller, returns a description + of the auction + + \item[/join] -- Join an auction as a bidder, providing the auction + description and a proof of escrow. + + \item[/info] -- Retrieve status information of running auctions, extract + information of particular auctions. + +\end{description} + +The computation of the winning bid and the bidder will be done anonymously by +each bidder (and seller) using informations from the \texttt{info} endpoints +and the algorithm performed over them from \texttt{libbrandt}. + +The winning bidder can then initiate the flow for the claiming the goods and +releasing the deposit in the escrow. + + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\newpage +\part*{Appendix} +\addcontentsline{toc}{part}{Appendix} +\appendix +\section{Edx25519} +\label{edx25519} + +Edx25519 is a variant of EdDSA on curve25519 which allows for repeated +derivation of private and public keys, independently. The private keys +in Edx25519 initially correspond to the data after expansion and +clamping in EdDSA. However, this correspondence is lost after deriving +further keys from existing ones. The public keys and signature +verification are compatible with EdDSA. + +The scheme that has been implemented is as follows: + +\begin{verbatim} +/* Private keys in Edx25519 are pairs (a, b) of 32 byte each. + * Initially they correspond to the result of the expansion + * and clamping in EdDSA. + */ + +Edx25519_generate_private(seed) { + /* EdDSA expand and clamp */ + dh := SHA-512(seed) + a := dh[0..31] + b := dh[32..64] + a[0] &= 0b11111000 + a[31] &= 0b01111111 + a[31] |= 0b01000000 + + return (a, b) +} + +Edx25519_public_from_private(private) { + /* Public keys are the same as in EdDSA */ + (a, _) := private + return [a] * G +} + +Edx25519_blinding_factor(P, seed) { + /* This is a helper function used in the derivation of + * private/public keys from existing ones. */ + h1 := HKDF_32(P, seed) + + /* Ensure that h == h % L */ + h := h1 % L + + /* Optionally: Make sure that we don't create weak keys. */ + P' := [h] * P + if !( (h!=1) && (h!=0) && (P'!=E) ) { + return Edx25519_blinding_factor(P, seed+1) + } + + return h +} + +Edx25519_derive_private(private, seed) { + /* This is based on the definition in + * GNUNET_CRYPTO_eddsa_private_key_derive. But it accepts + * and returns a private pair (a, b) and allows for iteration. + */ + (a, b) := private + P := Edx25519_public_key_from_private(private) + h := Edx25519_blinding_factor(P, seed) + + /* Carefully calculate the new value for a */ + a1 := a / 8; + a2 := (h * a1) % L + a' := (a2 * 8) % L + + /* Update b as well, binding it to h. + This is an additional step compared to GNS. */ + b' := SHA256(b || h) + + return (a', b') +} + +Edx25519_derive_public(P, seed) { + h := Edx25519_blinding_factor(P, seed) + return [h]*P +} + +Edx25519_sign(private, message) { + /* As in Ed25519, except for the origin of b */ + (d, b) := private + P := Edx25519_public_from_private(private) + r := SHA-512(b || message) + R := [r] * G + s := r + SHA-512(R || P || message) * d % L + + return (R,s) +} + +Edx25519_verify(P, message, signature) { + /* Identical to Ed25519 */ + (R, s) := signature + return [s] * G == R + [SHA-512(R || P || message)] * P +} + +\end{verbatim} + +\newpage +\section{Age-restricted payments scenario} +\label{scenario} +Sarah’s daughter Alice is turning 11 this year, and Sarah is thinking about her +birthday present. Alice is an avid gamer, and Sarah thinks Alice would enjoy a +new video game. Sarah does not want to pick the game for Alice: she would like +Alice to choose and buy the game herself. So Sarah plans to give Alice the +money to purchase whichever game she likes. + +However, Sarah also worries about the possibility of Alice buying a game that +is not appropriate for her age. To give Alice the independence to choose and +buy her own game, while constraining her purchase to age-appropriate content, +Sarah decides to use Alice’s Taler mobile wallet to send her the birthday +money. + +Sarah sits down with Alice and explains her birthday present will be some money +for a new video game. Alice is really happy about that: “Exactly what I +wanted!”, she replies. Sarah asks Alice to grab her phone and open her mobile +wallet. Together, they start a Taler “withdrawal”: the process of getting money +into Alice’s wallet. Alice asks Sarah what’s the amount she wants to give her, +and Sarah says 30 euros. Alice enters the amount in the wallet, and taps the +“withdrawal” button. “Actually”, says Sarah, “could you go back for a second? +There is something else we should do”. Alice taps the back button and returns +to the “withdrawal” screen. “Do you see that ‘age’ option there?”, Sarah asks. +“Could you tap it for me?”. Alice taps on the ‘age’ option, and 4 choices come +up: + +\begin{itemize} + \itemsep0em + \item up to 6 years old + \item up to 11 years old + \item up to 15 years old, and + \item up to 17 years old +\end{itemize} + +Sarah asks Alice to tap the “up to 11 years old” option. Alice asks what this +means. Sarah explains the money Alice will receive can only be spent on things +that are appropriate for children who are younger than 11. Alice asks why does +this matter. Sarah tells Alice that many games include things that could be +upsetting or hard to understand for a 10-year old. “I trust you, Alice”, Sarah +says: “this is more for my peace of mind. I hope you understand.” Alice is left +wondering what those ‘hard to understand’ things may be. + +Alice taps the “withdrawal” button once again, and a QR code shows up. Sarah +takes her own phone, opens her camera and scans the QR code. She is prompted to +choose one of her mobile banking apps. Sarah taps one of the banking apps, +authenticates using her PIN, and is asked to confirm the 50 euro transfer to +Alice’s Taler wallet. Sarah confirms the transaction, and Alice’s phone pings: +a notification confirming the 30 euro have arrived! Alice gives Sarah a big hug +and thanks her for the present. Now she just needs to decide which game to buy. + +After thinking about it for a bit, Alice decides to buy the Dragon Ball +FighterZ game to play in her computer. She has never played a fighter game +before, but her friends have told them this one is a lot of fun. + +She visits her favourite online game store and searches for the game. She +quickly goes through the purchase process, and when she reaches the payment +page, she chooses the “Pay with Taler” option. The game store displays a QR +code, which Alice scans with her phone. This opens the payment page in the +Taler wallet. Alice taps the “Pay now” button, but instead of the usual +confirmation page, Alice sees a notification telling her she does not have +funds to pay for over-12 content. Below the notification, some text explains +that the Dragon Ball FighterZ has been rated as suitable for children over 12 +years old, and her Taler balance is limited to purchases suitable for children +who are 11 or younger. + +Alice remembers the age option Sarah asked her to choose when receiving her +birthday money, and guesses that is the reason why she cannot buy Dragon Ball +FighterZ. Luckily, Alice has a plan B: buying Ever Forward instead. Because +Ever Forward is rated as suitable for children over 7, Alice is able to +complete the game purchase with her Taler wallet. + +\newpage +\includepdf[pagecommand=\section{Age restriction and Legal Issues}\label{legal},frame=true,pages=1,scale=.9]{Age_restriction_and_legal_issues.pdf} +\includepdf[pages=2-,scale=.9,frame=true]{Age_restriction_and_legal_issues.pdf} +\end{document}