955 lines
39 KiB
TeX
955 lines
39 KiB
TeX
\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}
|