\begin{frame} \begin{columns} \begin{column}{0.5\textwidth} \mktitle{Outline} \begin{enumerate} \item Setting and problem \item Design overview \item How to get involved \end{enumerate} \end{column} \begin{column}{0.5\textwidth} \centering \includegraphics[width=\columnwidth]{img/rgdd} \burl{https://creativecommons.org/licenses/by-sa/4.0/} \end{column} \end{columns} \end{frame} \begin{frame} % % 1. Introduce the system. Think first two paragraphs in design.md % \mktitle{Our starting point} \begin{columns} \begin{column}{0.5\textwidth} \begin{itemize} \item Data publisher \item End-user \item Assumptions \begin{itemize} \item Public key can be located \item Signed data can be located \item End-user can install extra tooling \end{itemize} \end{itemize} \end{column} \begin{column}{0.5\textwidth} \centering \input{img/before} \end{column} \end{columns} \vfill \pause \alert{The attacker can compromise the data publisher}\\ \pause \alert{The goal is to detect unwanted key-usage} \end{frame} \begin{frame} % % 1. Our design is about transparency logs. So, I need to explain briefly % what a transparency log is. % 2. Append-only Merkle tree. You can think of the data as being stored in % the leaves. Each leaf is hashed. Parents concatenate their children % hashes to produces their own hash values. Repeat until single root hash. % 3. The root hash is usually called a tree head. % 4. Tree head interesting because it fixes the structure and the content of % the tree. Add/remove/modify -> new tree head. % 5. If the log signs the tree head, you can hold it accountable for its % structure and content. % 6. This is important because the attacker can control the log. % 7. So we cannot trust that the log is append-only. We will need to verify % that. To this end we have consistency proofs. The intuition is that you % can force the log to reveal a number of cryptographic hashes. These % hashes will prove that the tree head you see today is consistent with the % tree head you saw yesterday. % 8. You can also prove that something is in the log efficiently. This is % called an inclusion proof. The intuition is that you reveal a number of % hashes. If you can use them to reconstruct the root of a globally % consistent tree head you can be sure that some data is in the log. % 8. Global consistency (as opposed to just consistency) is what prevents % the log from creating forks. I will return to this later on because it is % an important part of our design. % (9. Not having global consistency would be like having a blockchain % without a consensus mechanism.) % \mktitle{A quick step back---Transparency log crash course} \input{img/mt} \vfill \begin{columns} \begin{column}{0.33\textwidth} \begin{itemize} \item Tree head \end{itemize} \end{column} \begin{column}{0.33\textwidth} \begin{itemize} \item Consistency proof \end{itemize} \end{column} \begin{column}{0.33\textwidth} \begin{itemize} \item Inclusion proof \end{itemize} \end{column} \end{columns} \vfill \pause \alert{The attacker can control the log} \end{frame} \begin{frame} \mktitle{Preparing a logging request} \begin{columns} \begin{column}{0.5\textwidth} \begin{itemize} \item Select a shard hint and checksum \item Sign using your private key \end{itemize} \end{column} \begin{column}{0.5\textwidth} \lstinputlisting[style=CStyle]{img/tree-leaf.trunnel} \end{column} \end{columns} \end{frame} \begin{frame} \mktitle{Submitting a logging request} \begin{columns} \begin{column}{0.2\textwidth} \underline{Key-value pairs:} \begin{itemize} \item Shard hint \item Checksum \item Signature \item Public key \item Domain hint \end{itemize} \end{column} \begin{column}{0.8\textwidth} \centering \input{img/log-request} \end{column} \end{columns} \end{frame} \begin{frame} \mktitle{Distributing proofs of public logging} \begin{columns} \begin{column}{0.5\textwidth} \begin{itemize} \item End-user will not talk to the log \item Proofs of logging \begin{itemize} \item Inclusion proof \item Tree head \end{itemize} \item Witness cosigning \end{itemize} \end{column} \begin{column}{0.5\textwidth} \centering \input{img/after} \end{column} \end{columns} \pause \alert{The attacker can control a threshold of witnesses} \end{frame} \begin{frame} \mktitle{Summary and additional details} \begin{columns} \begin{column}{0.5\textwidth} \begin{itemize} \item Signed checksums \item Sharding \item Preserved data flows \item Anti-spam \item Global consistency \item Few simple parsers \item No cryptographic agility \end{itemize} \end{column} \begin{column}{0.5\textwidth} \includegraphics[width=\columnwidth]{img/clean} \end{column} \end{columns} \end{frame} \begin{frame} \vfill \begin{columns} \begin{column}{0.7\textwidth} \mktitle{Get involved} \begin{itemize} \item Feedback on our v0 design\footnotemark and API\footnotemark? \item Is this a service that you would use? Why (not)? \item Want to run an experimental log or witness? \item Implementation and tooling is still early-days \item Reach out via slack\footnotemark, IRC\footnotemark, GitHub, or DM \end{itemize} \end{column} \begin{column}{0.3\textwidth} \centering \includegraphics[width=\columnwidth]{img/thanks} \end{column} \end{columns} \footnotetext[1]{\burl{https://github.com/system-transparency/stfe/blob/design/doc/design.md}} \footnotetext[2]{\burl{https://github.com/system-transparency/stfe/blob/design/doc/api.md}} \footnotetext[3]{\burl{https://communityinviter.com/apps/system-transparency/join}} \footnotetext[4]{\tiny{\texttt{irc/oftc \#siglog}}} \end{frame}