\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}