From 3b6192458596aa9442884a03059c455aa6fcb365 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=C3=96zg=C3=BCr=20Kesim?= Date: Sun, 30 Oct 2022 13:46:43 +0100 Subject: [PATCH] update legal evaluation et. al. --- m4/ngi-ap3-m4-report.tex | 136 +++++++++++++++++++++++---------------- 1 file changed, 82 insertions(+), 54 deletions(-) diff --git a/m4/ngi-ap3-m4-report.tex b/m4/ngi-ap3-m4-report.tex index eeb3d48..d22f193 100644 --- a/m4/ngi-ap3-m4-report.tex +++ b/m4/ngi-ap3-m4-report.tex @@ -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