taler/ngi-pointer-ap3
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

init

Browse Source
This commit is contained in:
Özgür Kesim 2022-05-02 16:53:23 +02:00
commit 233fe0bb2c
4 changed files with 955 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored Normal file
View File

@ -0,0 +1 @@
*.pdf

BIN
Age_restriction_and_legal_issues.pdf Normal file
View File

Binary file not shown.

BIN
escrow-flow.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 85 KiB

954
ngi-ap3-m2-report.tex Normal file
View File

@ -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}{<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}