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

update legal evaluation et. al.

Browse Source
This commit is contained in:
Özgür Kesim 2022-10-30 13:46:43 +01:00
parent 906a22de47
commit 3b61924585
1 changed files with 82 additions and 54 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

136
m4/ngi-ap3-m4-report.tex
View File

@ -16,6 +16,7 @@
\usepackage{graphicx}
\usepackage{listings}
\usepackage{fontspec}
\usepackage{menukeys}
\usepackage{tikz}
\usetikzlibrary{tikzmark}
\usetikzlibrary{shapes,arrows,arrows.meta}
@ -122,8 +123,8 @@ 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).
The following figure gives an overview of the scheme for age restriction
detached from the payment flow:
Figure~\ref{scheme} gives an overview of the scheme for age restriction
detached from the payment flow.
\begin{figure}[h]
\begin{center}\footnotesize
@ -156,8 +157,13 @@ detached from the payment flow:
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$,
@ -185,9 +191,10 @@ $\Derive$ and $\Compare$ is based on the following main building blocks:
\, (\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$.
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$.
@ -198,7 +205,7 @@ $\Derive$ and $\Compare$ is based on the following main building blocks:
\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)$.
The child can now create an \textit{attestation}
$\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$.
@ -209,14 +216,34 @@ $\Derive$ and $\Compare$ is based on the following main building blocks:
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 schemes for age restriction and the scheme for payment in GNU Taler
(protocols \textsf{withdraw}, \textsf{purchase}, \textsf{deposit} and
\textsf{refresh}) are integrated as sketched in the following figure:
\begin{figure}[h]
\begin{center}\footnotesize
\begin{tikzpicture}[scale=.8]
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$};
@ -243,27 +270,9 @@ The schemes for age restriction and the scheme for payment in GNU Taler
\end{center}
\caption{Sketch of the integration of the schemes for age restriction
and payment in GNU Taler.}
\label{bothschemes}
\end{figure}
\filbreak
The cut-and-choose protocol $\DeriveCompare$ is defined roughly as follows:
\begin{center}
\parbox{0.75\textwidth}{
\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{center}
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
@ -276,10 +285,43 @@ published in the
\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. The commission 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 under the category ``holistic youth
protection concept''. The KJM uses this category only for concepts that are
widely accessible to the public and do not only serve a closed user group
(closed user group means: access to content or goods is granted only after age
verification by presenting an official ID card, driving licenses or the
like---which is endangering privacy, data security, and informational
self-determination).
\subsection{Future Works}
\begin{description}
\item[Complete support for all GNU Taler protocols:] So far, age restriction is
\item[Completion of support for all GNU Taler protocols:] So far, age restriction is
only implemented for the GNU Taler protocols \textsf{withdraw},
\textsf{purchase}, \textsf{deposit} and \textsf{refresh}. We
will extend the support for age restriction in GNU Taler to
@ -303,25 +345,9 @@ published in the
\textit{maximum} age for the age commitment during the
\textsf{withdraw} protocol.
\item[Legal certification of our age restriction scheme:] We are in
correspondence with the
\href{https://www.kjm-online.de/en/}{German Commission for the
Protections of Minors in the Media (KJM)} which evaluates and
recommends concepts for protection of minors. GNU Taler has
been recognized as a potential candidate in the so-called
``cross-channel concepts for the protection of minors''.
We will prepare a white paper about GNU Taler's age restriction
as input for the commission's next meeting on December 7, 2022,
in Berlin. Our goal is to convince the commission of GNU
Taler's age restriction scheme as a legally acceptable form of
age verification and add it to its list of
\href{https://www.kjm-online.de/aufsicht/technischer-jugendmedienschutz/uebergreifende-konzepte}%
{positively evaluated concepts}.
\end{description}
\subsection{Links}
Our scheme for age restriction in GNU Taler has been
@ -441,11 +467,13 @@ 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 KYCed (i.e. know-your-customer ready) 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.
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