781 lines
37 KiB
TeX
781 lines
37 KiB
TeX
\documentclass{scrartcl}
|
||
\usepackage[a4paper]{geometry}
|
||
\usepackage{hyperref}
|
||
\usepackage[dvipsnames]{xcolor}
|
||
\hypersetup{
|
||
colorlinks = true,
|
||
allcolors = {black},
|
||
linkcolor = DarkOrchid,
|
||
urlcolor = DarkOrchid,
|
||
}
|
||
\usepackage{url}
|
||
\usepackage[font=footnotesize]{caption}
|
||
\usepackage{amssymb}
|
||
\usepackage{amsmath}
|
||
\usepackage{pdfpages}
|
||
\usepackage{graphicx}
|
||
\usepackage{listings}
|
||
\usepackage{fontspec}
|
||
\usepackage{menukeys}
|
||
\usepackage{tikz}
|
||
\usetikzlibrary{tikzmark}
|
||
\usetikzlibrary{shapes,arrows,arrows.meta}
|
||
\usetikzlibrary{positioning,patterns}
|
||
\usetikzlibrary{calc}
|
||
\setmonofont[Path = ../fonts/,
|
||
Extension = .ttf,
|
||
UprightFont = *-Regular,
|
||
ItalicFont = *-Italic,
|
||
BoldFont = *-Bold,
|
||
Scale=0.85]{RobotoMono}
|
||
|
||
\lstdefinelanguage{typescript}{
|
||
keywords={typeof, new, true, false, catch, function, return, null, catch, switch, var, if, in, while, do, else, case, break, interface},
|
||
keywordstyle=\bfseries,
|
||
ndkeywords={class, export, boolean, number, Amount, string, Timestamp, RelativeTime, EddsaPublicKey, BrandtVickreyAuction, BrandtVickreyAuctionMessage, BrandtVickreyAuctionWinner, EddsaSignature, HashCode, throw, implements, import, this, BrandtVickreyReplayOutcome},
|
||
ndkeywordstyle=\bfseries,
|
||
identifierstyle=\color{black},
|
||
sensitive=false,
|
||
comment=[l]{//},
|
||
morecomment=[s]{/*}{*/},
|
||
commentstyle=\itshape,
|
||
%stringstyle=\color{red},
|
||
morestring=[b]',
|
||
morestring=[b]"
|
||
}
|
||
|
||
\lstset{
|
||
language=typescript,
|
||
%backgroundcolor=\color{lightgray},
|
||
extendedchars=true,
|
||
basicstyle=\footnotesize\color{NavyBlue}\ttfamily,
|
||
showstringspaces=false,
|
||
showspaces=false,
|
||
%numbers=left,
|
||
%numberstyle=\footnotesize,
|
||
%numbersep=9pt,
|
||
tabsize=2,
|
||
breaklines=true,
|
||
showtabs=false,
|
||
captionpos=b,
|
||
emphstyle=\bfseries
|
||
}
|
||
\newcommand{\TODO}[1]{{\color{orange}#1}\marginpar{{\color{orange}TODO}}}
|
||
\include{definitions}
|
||
|
||
\begin{document}
|
||
|
||
\title{AP³\\
|
||
Report for Milestone IV\\
|
||
NGI Pointer}
|
||
\author{Özgür Kesim\\
|
||
Christan Grothoff\\
|
||
Florian Dold\\
|
||
Stefan Kügel\\
|
||
Emmanuel Benoist\\[\bigskipamount]
|
||
\normalsize Mentor: Mirko Ross \href{mailto:m.ross@digital-worx.de}{<m.ross@digital-worx.de>}\\[\medskipamount]
|
||
}
|
||
|
||
\date{October 29, 2022}
|
||
|
||
\maketitle
|
||
|
||
\section*{Management summary}
|
||
\begin{abstract}
|
||
\noindent
|
||
For the \textsc{NGI Pointer} programme, the AP³ project team extended GNU Taler with
|
||
\begin{itemize}
|
||
\item age-restricted payments,
|
||
\item peer-to-peer (P2P) payments and
|
||
\item a proof-of-concept escrow functionality for
|
||
privacy-preserving auctions.
|
||
\end{itemize}
|
||
|
||
This document provides the report for the final milestone IV with details on
|
||
the results of our usability study, the state of the implementation of
|
||
the features and projected future work.
|
||
|
||
\end{abstract}
|
||
|
||
\vfill
|
||
\hfill {\footnotesize Version: 1.0}
|
||
|
||
\thispagestyle{empty}
|
||
|
||
\newpage
|
||
\tableofcontents
|
||
\newpage
|
||
|
||
|
||
\section{Age Restriction}
|
||
|
||
We designed and implemented a scheme for age restriction in GNU Taler based on
|
||
the following basic ideas:
|
||
|
||
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 $\DeriveCompare$, that gives the minor a 1/$\kappa$ chance to raise
|
||
the minimum age for the new coin).
|
||
|
||
Figure~\ref{scheme} gives an overview of the scheme for age restriction
|
||
detached from the payment flow.
|
||
|
||
\begin{figure}[h]
|
||
\begin{center}\footnotesize
|
||
\begin{tikzpicture}[scale=.8]
|
||
\node[circle,minimum size=25pt,fill=black!15] at ( 0:0) (Client) {$\Child$};
|
||
\node[circle,minimum size=25pt,fill=black!15] at ( 60:5) (Exchange) {$\Exchange$};
|
||
\node[circle,minimum size=25pt,fill=black!15] at ( 0:5) (Merchant) {$\Merchant$};
|
||
\node[circle,minimum size=25pt,fill=blue!15] at (130:3) (Guardian) {$\Guardian$};
|
||
|
||
\draw[orange,<->] (Client) to node[sloped,below,align=center]
|
||
{\orange{$\DeriveCompare$}} (Exchange);
|
||
\draw[blue,->] (Client) to node[sloped, below]
|
||
{\blue{$(\attest_\minage, \commitment)$}} (Merchant);
|
||
|
||
\draw[->] (Guardian) to [out=150,in=70, loop] node[above]
|
||
{$\Commit(\age)$} (Guardian);
|
||
\draw[->] (Guardian) to node[below,sloped]
|
||
{($\commitment$, $\pruf_\age$)} (Client);
|
||
\draw[->,blue] (Client) to [out=-50,in=-130, loop] node[below]
|
||
{\blue{$\Attest(\minage, \commitment, \pruf_{\age})$}} (Client);
|
||
\draw[->,blue] (Merchant) to [out=-50,in=-130, loop] node[below]
|
||
{\blue{$\Verify(\minage, \commitment, \attest_{\minage})$}} (Merchant);
|
||
\end{tikzpicture}
|
||
\end{center}
|
||
\caption{Scheme of the age restriction performed between a guardian
|
||
$\Guardian$, a child $\Child$, a merchant $\Merchant$ and an exchange
|
||
$\Exchange$, using the functions $\Commit$, $\Attest$, $\Verify$ and
|
||
the zero-knowledge protocol $\DeriveCompare$ which is based on
|
||
functions $\Derive$ and $\Compare$. $\commitment$ is the age
|
||
commitment for a maximum age $\age \in \{1,...,\Age\}$ and
|
||
$\pruf_{\age}$ is the corresponding proof. $\attest_{\minage}$ is an
|
||
attestation of a required age $\minage \leq \age$.}
|
||
\label{scheme}
|
||
\end{figure}
|
||
|
||
We have implemented all parts of this scheme in GNU Taler's exchange, wallet
|
||
and merchant code bases for the most common protocols: withdraw, purchase,
|
||
deposit and refresh.
|
||
|
||
\subsection{Technical details}
|
||
|
||
Our implementation of the five functions $\Commit$, $\Attest$, $\Verify$,
|
||
$\Derive$ and $\Compare$ is based on the following main building blocks:
|
||
|
||
\begin{itemize}
|
||
\item The exchange $\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 $\Age$ of pairs of
|
||
\href{https://docs.taler.net/design-documents/024-age-restriction.html#edx25519}{Edx25519}
|
||
public and private keys on Curve25519. In other words: one key
|
||
pair for each age group after the zeroth: $\bigl\langle (p_1,
|
||
q_1), \ldots, (p_M, q_M) \bigr\rangle$. (Here, $p_i$ are
|
||
\textit{private} and $q_i$ are public keys).
|
||
|
||
\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, q_1), \ldots, (p_m, q_m),
|
||
\, (\perp, q_{m+1}),
|
||
\ldots, (\perp, q_M)\bigr\rangle
|
||
\] F.e. if none of the private keys is provided, the age
|
||
commitment would be restricted to the zeroth age group.
|
||
|
||
Note that the action of dropping private keys is performed by
|
||
the guardian $\Guardian$.
|
||
|
||
\item An \textit{age commitment} (without prefix) is just the vector of
|
||
public keys: $\commitment := \langle q_1, \ldots, q_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 A child $\Child$ receives the commitment $\commitment$ along with
|
||
the proof, the restricted vector\\
|
||
$\pruf_\age := (p_1,\ldots,p_\age,\perp,\ldots,\perp)$.
|
||
$\Child$ can now create an \textit{attestation}
|
||
$\attest_\minage$ for age group $\minage \leq \age$, which is
|
||
simply a signature to some message with the private key
|
||
$p_\minage$.
|
||
|
||
\item An age commitment $\commitment$ is bound to a particular coin
|
||
$C_p$ by incorporating the SHA256 hash value of $\commitment$
|
||
into the signature of the coin. So, instead of signing the
|
||
full-domain-hash $\text{FDH}(C_p)$ with the RSA private key of
|
||
a denomination, the exchange signs $\text{FDH}(C_p,
|
||
\orange{H(\commitment)})$.
|
||
|
||
\item $\DeriveCompare$ is a zero-knowledge, cut-and-choose protocol,
|
||
using the functions $\Derive$ and $\Compare$, which allows
|
||
$\Child$ to derive new commitments from existing ones in an
|
||
unlinkable way and $\Exchange$ to statistically trust them to
|
||
be equivalent. The protocol is defined roughly as follows,
|
||
with $\kappa \in \N$ the security parameter (currently $\kappa
|
||
= 3$):
|
||
\begin{enumerate}
|
||
\item $\Child$ derives commitments $(\commitment_1,\dots,\commitment_\kappa)$
|
||
from $\commitment_0$ by calling $\Derive()$ \\ with blindings $(\beta_1,\dots,\beta_\kappa)$
|
||
\item $\Child$ calculates $h_0:=H\left(H(\commitment_1, \beta_1)||\dots||H(\commitment_\kappa, \beta_\kappa)\right)$
|
||
\item $\Child$ sends $\commitment_0$ and $h_0$ to $\Exchange$
|
||
\item $\Exchange$ chooses $\gamma \in \{1,\dots,\kappa\}$ randomly
|
||
\item $\Child$ reveals $h_\gamma:=H(\commitment_\gamma, \beta_\gamma)$ and all $(\commitment_i, \beta_i)$, except $(\commitment_\gamma, \beta_\gamma)$
|
||
\item $\Exchange$ compares $h_0$ and
|
||
$H\left(H(\commitment_1, \beta_1)||...||h_\gamma||...||H(\commitment_\kappa, \beta_\kappa)\right)$
|
||
and \\ evaluates $\Compare(\commitment_0, \commitment_i, \beta_i)$.
|
||
\end{enumerate}
|
||
|
||
\end{itemize}
|
||
|
||
The integration of both schemes for age restriction and the scheme for payment
|
||
in GNU Taler (protocols \textsf{withdraw}, \textsf{purchase}, \textsf{deposit}
|
||
and \textsf{refresh}) is sketched in Figure~\ref{bothschemes}.
|
||
\begin{figure}[ht]
|
||
\begin{center}
|
||
\begin{tikzpicture}[scale=.9]
|
||
\node[circle,minimum size=25pt,fill=black!15] at ( 0:0) (Client) {$\Child$};
|
||
\node[circle,minimum size=25pt,fill=black!15] at ( 60:5) (Exchange) {$\Exchange$};
|
||
\node[circle,minimum size=25pt,fill=black!15] at ( 0:5) (Merchant) {$\Merchant$};
|
||
\node[circle,minimum size=25pt,fill=blue!15] at (130:3) (Guardian) {$\Guardian$};
|
||
|
||
\draw[<->] (Guardian) to node[sloped,above,align=center]
|
||
{\textsf{withdraw}\orange{, using}\\ $\FDH(C_p\orange{, H(\commitment)})$} (Exchange);
|
||
\draw[<->] (Client) to node[sloped,below,align=center]
|
||
{\textsf{refresh} \orange{ + }\\ \orange{$\DeriveCompare$}} (Exchange);
|
||
\draw[<->] (Client) to node[sloped, below]
|
||
{\textsf{purchase} \blue{+ $(\attest_\minage, \commitment)$}} (Merchant);
|
||
\draw[<->] (Merchant) to node[sloped, above]
|
||
{\textsf{deposit} \orange{+ $H(\commitment)$}} (Exchange);
|
||
|
||
\draw[->] (Guardian) to [out=70,in=150, loop] node[above]
|
||
{$\Commit(\age)$} (Guardian);
|
||
\draw[->] (Guardian) to node[below,sloped]
|
||
{($\commitment$, $\pruf_\age$)} (Client);
|
||
\draw[->,blue] (Client) to [out=-50,in=-130, loop] node[below]
|
||
{\blue{$\Attest(\minage, \commitment, \pruf_{\age})$}} (Client);
|
||
\draw[->,blue] (Merchant) to [out=-50,in=-130, loop] node[below]
|
||
{\blue{$\Verify(\minage, \commitment, \attest_{\minage})$}} (Merchant);
|
||
\end{tikzpicture}
|
||
\end{center}
|
||
\caption{Sketch of the integration of the schemes for age restriction
|
||
and payment in GNU Taler.}
|
||
\label{bothschemes}
|
||
\end{figure}
|
||
|
||
The proposed solution maintains the guarantees of GNU Taler with respect to
|
||
anonymity and unlinkability. Precise formulations of the functions, protocols,
|
||
requirements and security guarantees---together with proofs---can be found in
|
||
our paper
|
||
\href{https://taler.net/papers/esorics2022-age-restriction.pdf}
|
||
{\textit{Zero-Knowledge Age Restriction for GNU Taler}},
|
||
published in the
|
||
\href{https://link.springer.com/chapter/10.1007/978-3-031-17140-6\_6}
|
||
{proceedings to ESORICS 2022}.
|
||
|
||
|
||
|
||
\subsection{Legal evaluation}
|
||
|
||
We are in correspondence with the \href{https://www.kjm-online.de/en/}{German
|
||
Commission for the Protections of Minors in the Media (KJM)}. The commission
|
||
acts as the central supervisory body for the protection of minors in private
|
||
broadcasting and media in Germany and runs a Berlin-based joint office of state
|
||
authorities for media and journalism within the Federal republic of Germany.
|
||
Its plenary congregation meets in Berlin on December 7, 2022, for which GNU
|
||
Taler applies with a systematic description and the whitepaper on Taler tokens
|
||
with age restrictions in German language. The application is assisted and
|
||
coordinated by Mr. Henning Mellage, Legal \& Supervision Officer, at the
|
||
Landesanstalt für Medien NRW in Düsseldorf which is part of the KJM.
|
||
|
||
The KJM confirmed its intention to evaluate GNU Taler as recommendable concept
|
||
for the protection of minors and to add GNU Taler to its list of positively
|
||
evaluated, so-called ``cross-channel concepts'' at
|
||
\href{https://www.kjm-online.de/en/supervision/technical-protection-of-minors-in-the-media/cross-channel-concepts}%
|
||
{\texttt{https://www.kjm-online.de/en/supervision/{\small \keys{\return}}\\
|
||
technical-protection-of-minors-in-the-media/cross-channel-concepts}}. This
|
||
includes the presentation of GNU Taler in the document
|
||
\href{https://www.kjm-online.de/fileadmin/user_upload/KJM/Aufsicht/Technischer_Jugendmedienschutz/Uebergreifende_Jugendschutzkonzepte.pdf}{\textit{Übersicht
|
||
über positiv bewertete übergreifende Jugendschutzkonzepte}}, which mirrors the
|
||
content of the mentioned website with recommended concepts of youth protection.
|
||
|
||
GNU Taler is going to be evaluated for the category ``holistic youth protection
|
||
concept''. The KJM uses this category only for concepts that are widely
|
||
accessible to the public and \textit{do not} serve a closed user group. Here,
|
||
\textit{serving a closed user group} means granting access to content or goods
|
||
only after ID-based verification of the membership in a particular group, such
|
||
as: proof of belonging to a certain age-group by presenting an official ID
|
||
card, driving licenses or the like---a type of verification which is
|
||
endangering privacy, data security, and informational self-determination.
|
||
|
||
\subsection{Future Works}
|
||
|
||
\begin{description}
|
||
\item[Finishing support for age restriction:] So far, age-restriction
|
||
is not available in P2P payments when the age data is obtained
|
||
from the KYC process. Also, the tipping protocol doesn't allow
|
||
for denominations with age restriction, yet. We will add
|
||
support for age-restriction in those scenarios.
|
||
|
||
\item[Support for minors with bank accounts:] The current design
|
||
of age restriction is based on the assumption that only
|
||
adults can have bank accounts. That is: wire transfers to the
|
||
exchange are assumed to be originated by adults.
|
||
|
||
However, in some countries, like Germany, it is possible for
|
||
minors to have bank accounts, too, starting from a certain age.
|
||
In those cases, the wire transfer record will indicate that the
|
||
originating account is owned by a minor.
|
||
|
||
We plan to extend the current design and implementation of age
|
||
restriction to handle those situations as well: After the
|
||
exchange receives a wire transfer from a bank account of a
|
||
minor, it will require in a zero-knowledge-proof for a) the
|
||
presence of age restriction and b) the appropriate
|
||
\textit{maximum} age for the age commitment during the
|
||
\textsf{withdraw} protocol.
|
||
|
||
\end{description}
|
||
|
||
|
||
\subsection{Links}
|
||
|
||
Our scheme for age restriction in GNU Taler has been
|
||
\href{https://link.springer.com/chapter/10.1007/978-3-031-17140-6\_6}{published
|
||
in the proceedings to ESORICS 2022}.
|
||
In addition,
|
||
\href{https://docs.taler.net/design-documents/024-age-restriction.html}%
|
||
{document 24} at \url{https://docs.taler.net/design-documents} also lays out
|
||
the design. The implementation is distributed across multiple repositories:
|
||
|
||
{
|
||
\begin{description}
|
||
\item[Exchange:] The following REST endpoint handlers and their
|
||
accompanying helper functions in
|
||
\url{https://git.taler.net/exchange.git/tree/src}:
|
||
\begin{itemize}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_deposit.c}{\texttt{TEH\_handler\_deposit}}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_melt.c}{\texttt{TEH\_handler\_melt}}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_refreshes_reveal.c}{\texttt{TEH\_handler\_reveal}}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_recoup.c}{\texttt{TEH\_handler\_recoup}}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/exchange/taler-exchange-httpd_recoup-refresh.c}{\texttt{TEH\_handler\_recoup\_refresh}}
|
||
\end{itemize}
|
||
|
||
Under \url{https://git.taler.net/exchange.git/tree/src/exchangedb}:\\
|
||
\href{https://git.taler.net/exchange.git/tree/src/exchangedb/common.sql}{common.sql},
|
||
\href{https://git.taler.net/exchange.git/tree/src/exchangedb/exchange-0001.sql}{exchange-0001.sql},
|
||
\href{https://git.taler.net/exchange.git/tree/src/exchangedb/plugin\_exchangedb\_postgres.c}{plugin\_exchangedb\_postgres.c}.
|
||
|
||
\item[Merchant:]
|
||
Under \url{https://git.taler.net/merchant.git/tree/src/},
|
||
\begin{itemize}
|
||
\item schema changes in
|
||
\href{https://git.taler.net/merchant.git/tree/src/backenddb/merchant-0001.sql}{backenddb/merchant-0001.sql} and\\
|
||
\href{https://git.taler.net/merchant.git/tree/src/backenddb/plugin_merchantdb_postgres.c}{backenddb/plugin\_merchantdb\_postgres.c}
|
||
\item functions \verb|process_pay_with_exchange| and \verb|parse_pay| in\\
|
||
\href{https://git.taler.net/merchant.git/tree/src/backend/taler-merchant-httpd_post-orders-ID-pay.c}{backend/taler-merchant-httpd\_post-orders-ID-pay.c}
|
||
\end{itemize}
|
||
|
||
\item[Wallet:]
|
||
Under \url{https://git.taler.net/wallet-core.git/tree/packages/taler-util}
|
||
\begin{itemize}
|
||
\item low-level cryptographic primitives in
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/nacl-fast.ts}{\texttt{crypto\_edx25519}} and
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.ts#n851}{namespace \texttt{Edx25519}}
|
||
\item high-level cryptographic primitives in
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/talerCrypto.ts#n966}{namespace \texttt{AgeRestrictions}}
|
||
\item API changes to wallet-core RPC API in
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/walletTypes.ts}{\texttt{restrictAge}}
|
||
\end{itemize}
|
||
Under \url{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/}
|
||
\begin{itemize}
|
||
\item withdrawal and refresh primitives in \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/crypto/cryptoImplementation.ts}{\texttt{crypto/cryptoImplementation.ts}}
|
||
\item wallet database requests and HTTP requests in \\
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/db.ts}{\texttt{db.ts}},
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/withdraw.ts}{\texttt{withdraw.ts}} and
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/refresh.ts}{\texttt{refresh.ts}}
|
||
\item coin/denomination selection in
|
||
\href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/util/coinSelection.ts}{\texttt{util/coinSelection.ts}}
|
||
\end{itemize}
|
||
|
||
|
||
\item[Tests:] Under \url{https://git.taler.net/exchange.git/tree/src}:
|
||
\begin{itemize}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/util/test\_crypto.c}{util/test\_crypto.c}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/util/test\_age\_restriction.c}{util/test\_age\_restriction.c}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/util/tv\_age\_restriction.c}{util/tv\_age\_restriction.c}
|
||
\item \href{https://git.taler.net/exchange.git/tree/src/testing/test\_exchange\_api.c}{testing/test\_exchange\_api.c}
|
||
\end{itemize}
|
||
\end{description}
|
||
|
||
|
||
The definition of Edx25519, a variant of EdDSA that we designed for usage in
|
||
our age restriction scheme in GNU Taler, and its implementation is located at
|
||
\url{https://git.gnunet.org/gnunet.git/} in file
|
||
\href{https://git.gnunet.org/gnunet.git/tree/src/util/crypto\_edx25519.c}{util/crypto\_edx25519.c}.
|
||
|
||
}
|
||
|
||
|
||
|
||
\newpage
|
||
\section{P2P Payments}
|
||
|
||
We implemented two styles of P2P payments: \textbf{push payments} where a
|
||
user sends money to another Taler wallet (which can then accept the
|
||
payment), and \textbf{pull payments} where a user sends an invoice to
|
||
another Taler wallet (which can then pay the invoice).
|
||
|
||
Both styles of payment only require one asynchronous uni-directional
|
||
secure communication between the wallets to make the payment. The
|
||
information that is exchanged is in both cases a short \texttt{taler://}-URI
|
||
which allows the wallet to obtain further details from the payment service
|
||
provider. These further details include the contract/invoice that the payment
|
||
is for. The contract/invoice is stored encrypted at the exchange and thus
|
||
cannot be learned by the exchange.
|
||
|
||
The actual P2P payment works by having the initiator wallet first
|
||
communicate with the Taler exchange to setup the payment. Then the
|
||
Taler URI is communicated to the other wallet, for now usually via
|
||
QR code or NFC transmission; however, users could also copy the URI
|
||
to the clipboard and exchange it via some (secure) messenger. Upon
|
||
receiving the URI, the other wallet then again interacts with the
|
||
exchange to obtain more details and complete the payment.
|
||
|
||
If the recipient of a push payment does not accept the payment
|
||
(say because the message was lost in transmission, or they do not
|
||
like the attached contract terms) the money is automatically refunded
|
||
to the payer after some expiration date is reached.
|
||
|
||
\subsection{Technical details}
|
||
|
||
P2P payments always work by establishing a \textbf{purse} at the
|
||
exchange. A purse has an expiration date, target amount, minimum age,
|
||
associated business contract (or invoice), an actual balance and two
|
||
public-private key pairs representing permissions to operate on the
|
||
purse. For a push payment, the wallet of the sending user creates a
|
||
purse (with contract and expiration time) and immediately ensures that
|
||
the balance of the purse is the target amount. The payer then sends
|
||
the merge-capability key of the purse to the payee. The payee can
|
||
then use the merge-capability key to merge (move) the balance of the
|
||
purse into a KYC%
|
||
\footnote{KYC: Know-Your-Customer, a legally required procedure for customers
|
||
to identify themselves with the bank.}ed
|
||
reserve of the receiving wallet. A KYCed reserve basically is a long-term
|
||
public-private key pair that identifies a wallet and a user at an exchange,
|
||
ensuring income transparency. Once the money is in the reserve, the wallet can
|
||
then use the reserve private key to withdraw fresh coins.
|
||
|
||
When invoicing, the initiator again creates a purse, but this time
|
||
does not put any money into it and keeps the merge capability key
|
||
private. The initiator wallet instead immediately specifies its own
|
||
KYCed reserve as the one the purse should be merged into. The
|
||
initiator then shares a contract-download capability key with the
|
||
payer. The payer downloads the contract (including the purse public
|
||
key) and can then decide to put money into the purse. Once the purse
|
||
balance reaches the target amount, it is then automatically merged
|
||
with the initiator's reserve. The initiator's wallet (long) polls the
|
||
reserve and withdraws the funds as soon as they become available.
|
||
|
||
The protocol and implementation includes a few refinements, like fees
|
||
to be paid to the exchange for managing a purse and age-restrictions
|
||
on the coins used to pay an invoice.
|
||
|
||
\subsection{Future Work}
|
||
|
||
The following features (from tiny to major) have been discussed in
|
||
the team and ought to be implemented as part of future work.
|
||
|
||
\begin{itemize}
|
||
\item \textbf{Wallets:} The wallet UIs currently do not allow the user to actually specify
|
||
any age-restrictions on the payer when sending P2P pull payment requests
|
||
(invoicing). This mostly is about adding one more drop-down widget.
|
||
\item \textbf{Wallets:} The wallet UIs currently do not allow the user to actually specify
|
||
the expiration date for the purse. Instead, the duration is hard-coded
|
||
to a few hours (likely too short). This mostly is about adding one more
|
||
input field.
|
||
\item \textbf{Auditor:} The Taler auditor was extended to support P2P transactions in
|
||
its audits, but the code has not been adequately tested (no
|
||
fault injection).
|
||
\item \textbf{Exchange:} P2P payments currently only work if both wallets are using the
|
||
same exchange. If multiple exchanges operate in the same currency
|
||
domain and the recipient has made their (expensive) KYC process
|
||
at one exchange and the payer has withdrawn from the other, a
|
||
direct payment between the wallets is not possible right now. We
|
||
envision federation protocol using periodic aggregated
|
||
(``wad'') payments between exchanges should be added to support
|
||
P2P payments involing multiple exchanges in the future.
|
||
\item \textbf{Mailbox (NEW):} Currently, sending the payment URI is largely left to the user.
|
||
We would like to implement a ``mailbox'' service for Taler wallets
|
||
that would enable wallets to asynchronously exchange URIs over the
|
||
Internet. Once a wallet knows the mailbox address of another wallet
|
||
(which would include a public key to encrypt messages to), the user
|
||
would no longer be required to manually exchange the QR code.
|
||
\item \textbf{TalDir (NEW):} To lookup the mailbox address of another wallet, we would like
|
||
to implement a directory service that maps existing addresses like
|
||
e-mail addresses, phone numbers or accounts in messengers or social
|
||
media platforms to a mailbox. When establishing the directory service
|
||
entry, the directory service would validate that the user registering
|
||
the wallet has control over the respective address. Naturally, the
|
||
directory service would need to be trusted to return the correct
|
||
mapping.
|
||
\item Both the mailbox and the directory service operators could
|
||
themselves be paid via Taler for their service. That should help
|
||
ensure a high quality of service from those operators. Naturally,
|
||
using the mailbox or the directory service would be optional.
|
||
\item \textbf{Messaging:} In the long term, we would like to see more direct integration
|
||
of Taler payment functionality with messaging applications, especially
|
||
for spam prevention (``The recipient has configured its software to
|
||
demand a payment of 50 cents before displaying a message from an unknown
|
||
sender to the user. If they like your message, they promise they would
|
||
refund this attention fee. Do you want to pay to have your message
|
||
shown? (Y/N)'').
|
||
\end{itemize}
|
||
|
||
|
||
\subsection{Links}
|
||
|
||
\href{https://docs.taler.net/design-documents/013-peer-to-peer-payments.html}{Document
|
||
013} at \url{https://docs.taler.net/design-documents/} presents the design.
|
||
The main implementation parts for P2P are distributed over various code
|
||
locations under \url{https://git.taler.net/wallet-core.git/tree/packages/}
|
||
(wallet) and \url{https://git.taler.net/exchange.git/tree/src/exchange/}
|
||
(exchange):
|
||
\begin{description}
|
||
\item[Payment operations:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/operations/pay-peer.ts}{taler-wallet-core/src/operations/pay-peer.ts}
|
||
\item[Database schema related:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-core/src/db.ts#n2065}{taler-wallet-core/src/db.ts}
|
||
\item[Transaction list type declarations:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-util/src/transactions-types.ts#n251}{taler-util/src/transactions-types.ts}
|
||
\item[WebExtension UI:] \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/cta/InvoiceCreate}{taler-wallet-webextension/src/cta/InvoiceCreate} and \href{https://git.taler.net/wallet-core.git/tree/packages/taler-wallet-webextension/src/cta/InvoicePay}{InvoicePay}
|
||
\item[Exchange] \url{https://git.taler.net/exchange.git/tree/src/exchange/},
|
||
specifically:\\
|
||
\texttt{taler-exchange-httpd\_purses\_*.c}, \texttt{taler-exchange-httpd\_reserves\_purse\_*.c},
|
||
\texttt{taler-exchange-httpd\_contract.*},
|
||
\texttt{taler-exchange-expire.c} (plus related changes in the database, client libraries, history, auditor),
|
||
and the main test case at
|
||
\href{https://git.taler.net/exchange.git/tree/src/testing/test\_exchange\_p2p.c}{testing/test\_exchange\_p2p.c}
|
||
\end{description}
|
||
|
||
|
||
|
||
|
||
\newpage
|
||
\section{Brandt-Vickrey Auctions}
|
||
|
||
\href{https://pub.dss.in.tum.de/brandt-research/ijis2006.pdf}{In 2006, Felix
|
||
Brandt} designed cryptographic Vickrey-style auction protocols that only yield
|
||
the winners’ identities and the selling price. Losing bidders learn no
|
||
information at all, except that they lost. This approach does not rely on
|
||
trusted third parties, e.g., auctioneers or---in our case---the payment service
|
||
provider.
|
||
\href{https://grothoff.org/christian/teich2017ms.pdf}{In 2017, Marcus Teich}
|
||
updated the cryptographic primitives in the Brandt-Vickrey protocols to use
|
||
elliptic curves and provided an implementation in
|
||
\url{https://git.gnunet.org/libbrandt.git/}.
|
||
|
||
Based on that work, we implemented a Proof-of-Concept for \textsc{NGI Pointer}
|
||
of conditional payments in GNU Taler in the form of sealed-bid auctions of type
|
||
Brandt-Vickrey:
|
||
|
||
Bidders put coins in escrow with the exchange in order to participate in a
|
||
particular auction. The coins are locked and can only be unlocked by timeout
|
||
or by winning the auction. After successfully running the Brandt-Vickrey
|
||
auction, the seller has to provide the transcript of all (signed) messages
|
||
received from all bidders. The exchange then replays the transcript and
|
||
determines the winning bidder(s) and price(s) and pays the seller accordingly.
|
||
Non-winning coins and rest amounts can be claimed by the bidders.
|
||
|
||
\subsection{Technical details}
|
||
|
||
We designed and implemented a general framework for conditional payments with
|
||
GNU Taler---so-called \textit{policies}. Our proof-of-concept of sealed-bid
|
||
auction support is implemented as an policy extension to GNU Taler. In
|
||
particular, we implemented the following parts:
|
||
|
||
\begin{description}
|
||
\item[Transcript generation:] \texttt{libbrandt} has been extended to
|
||
generate a transcript of the auction including all
|
||
cryptographically signed messages from all bidders in
|
||
JSON-encoding.
|
||
|
||
\item[Transcript replay:] An external program to replay a transcript
|
||
has been implemented as part of \texttt{libbrandt}. It
|
||
consumes a transcript of an auction in JSON-encoding, generates
|
||
a Brandt-Vickrey-auction and replays all provided messages. On
|
||
success, it returns the winning bidder(s) and price(s)
|
||
according the transcript.
|
||
|
||
\item[Policy extension for auctions:] A policy extension for GNU Taler
|
||
has been implemented that handles deposit requests with set
|
||
policy of type \texttt{\small
|
||
policy\_brandt\_vickrey\_auction}. It locks the coins and
|
||
persists the policy details under a hash-code, that it
|
||
generates by calculating the hash $H(h_a || p_b)$, where $h_a$
|
||
is the hash of the auction meta data and $p_b$ is the public
|
||
key of the bidder. Both parameters are part of the policy
|
||
structure provided during a deposit.
|
||
|
||
\item[POST handler for auction transcripts:] A POST handler for the
|
||
policy extension of that type has been implemented that expects
|
||
a valid transcript of a Brandt-Vickrey-auction. It uses the
|
||
external program to perform a replay of the auction and
|
||
determine the winning bidder(s) and price(s). Based on the
|
||
outcome information, the exchange unlocks the corresponding
|
||
winning coins' value for transfer to the seller---minus an
|
||
auction fee---and the rest value of all coins for refresh.
|
||
|
||
\end{description}
|
||
|
||
|
||
\subsection{Future Works}
|
||
|
||
For a fully functional and maintainable solution, further development is needed
|
||
in the following areas:
|
||
|
||
\begin{description}
|
||
|
||
\item[libbrandt upgrade:] The code base of this library is from 2017 and doesn't
|
||
compile with the latest version of
|
||
\href{https://git.gnunet.org/gnunet.git}{GNUnet}. It also
|
||
uses \href{https://gnupg.org/software/libgcrypt/index.html}%
|
||
{\ttfamily libgcrypt} as cryptographic library, which is quite
|
||
slow compared to its modern alternative
|
||
\href{https://doc.libsodium.org/}{\ttfamily libsodium}, at
|
||
least with respect to the primitives used in libbrandt.
|
||
For future work we plan to refactor libbrandt to use libsodium
|
||
and the current version of GNUnet.
|
||
|
||
\item[Brandt-Vickrey-auction continuation:] The current code is a
|
||
proof-of-concept. The following known problem exist:
|
||
\begin{itemize}
|
||
\item Signature verification of the transcript and its messages
|
||
is missing
|
||
\item Unit- and integration-tests with the exchange are missing
|
||
\item A fully featured auction(er) system, including billboard
|
||
and client software, is missing.
|
||
\end{itemize}
|
||
|
||
We will address at least the first two issues and plan to
|
||
address the lack of an auction system once we find volunteers
|
||
and funding for it.
|
||
|
||
\item[Policy framework continuation:] Based on the current design of policy
|
||
extensions for deposit---aka conditional payments---we plan to add
|
||
following policy extensions to the GNU Taler exchange:
|
||
\begin{itemize}
|
||
\item{\itshape Merchant refunds:} Merchant can grant customers refundable
|
||
payments. Right now, this policy is implicit and optional in
|
||
the usual deposit-flow. Future work on Taler will lift
|
||
this into a policy-extension.
|
||
|
||
\item{\itshape Escrowed payments:} A trustor puts coins into escrow
|
||
with the exchange. It can be claimed by a beneficiary until a
|
||
certain deadline, when the claim is signed by
|
||
both, the beneficiary’s and the trustor’s keys.
|
||
\end{itemize}
|
||
|
||
\end{description}
|
||
|
||
\subsection{Links}
|
||
|
||
\begin{description}
|
||
\item[Changes to libbrandt:]
|
||
\href{https://git.kesim.org/oec/libbrandt/src/branch/transcript/test\_brandt.c}{\ttfamily test\_brandt.c}
|
||
has been extended to generate and print a transcript in JSON
|
||
encoding for each auction. The new file
|
||
\href{https://git.kesim.org/oec/libbrandt/src/branch/transcript/replay.c}{\ttfamily
|
||
replay.c} implements a standalone program to replay an auction.
|
||
\item[Changes to the Exchange:]
|
||
The changes to the exchange can be found at\\
|
||
\url{https://git.kesim.org/taler/exchange/src/branch/auction\_brandt/},\\
|
||
in particular:
|
||
\begin{description}
|
||
\item[\href{https://git.kesim.org/taler/exchange/src/branch/auction\_brandt/src/extensions/policy\_brandt\_vickrey\_auction/policy\_brandt\_vickrey\_auction.c\#L767-L821}{\ttfamily auction\_create\_policy\_details}]
|
||
This implements the {\ttfamily create\_policy\_details}
|
||
function of the policy extension interface.
|
||
|
||
\item[\href{https://git.kesim.org/taler/exchange/src/branch/auction\_brandt/src/extensions/policy\_brandt\_vickrey\_auction/policy\_brandt\_vickrey\_auction.c\#L694-L764}{\ttfamily auction\_policy\_post\_handler}]
|
||
This implements the {\ttfamily policy\_post\_handler} function
|
||
of the policy extension interface.
|
||
\end{description}
|
||
\end{description}
|
||
|
||
|
||
\newpage
|
||
\section{Usability Study}
|
||
|
||
For the \textsc{NGI Pointer} programme, the AP³ project team performed a
|
||
usability study to gather feedback and inform further development of the
|
||
age-restricted and P2P payment functionalities.
|
||
|
||
The BFH ``Digitaltag'' is an annual day-long event where the
|
||
university presents itself to the public. It is held right next to the
|
||
central train station of Biel/Bienne, and is open to the general
|
||
public. It was attended by a mixture of prospective students, normal
|
||
adults, Swiss executives and retirees.
|
||
|
||
We used the opportunity to both present GNU Taler to the public, and
|
||
to conduct usability studies with interested volunteers.
|
||
|
||
\begin{figure}[h!]
|
||
\includegraphics[width=\textwidth]{pics/b.jpg}
|
||
\caption{Our booth, with GNU Taler publications (including on
|
||
age-restrictions), NGI stickers, and a Taler-enabled coffee machine.}
|
||
\end{figure}
|
||
|
||
|
||
\subsection{Preparation}
|
||
|
||
We prepared several notebooks with a browser running a Taler wallet as
|
||
well as several Android phones with the Taler Android wallet. We
|
||
set up the coffee machine and three Taler backends, one for CHF (used
|
||
by the coffee machine), one for KUDOS (used with age-restrictions in
|
||
the browser-based setup) and one for Bitcoin (used for P2P payments).
|
||
We also prepared a rough write-up describing what we would like users
|
||
to do. These intended user stories are included in the appendix. We
|
||
note that during the day, we permitted participants to deviate from
|
||
the script if they desired to do so, sometimes leading them to explore
|
||
other GNU Taler features (and us learning interesting lessons about
|
||
those).
|
||
|
||
For the UX study, we prepared four tables: two tables with the coffee
|
||
machine and information materials, and two tables with additional
|
||
chairs for guests for the actual UX experiment.
|
||
|
||
\begin{figure}[h!]
|
||
\includegraphics[width=\textwidth]{pics/a.jpg}
|
||
\caption{Tables for the UX study with Prof. Benoist.}
|
||
\end{figure}
|
||
|
||
\subsection{Data collection}
|
||
|
||
We did not collect any PII on the participants.\footnote{Except for
|
||
one executive who had come just for our booth from Zug and who gave us
|
||
his business card as he hopes to collaborate with us in the future.}
|
||
Instead, each team member wrote down their observations. We
|
||
afterwards de-duplicated the observations and turned those that could
|
||
lead to improvements into over 20 new issues on the GNU Taler
|
||
bug-tracker (\#7334--\#7354).
|
||
|
||
\subsection{Key conclusions}
|
||
|
||
The day revealed the existence of several previously unknown bugs
|
||
(like refresh not working properly with the new features) as well
|
||
as quite a few surprising difficulties of users (not finding the
|
||
QR code button, not finding the account balance, not understanding
|
||
that the \texttt{shop.demo.taler.net} page is the shop where they should buy
|
||
things). We have made changes to GNU Taler in an attempt to rectify most of
|
||
these issues.
|
||
|
||
|
||
\end{document}
|