Update taler.tex to refresh protocol with new coin derivation

I made usages of the FDH explicit too, but did not realyl explain it.
This commit is contained in:
Jeff Burdges 2016-08-08 14:57:34 +02:00
parent cdcd67a27d
commit eb28eaf320

View File

@ -563,6 +563,9 @@ the refresh protocol from being used to transfer ownership.
\section{Taler's Cryptographic Protocols} \section{Taler's Cryptographic Protocols}
\def\KDF{\textrm{KDF}}
\def\FDH{\textrm{FDH}}
% In this section, we describe the protocols for Taler in detail. % In this section, we describe the protocols for Taler in detail.
For the sake of brevity we omit explicitly saying each time that a For the sake of brevity we omit explicitly saying each time that a
@ -629,24 +632,35 @@ Now the customer carries out the following interaction with the exchange:
\item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$, \item coin key $C := (c_s,C_p)$ with private key $c_s$ and public key $C_p := c_s G$,
\item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk. \item blinding factor $b$, and commits $\langle W, C, b \rangle$ to disk.
\end{itemize} \end{itemize}
\item The customer transfers an amount of money corresponding to at least $K_v$ to the exchange, with $W_p$ in the subject line of the transaction. \item The customer transfers an amount of money corresponding to at least $K_v$
\item The exchange receives the transaction and credits the $W_p$ reserve with the respective amount in its database. to the exchange, with $W_p$ in the subject line of the transaction.
\item The customer sends $S_W(B_b(C_p))$ to the exchange to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with blinding factor $b$. \item The exchange receives the transaction and credits the $W_p$ reserve with
\item The exchange checks if the same withdrawal request was issued before; in this case, it sends $S_{K}(B_b(C_p))$ to the customer.\footnote{$S_K$ the respective amount in its database.
denotes a Chaum-style blind signature with private key $K_s$.} \item The customer sends $S_W(B)$ where $B := B_b(\FDH_K(C_p))$ to the exchange
to request withdrawal of $C$; here, $B_b$ denotes Chaum-style blinding with
blinding factor $b$.
\item The exchange checks if the same withdrawal request was issued before;
in this case, it sends $S_{K}(B)$ to the customer.%
\footnote{$S_K$ denotes a Chaum-style blind signature with private key $K_s$.}
If this is a fresh withdrawal request, the exchange performs the following transaction: If this is a fresh withdrawal request, the exchange performs the following transaction:
\begin{enumerate} \begin{enumerate}
\item checks if the reserve $W_p$ has sufficient funds for a coin of value corresponding to $K$ \item checks if the reserve $W_p$ has sufficient funds
\item stores the withdrawal request and response $\langle S_W(B_b(C_p)), S_K(B_b(C_p)) \rangle$ in its database for future reference, for a coin of value corresponding to $K$
\item stores the withdrawal request and response
$\langle S_W(B), S_K(B) \rangle$ in its database
for future reference,
\item deducts the amount corresponding to $K$ from the reserve, \item deducts the amount corresponding to $K$ from the reserve,
\end{enumerate} \end{enumerate}
and then sends $S_{K}(B_b(C_p))$ to the customer. and then sends $S_K(B)$ to the customer.
If the guards for the transaction fail, the exchange sends a descriptive error back to the customer, If the guards for the transaction fail, the exchange sends a descriptive
with proof that it operated correctly. error back to the customer, with proof that it operated correctly.
Assuming the signature was valid, this would involve showing the transaction history for the reserve. Assuming the signature was valid, this would involve showing the transaction
history for the reserve.
% FIXME: Is it really the whole history? % FIXME: Is it really the whole history?
\item The customer computes and verifies the unblinded signature $S_K(C_p) = U_b(S_K(B_b(C_p)))$. \item The customer computes and verifies the unblinded signature
The customer saves the coin $\langle S_K(C_p), c_s \rangle$ to local wallet on disk. $S_K(\FDH_K{C_p}) = U_b(S_K(B))$.
Finally the customer saves the coin $\langle S_K(\FDH_K(C_p)), c_s \rangle$
to their local wallet on disk.
\end{enumerate} \end{enumerate}
@ -662,7 +676,7 @@ must be authenticated with X.509c.
We now describe the protocol between the customer, merchant, and exchange We now describe the protocol between the customer, merchant, and exchange
for a transaction in which the customer spends a coin $C := (c_s, C_p)$ for a transaction in which the customer spends a coin $C := (c_s, C_p)$
with signature $\widetilde{C} := S_K(C_p)$ with signature $\widetilde{C} := S_K(\FDH_K(C_p))$
where $K$ is the exchange's demonination key. where $K$ is the exchange's demonination key.
% FIXME: Again, these steps occur at different points in time, maybe % FIXME: Again, these steps occur at different points in time, maybe
@ -760,59 +774,73 @@ generator of the elliptic curve.
\begin{enumerate} \begin{enumerate}
\item For each $i = 1,\ldots,\kappa$, the customer randomly generates \item For each $i = 1,\ldots,\kappa$, the customer randomly generates
a transfer private key $t^{(i)}_s$ and computes
\begin{itemize} \begin{itemize}
\item transfer key $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$ \item the transfer public key $T^{(i)}_p := t^{(i)}_s G$ and
where $T^{(i)}_p := t^{(i)}_s G$, \item the new coin secret seed $K_i := H(c'_s T_p^{(i)})$.
\item coin key pair $C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$
where $C^{(i)}_p := c^{(i)}_s G$, and
\item blinding factors $b^{(i)}$.
\end{itemize} \end{itemize}
The customer then computes We have computed $K_i$ as a Diffie-Hellman shared secret between
$E^{(i)} := E_{K_i}\left(c_s^{(i)}, b^{(i)}\right)$ the transfer key pair $T^{(i)} := \left(t^{(i)}_s,T^{(i)}_p\right)$
where $K_i := H(c'_s T_p^{(i)})$, and and old coin key pair $C' := \left(c_s', C_p'\right)$,
commits $\langle C', \vec{T}, \vec{C}, \vec{b} \rangle$ to disk. so that $K_i = H(t^{(i)}_s C'_p)$ too.
Now the customer applies key derivtion functions to $K_i$ to generate
\begin{itemize}
\item a blinding factor $b^{(i)} = \FDH_K(\KDF_{\textrm{blinding}}(K_i))$.
\item $c_s^{(i)} = \KDF_{\textrm{Ed25519}}(K_i)$
\end{itemize}
Now the customer can compute her new coin key pair
$C^{(i)} := \left(c_s^{(i)}, C_p^{(i)}\right)$
where $C^{(i)}_p := c^{(i)}_s G$.
Our computation of $K_i$ is effectively a Diffie-Hellman operation The customer saves to disk $\langle C', \vec{t}\rangle$ where
between the private key $c'_s$ of the original coin with $\vec{t} = \langle t^{(1)}_s, \ldots, t^{(\kappa)}_s \rangle$.
the public transfer key $T_p^{(i)}$. We observe that $t^{(i)}_s$ suffices to regenerate $C^{(i)}$ and $b^{(i)}$
\item The customer computes $B^{(i)} := B_{b^{(i)}}(C^{(i)}_p)$ for $i \in \{1,\ldots,\kappa\}$ and sends a commitment using the same key derivtion functions.
$S_{C'}(\vec{E}, \vec{B}, \vec{T_p})$ to the exchange.
% \item
The customer computes $B^{(i)} := B_{b^{(i)}}(\FDH_K(C^{(i)}_p))$
for $i \in \{1,\ldots,\kappa\}$ and sends a commitment
$S_{C'}(\vec{B}, \vec{T_p})$ to the exchange.
\item The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and \item The exchange generates a random $\gamma$ with $1 \le \gamma \le \kappa$ and
marks $C'_p$ as spent by committing marks $C'_p$ as spent by committing
$\langle C', \gamma, S_{C'}(\vec{E}, \vec{B}, \vec{T_p}) \rangle$ to disk. $\langle C', \gamma, S_{C'}(\vec{B}, \vec{T_p}) \rangle$ to disk.
Auditing processes should assure that $\gamma$ is unpredictable until Auditing processes should assure that $\gamma$ is unpredictable until
this time to prevent the exchange from assisting tax evasion. this time to prevent the exchange from assisting tax evasion.
\item The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where \item The exchange sends $S_{K'}(C'_p, \gamma)$ to the customer where
$K'$ is the exchange's message signing key. $K'$ is the exchange's message signing key.
\item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk. \item The customer commits $\langle C', S_K(C'_p, \gamma) \rangle$ to disk.
\item The customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
% \item
Also, the customer computes $\mathfrak{R} := \left(t_s^{(i)}\right)_{i \ne \gamma}$
and sends $S_{C'}(\mathfrak{R})$ to the exchange. and sends $S_{C'}(\mathfrak{R})$ to the exchange.
\item \label{step:refresh-ccheck} The exchange checks whether $\mathfrak{R}$ is consistent with the commitments; \item \label{step:refresh-ccheck}
specifically, it computes for $i \not= \gamma$: The exchange checks whether $\mathfrak{R}$ is consistent with
the commitments; specifically, it computes for $i \not= \gamma$:
\vspace{-2ex} \vspace{-2ex}
\begin{minipage}{5cm} \begin{minipage}{5cm}
\begin{align*} \begin{align*}
\overline{K}_i :&= H(t_s^{(i)} C_p'), \\ \overline{K}_i :&= H(t_s^{(i)} C_p') \\
(\overline{c}_s^{(i)}, \overline{b_i}) :&= D_{\overline{K}_i}(E^{(i)}), \\ \overline{c}_s^{(i)} :&= \KDF_{\textrm{Ed25519}}(\overline{K}_i) \\
\overline{C^{(i)}_p} :&= \overline{c}_s^{(i)} G, \overline{C^{(i)}_p} :&= \overline{c}_s^{(i)} G
\end{align*} \end{align*}
\end{minipage} \end{minipage}
\begin{minipage}{5cm} \begin{minipage}{5cm}
\begin{align*} \begin{align*}
\overline{T_p^{(i)}} :&= t_s^{(i)} G, \\ \\ \overline{T_p^{(i)}} :&= t_s^{(i)} G \\
\overline{B^{(i)}} :&= B_{\overline{b_i}}(\overline{C_p^{(i)}}), \overline{b}^{(i)} :&= \FDH_K(\KDF_{\textrm{blinding}}(\overline{K}_i)) \\
\overline{B^{(i)}} :&= B_{\overline{b_i}}(\overline{C_p^{(i)}})
\end{align*} \end{align*}
\end{minipage} \end{minipage}
and checks if $\overline{B^{(i)}} = B^{(i)}$ and checks if $\overline{B^{(i)}} = B^{(i)}$
and $\overline{T^{(i)}_p} = T^{(i)}_p$. and $\overline{T^{(i)}_p} = T^{(i)}_p$.
\item \label{step:refresh-done}
\item \label{step:refresh-done} If the commitments were consistent, If the commitments were consistent, the exchange sends the
the exchange sends the blind signature $\widetilde{C} := blind signature $\widetilde{C} := S_{K}(B^{(\gamma)})$ to the customer.
S_{K}(B^{(\gamma)})$ to the customer. Otherwise, the exchange responds Otherwise, the exchange responds with an error indicating
with an error indicating the location of the failure. the location of the failure.
\end{enumerate} \end{enumerate}
%\subsection{N-to-M Refreshing} %\subsection{N-to-M Refreshing}
@ -824,12 +852,11 @@ generator of the elliptic curve.
% FIXME: What is \mathtt{link} ? % FIXME: What is \mathtt{link} ?
For a coin that was successfully refreshed, the exchange responds to a For a coin that was successfully refreshed, the exchange responds to a
request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p$, $E^{(\gamma)}, request $S_{C'}(\mathtt{link})$ with $(T^{(\gamma)}_p, \widetilde{C})$.
\widetilde{C})$.
% %
This allows the owner of the melted coin to also obtain the private This allows the owner of the melted coin to derive the private key of
key of the new coin, even if the refreshing protocol was illicitly the new coin, even if the refreshing protocol was illicitly executed
executed with the help of another party who generated $\vec{c_s}$ and only with the help of another party who generated $\vec{c_s}$ and only
provided $\vec{C_p}$ and other required information to the old owner. provided $\vec{C_p}$ and other required information to the old owner.
As a result, linking ensures that access to the new coins issued in As a result, linking ensures that access to the new coins issued in
the refresh protocol is always {\em shared} with the owner of the the refresh protocol is always {\em shared} with the owner of the
@ -840,8 +867,8 @@ The linking request is not expected to be used at all during ordinary
operation of Taler. If the refresh protocol is used by Alice to operation of Taler. If the refresh protocol is used by Alice to
obtain change as designed, she already knows all of the information obtain change as designed, she already knows all of the information
and thus has little reason to request it via the linking protocol. and thus has little reason to request it via the linking protocol.
The fundamental reason why the exchange must provide the link protocol is The fundamental reason why the exchange must provide the link protocol
simply to provide a threat: if Bob were to use the refresh protocol is simply to provide a threat: if Bob were to use the refresh protocol
for a transaction of funds from Alice to him, Alice may use a link for a transaction of funds from Alice to him, Alice may use a link
request to gain shared access to Bob's coins. Thus, this threat request to gain shared access to Bob's coins. Thus, this threat
prevents Alice and Bob from abusing the refresh protocol to evade prevents Alice and Bob from abusing the refresh protocol to evade