diff options
author | Christian Grothoff <christian@grothoff.org> | 2021-05-18 17:00:53 +0200 |
---|---|---|
committer | Christian Grothoff <christian@grothoff.org> | 2021-05-18 17:00:53 +0200 |
commit | 75804f8bceb7249f7b6b1c7248f7f90e721d1c57 (patch) | |
tree | f30590667356fc557478b404ff45111b862f8fb4 | |
parent | 4f75848465f6dd94d1dd9dc31b307bf9f98e2ce9 (diff) | |
download | marketing-75804f8bceb7249f7b6b1c7248f7f90e721d1c57.tar.gz marketing-75804f8bceb7249f7b6b1c7248f7f90e721d1c57.tar.bz2 marketing-75804f8bceb7249f7b6b1c7248f7f90e721d1c57.zip |
NYC update
-rw-r--r-- | presentations/comprehensive/nyc.tex | 201 |
1 files changed, 89 insertions, 112 deletions
diff --git a/presentations/comprehensive/nyc.tex b/presentations/comprehensive/nyc.tex index 3f671f0..6a36176 100644 --- a/presentations/comprehensive/nyc.tex +++ b/presentations/comprehensive/nyc.tex @@ -612,12 +612,6 @@ But of course we use modern instantiations. \end{minipage} \end{frame} -\begin{frame}{Withdrawing coins on the Web} - \begin{center} - \includegraphics[height=0.9\textheight]{figs/taler-withdraw.pdf} - \end{center} -\end{frame} - \begin{frame}{Customer: Build shopping cart} \begin{center} @@ -654,18 +648,6 @@ But of course we use modern instantiations. \end{frame} -\begin{frame}{Merchant Integration: Contract} - % \begin{figure*}[t!] - {\tiny - \lstset{language=JavaScript} - \lstinputlisting{figs/taler-contract.json} -% \caption{Minimal Taler contract over a digital article with a value of \EUR{0.10}. The merchant will pay transaction fees up to \EUR{0.01}. The hash over the wire transfer information was truncated to make it fit to the page.} -% \label{listing:json-contract} - % \end{figure*} - } -\end{frame} - - \begin{frame}{Merchant: Propose contract (EdDSA)} \begin{minipage}{6cm} \begin{enumerate} @@ -762,13 +744,6 @@ But of course we use modern instantiations. \end{frame} -\begin{frame}{Payment processing with Taler} - \begin{center} - \includegraphics[height=0.9\textheight]{figs/taler-pay.pdf} - \end{center} -\end{frame} - - \begin{frame}{Giving change} It would be inefficient to pay EUR 100 with 1 cent coins! \begin{itemize} @@ -1173,93 +1148,6 @@ But of course we use modern instantiations. -\begin{frame}{Warranting deposit safety} - Exchange has {\em another} online signing key $W = wG$: - \begin{center} - Sends $EdDSA_w(M,H(D),FDH(C))$ to the merchant. - \end{center} - This signature means that $M$ was the {\em first} to deposit - $C$ and that the exchange thus must pay $M$. - \vfill - \begin{center} - Without this, an evil exchange could renege on the deposit - confirmation and claim double-spending if a coin were - deposited twice, and then not pay either merchant! - \end{center} -\end{frame} - - -\begin{frame}{Online keys} -\begin{itemize} -\item The exchange needs $d$ and $w$ to be available for online signing. -\item The corresponding public keys $W$ and $(e,n)$ are certified using - Taler's public key infrastructure (which uses offline-only keys). -\end{itemize} -\begin{center} -\includegraphics[width=0.5\textwidth]{taler-diagram-signatures.png} -\end{center} -\vfill -\begin{center} -{\bf What happens if those private keys are compromised?} -\end{center} -\vfill -\end{frame} - - -\begin{frame}{Denomination key $(e,n)$ compromise} -\begin{itemize} -\item An attacker who learns $d$ can sign an arbitrary number of illicit coins - into existence and deposit them. -\item Auditor and exchange can detect this once the total number of deposits - (illicit and legitimate) exceeds the number of legitimate coins the - exchange created. -\item At this point, $(e,n)$ is {\em revoked}. Users of {\em unspent} - legitimate coins reveal $b$ from their withdrawal operation and - obtain a {\em refund}. -\item The financial loss of the exchange is {\em bounded} by the number of - legitimate coins signed with $d$. -\item[$\Rightarrow$] Taler frequently rotates denomination signing keys and - deletes $d$ after the signing period of the respective key expires. -\end{itemize} -\begin{center} -\includegraphics[width=0.5\textwidth]{taler-diagram-denom-expiration.png} -\end{center} -\end{frame} - - -\begin{frame}{Online signing key $W$ compromise} -\begin{itemize} -\item An attacker who learns $w$ can sign deposit confirmations. -\item Attacker sets up two (or more) merchants and customer(s) which double-spend - legitimate coins at both merchants. -\item The merchants only deposit each coin once at the exchange and get paid once. -\item The attacker then uses $w$ to fake deposit confirmations for the double-spent - transactions. -\item The attacker uses the faked deposit confirmations to complain to the auditor - that the exchange did not honor the (faked) deposit confirmations. -\end{itemize} -The auditor can then detect the double-spending, but cannot tell who is to blame, -and (likely) would presume an evil exchange, forcing it to pay both merchants. -\end{frame} - - -\begin{frame}{Detecting online signing key $W$ compromise} -\begin{itemize} -\item Merchants are required to {\em probabilistically} report - signed deposit confirmations to the auditor. -\item Auditor can thus detect exchanges not reporting signed - deposit confirmations. -\item[$\Rightarrow$] Exchange can rekey if illicit key use is detected, - then only has to honor deposit confirmations it already provided - to the auditor {\em and} those without proof of double-spending - {\em and} those merchants reported to the auditor. -\item[$\Rightarrow$] Merchants that do not participate in reporting - to the auditor risk their deposit permissions being voided in - cases of an exchange's private key being compromised. -\end{itemize} -\end{frame} - - \section{Competitor analysis} @@ -1749,6 +1637,95 @@ General notions: +\begin{frame}{Warranting deposit safety} + Exchange has {\em another} online signing key $W = wG$: + \begin{center} + Sends $EdDSA_w(M,H(D),FDH(C))$ to the merchant. + \end{center} + This signature means that $M$ was the {\em first} to deposit + $C$ and that the exchange thus must pay $M$. + \vfill + \begin{center} + Without this, an evil exchange could renege on the deposit + confirmation and claim double-spending if a coin were + deposited twice, and then not pay either merchant! + \end{center} +\end{frame} + + +\begin{frame}{Online keys} +\begin{itemize} +\item The exchange needs $d$ and $w$ to be available for online signing. +\item The corresponding public keys $W$ and $(e,n)$ are certified using + Taler's public key infrastructure (which uses offline-only keys). +\end{itemize} +\begin{center} +\includegraphics[width=0.5\textwidth]{taler-diagram-signatures.png} +\end{center} +\vfill +\begin{center} +{\bf What happens if those private keys are compromised?} +\end{center} +\vfill +\end{frame} + + +\begin{frame}{Denomination key $(e,n)$ compromise} +\begin{itemize} +\item An attacker who learns $d$ can sign an arbitrary number of illicit coins + into existence and deposit them. +\item Auditor and exchange can detect this once the total number of deposits + (illicit and legitimate) exceeds the number of legitimate coins the + exchange created. +\item At this point, $(e,n)$ is {\em revoked}. Users of {\em unspent} + legitimate coins reveal $b$ from their withdrawal operation and + obtain a {\em refund}. +\item The financial loss of the exchange is {\em bounded} by the number of + legitimate coins signed with $d$. +\item[$\Rightarrow$] Taler frequently rotates denomination signing keys and + deletes $d$ after the signing period of the respective key expires. +\end{itemize} +\begin{center} +\includegraphics[width=0.5\textwidth]{taler-diagram-denom-expiration.png} +\end{center} +\end{frame} + + +\begin{frame}{Online signing key $W$ compromise} +\begin{itemize} +\item An attacker who learns $w$ can sign deposit confirmations. +\item Attacker sets up two (or more) merchants and customer(s) which double-spend + legitimate coins at both merchants. +\item The merchants only deposit each coin once at the exchange and get paid once. +\item The attacker then uses $w$ to fake deposit confirmations for the double-spent + transactions. +\item The attacker uses the faked deposit confirmations to complain to the auditor + that the exchange did not honor the (faked) deposit confirmations. +\end{itemize} +The auditor can then detect the double-spending, but cannot tell who is to blame, +and (likely) would presume an evil exchange, forcing it to pay both merchants. +\end{frame} + + +\begin{frame}{Detecting online signing key $W$ compromise} +\begin{itemize} +\item Merchants are required to {\em probabilistically} report + signed deposit confirmations to the auditor. +\item Auditor can thus detect exchanges not reporting signed + deposit confirmations. +\item[$\Rightarrow$] Exchange can rekey if illicit key use is detected, + then only has to honor deposit confirmations it already provided + to the auditor {\em and} those without proof of double-spending + {\em and} those merchants reported to the auditor. +\item[$\Rightarrow$] Merchants that do not participate in reporting + to the auditor risk their deposit permissions being voided in + cases of an exchange's private key being compromised. +\end{itemize} +\end{frame} + + + + \end{document} |