Repo re-org

1 files changed, 0 insertions, 880 deletions

diff --git a/directions/research_directions.tex b/directions/research_directions.tex
deleted file mode 100644
index 602d09b..0000000
--- a/directions/research_directions.tex
+++ /dev/null
@@ -1,880 +0,0 @@
-\documentclass[12pt,a4paper,notitlepage]{article}
-\usepackage[utf8]{inputenc}
-\usepackage[a4paper,textwidth=17cm, top=2cm, bottom=3.5cm]{geometry}
-\usepackage[T1]{fontenc}
-\usepackage[
-    backend=biber,
-    style=numeric,
-    natbib=true,
-    url=true, 
-    doi=true,
-    eprint=false
-    ]{biblatex}
-\addbibresource{directions.bib}
-\usepackage{amssymb,amsmath}
-\usepackage{listings}
-\usepackage{eurosym}
-\usepackage{wasysym}
-\usepackage{amsthm}
-\usepackage{tabularx}
-\usepackage{multirow}
-\usepackage{multicol}
-\usepackage{tikz}
-
-\usetikzlibrary{arrows}
-\usetikzlibrary{backgrounds}
-\usetikzlibrary{calc}
-\usetikzlibrary{decorations.markings}
-\usetikzlibrary{decorations.pathreplacing}
-\usetikzlibrary{fit}
-\usetikzlibrary{patterns}  
-\usetikzlibrary{positioning}
-\usetikzlibrary{shapes}
-
-\usepackage{hyperref}
-\usepackage{tabularx}
-\usepackage{commath}
-\usepackage{graphicx,color}
-\usepackage{subcaption}
-\usepackage{float}
-\usepackage{footmisc}
-\usepackage{array}
-\usepackage[underline=false]{pgf-umlsd}
-\usetikzlibrary{calc}
-%\usepackage[pdftex]{graphicx,color}
-%\usepackage{epstopdf}
-
-\newcommand{\foonote}[1]{\footnote{#1}}
-\newcommand{\degree}{\ensuremath{^\circ}}
-\newcolumntype{P}[1]{>{\centering\arraybackslash}p{#1}}
-
-\author{Sebastian Götte {\texttt<secureusb@jaseg.net>} @Mori lab, Waseda University}
-\title{Securing the USB interface}
-\date{December 12 2018}
-\begin{document}
-\maketitle
-
-\section{Introduction}
-\subsection{Problem definition}
-A computer's USB interface is hard to secure. Though overall security is quite good today, the USB interface has not
-received enough attention. In particular HIDs are a problem, as they are naturally very highly privileged.
-Off-the-shelf USB HID attack tools exist. In particular from a security point of view extremely bad ideas such as
-WebUSB\cite{misc01} are set to increase this already large attack surface even further.
-
-\subsection{Contributions}
-This work includes three key contributions. First, it demonstrates a practical implementation of a complete,
-backwards-compatible secure USB system using QubesOS and a single new piece of security hardware.  Second, it shows a
-novel interactive user-friendly cryptographic handshaking scheme based on out-of-band communication. Third, it shows and
-proposes some techniques for the design of general secure protocols that are not limited to USB alone.
-
-\section{The state of the art in mitigation}
-Several ways to secure the USB interface have been proposed that can be broadly categorized as follows.
-\begin{itemize}
-    \item USB firewalls are software or hardware that protects the host from requests deemed invalid similar to a network firewall\cite{tian01,angel01,kang01,bates01,loe01}.
-    \item USB device authentication uses some sort of user feedback or public key infrastructure to authenticate the device when it connects\cite{usb01,griscioli01,wang01,he01}.
-    \item USB bus encryption encrypts the raw USB payloads to ward off eavesdroppers\cite{neugschwandtner01,weinstein01}.
-    \item For wireless protocols, every conceivable pairing model has been tried. However, not many have been applied to
-        USB\cite{arun01,uzun01,kobsa01,saxena01}.
-    \item Compartmentalized systems such as QubesOS separate vulnerable components with large attack surface such as the USB device drivers into VMs to not inhibit exploitation but mitigate its consequences.
-\end{itemize}
-
-\begin{table}
-    \setlength{\extrarowheight}{5pt}
-    \begin{tabular}{l|P{10mm}|P{15mm}|P{15mm}|P{15mm}|P{17mm}|P{25mm}|}
-                                &\multicolumn{3}{c|}{\bfseries Attacks}                                             & \multicolumn{2}{c|}{\bfseries Eavesdropping} & \multirow{2}{25mm}{\centering\bfseries Backwards\newline compatible} \\\cline{2-6}
-                                & \bfseries HID     &\bfseries Host\newline exploit &\bfseries Device\newline exploit&\bfseries Bus-level &\bfseries Physical layer    & \\\hline
-        Firewalls               & $\bigcirc$        & $\triangle$                   & $\times$                      & $\triangle$   & $\times$          & $\bigcirc$ \\
-        Device authentication   & $\bigcirc$        & $\times$                      & $\times$                      & $\triangle$   & $\times$          & $\times$ \\
-        Bus encryption          & $\triangle$       & $\times$                      & $\times$                      & $\bigcirc$    & $\bigcirc$        & $\times$ \\
-        Plain QubesOS setup\footnotemark 
-                                & $\triangle$       & $\triangle$                   & $\triangle$                   & $\triangle$   & $\times$          & $\bigcirc$ \\
-        Our work                & $\bigcirc$        & $\bigcirc$                    & $\bigcirc$                    & $\bigcirc$    & $\bigcirc$        & $\bigcirc$
-    \end{tabular}
-    \caption{Comparison of approaches to USB security}
-    \label{approach_comparison}
-\end{table}
-\footnotetext{Requires separate USB host controller for HIDs}
-
-We compare these approaches w.r.t. several attacks in \ref{approach_comparison}. Overall we found that QubesOS is the
-only advance towards securing this interface that is both \emph{practical} and \emph{effective}. Other approaches have
-not been successful so far likely due to market inertia and backwards-incompatibility.
-QubesOS approaches the problem by running a separate VM with the USB host controllers mapped through via IOMMU. This VM
-runs a linux kernel with a small set of white-listed USB device drivers (HID and mass storage device) and a USB-over-IP
-backend. A set of Qubes services pass through any HID input arriving inside this VM into dom0, and coordinate exporting
-USB mass storage devices as Xen block devices. Any other USB devices can be passed-through to other VMs through
-USB-over-IP-over-QubesRPC, a Xen vChan-based inter-VM communication system.
-QubesOS is still lacking in that it's compartmentalization becomes essentially useless when it is used with a USB HID
-keyboard that does not have its own dedicated PCIe USB host controller, as any normal desktop and most recent laptop
-computers. The issue here is that USB HID is neither authenticated nor encrypted, and the untrusted USB VM sits in the
-middle of this data stream, which thus allows it trivial privilege escalation via keystroke injection.
-
-\subsection{Usage scenarios}
-
-Today USB's level security is still adequate for most everyday users. In general, attacks against USB either require
-special malicious hardware or require re-flashing of existing peripherals with custom malicious firmware. Today's
-low-level cybercrime targeting everyday users is still focused on much easier tasks such as stealing passwords through
-phishing, installing cryptolocker malware by means of malicious email attachments and extracting sensitive user data
-with malicious browser addons. Fortunately, we have not yet entered an age where average computer users need to worry
-about the type of attack this work defends against. Still, it can be expected that with the general increase of overall
-computer security, eventually attackers will have to graduate to more advanced means--and since at this time the
-landscape of effective defenses against USB attacks is very sparse, your author considers it important to explore the
-avenues to effective defence ealier rather than later in order to be prepared for evolving attacks.
-
-Despite the banality of everyday cybersecurity described above, there already are some people and organizations who face
-advanced attacks including USB attacks. Due to their exceedingly simple execution, USB HID attacks are a very attractive
-way to perform targeted attacks. For this reason, specialized USB attack hardware is already available commercially at
-low cost. For users facing targeted attacks like this, SecureHID might already provide practical benefits.
-The users most at risk of targeted attacks are those either working with highly sensitive data or working with highly
-privileged access. The former group would include people such as journalists working with their sources and politicians
-working with confidential information. The latter group would include law enforcement officials, often being endowed
-with wide-ranging electronic access to databases and other confidential information. Further, system administrators and
-computer programmers are often provided highly privileged access to critical systems for software deployment using
-systems such as Ansible or uploading software packages into software repositories such as PyPI.
-
-In all of these scenarios there are many users with very poweful adversaries. In case of a software developer or systems
-administrator that would be competing companies or foreign intelligence agencies trying to gain access to internal
-networks to steal confidential information. In case of a journalist that would be whoever they are writing about and
-here the most interesting articles might come with the most powerful enemies. Finally, a security researcher would by
-nature of their work, out of academic interest specifically be looking for the most dangerous targets they could find.
-
-Some users might be able to reduce their attack surface to USB attacks by reducing their use of untrusted USB devices,
-but in many everyday scenarios such as those described above this is not an option. A security researcher needs to
-connect to untrusted devices in order to analyze them, and using a second, isolated machine for this is very
-inconvenient. A journalist or politician will frequently have to read USB flash drives with documents for their work,
-and again simply solving the problem by air-gapping is an effective but impractical mitigation. In all of these cases,
-SecureHID would be an effective mitigation.
-
-\section{Approach}
-\subsection{System overview}
-The goal of SecureHID is to enable the first reasonably secure system using both HID and arbitrary untrusted devices on
-the same USB host controller, based on QubesOS. SecureHID consists of a USB HID encryption box to be put between
-keyboard and computer and a piece of software run inside QubesOS. After initial pairing with the host software, the
-encryption box will encrypt and sign any USB HID input arriving from the keyboard and forward the encrypted data to the
-host. The host software running outside the untrusted USB VM will receive the encrypted and signed data from the
-untrusted USB VM, verify and decrypt it, and inject the received HID input events into Qubes's input event handling
-system.
-
-A schematic diagram of a system employing SecureHID is shown in figure \ref{diagram_with}. Two major points that can be
-seen here are that first, SecureHID requires no specialized hardware on either end and transparently plugs into the
-existing USB stack. Second, a SecureHID-protected setup has two well-defined security boundaries, one inside the
-SecureHID device between host and device side, and one in the host operating system between USB driver VM and
-hypervisor.  These security boundaries allow a clean separation of a SecureHID setup into untrusted and trusted domains
-and greatly simpliefies reasoning about overall system security.  Communication across these security boundaries is
-limited to the simple SecureHID protocol. We describe the design of the SecureHID protocol in section \ref{prot_desc}
-and elaborate its security properties in section \ref{prot_ver}. The security of the protocol's core components has been
-formally verified in the past and the protocol has been kept simple enough to allow exhaustive verification and testing.
-
-\begin{figure}[p]
-    \includegraphics[scale=0.8]{system_diagram_with_secureusb.eps}
-    \caption{Diagram of a SecureHID-protected system}
-    \label{diagram_with}
-\end{figure}
-
-\subsection{System security properties}
-This system is sufficient to secure any USB setup, especially unmodified desktop PCs or laptops where a USB host
-controller is shared between both HIDs and other devices. Attack surface is reduced such that a \emph{full compromise}
-of the system becomes unlikely, since plain HID is no longer supported. The remaining attack surface consists only of a
-\emph{compromise of the USB VM}. This attack surface is small enough that other sensitive devices such as USB audio
-devices can safely be connected. A compromise of the USB driver VM no longer gives full system access, but at best
-allows listening in on the microphone. Since a compromised USB VM in general does not have network access, such an
-attack will be mostly harmless in most scenarios. Additionally, the most likely attacking devices would be custom
-hardware or a compromised smartphone. Custom hardware can easily be outfitted with a microphone, essentially turning it
-into a bug irrespective of USB functionality, and smartphones already have microphones by definition.
-
-A practical mitigation for potential information leakage through microphones, webcams and other sensitive devices would
-be to simply unplug them when not used. Microphones could also be connected to a PCIe-based sound card (such as the
-integrated sound card of most laptops) and webcams could potentially be isolated to a separate USB host controller.
-
-\subsection{USB physical-level and bus-level attacks}
-Since sensitive HIDs are isolated from other USB devices effectively on a separate bus, bus-level attacks such as
-\textcite{neugschwandtner01} are entirely prevented. The much scarier physical attacks on USB such as \textcite{su01}
-can be prevented thanks to the clear security boundary inside the SecureHID device. Since there is only four wires
-needed between the trusted and untrusted sides (Ground, VCC, serial RX and serial TX) and the serial link is running at
-a comparatively low speed (115.2kBd easily suffice), analog filtering is a viable measure against sidechannels. On the
-ground and VCC rails extensive filtering using series inductors and large capacitors can be used to decouple both sides.
-Additionally, both sides' microcontrollers can optionally be fed from separate voltage regulators powered off the USB 5V
-rail to reduce side-channels. The serial link can be filtered to limit its analog bandwidth to above serial speeds
-(50kHz) but much below the trusted microcontroller's system clock (72MHz). Finally, on the untrusted microcontroller
-choosing UART pins that are not multiplexed to its internal ADC elminates the risk of direct measurements by a
-compromised microcontroller firmware and leaves only indirect measurements of power supplies or coupling into other
-pins' signals. This means that with a few very inexpensive hardware countermeasures (an additional voltage regulator and
-a handful of capacitors, inductors and resistors for filtering) any analog side-channels between trusted and untrusted
-side can be ruled out.
-
-\section{Cryptographic design}
-
-\subsection{Protocol description}
-\label{prot_desc}
-The basic protocol consists of two stages: \textsc{pairing} and \textsc{data}. When the device powers up, it enters
-\textsc{pairing} state. When the host enumerates a new device, it enters \textsc{pairing} state. If any fatal
-communication errors occur, both host and device re-enter \textsc{pairing} state. To make the implementation robust
-against host software crashing, devices being unplugged etc. without opening it up to attacks, the host can request the
-device to re-enter \textsc{pairing} state a limited number of times after powerup.
-
-\textsc{pairing} state consists of a number of substates as set by \textcite{perrin01}. The device runs noise's
-\textsc{XX} scheme, i.e. both host and device each contribute both one ephemeral key $e$ and one static key $s$ to the
-handshake, and the public halves of the static keys are transmitted during handshake encrypted by the emphemeral keys.
-
-The cryptographic primitives instantiated in the prototype are X25519 for the ECDH primitive, BLAKE2s as a hash and
-ChaCha20-Poly1305 as AEAD for the data phase. ECDH instead of traditional DH was chosen for its small key size and fast
-computation. Since no variant of RSA is used, key generation is fast. An ad-hoc prototype device-side random number
-generator has been implemented based on BLAKE2s and the STM32's internal hardware RNG.
-
-\begin{figure}[h]
-    \centering
-    \begin{sequencediagram}
-        \newinst{kbd}{Keyboard}
-        \newinst[3]{dev}{SecureHID}
-        \newinst[5]{host}{Host}
-
-        \mess{host}{}{dev}
-        \path (mess from) -- (mess to) node[midway, above] {\emph{COBS sync (null byte)}};
-        \mess{host}{}{dev}
-        \draw[->,>=angle 60] (mess from) -- (mess to) node[midway, above] {\textsc{Initiate Handshake}};
-
-        \begin{sdblock}{Noise XX handshake}{}
-            \mess{host}{}{dev}
-            \path (mess from) -- (mess to) node[midway, above] {$\textsc{Handshake}, e$};
-            \mess{dev}{}{host}
-            \path (mess from) -- (mess to) node[midway, above] {$\textsc{Handshake}, e,ee,s,es$};
-            \mess{host}{}{dev}
-            \path (mess from) -- (mess to) node[midway, above] {$\textsc{Handshake}, s,se$};
-        \end{sdblock}
-
-        \begin{sdblock}{Pairing}{Triggered by user interaction after unsuccessful handshake}
-            \mess{dev}{}{host}
-            \draw[->,>=angle 60] (mess from) -- (mess to) node[midway, above] {\textsc{Pairing Start}};
-            \stepcounter{seqlevel}
-
-            \mess{kbd}{keystroke}{dev}
-            \addtocounter{seqlevel}{-1}
-            \mess{dev}{}{host}
-            \path (mess from) -- (mess to) node[midway, above] {$\textsc{Pairing Input},E(\text{keystroke})$};
-            \stepcounter{seqlevel}
-            \mess{kbd}{}{dev}
-            \addtocounter{seqlevel}{-1}
-            \path (mess from) -- (mess to) node[midway, above] {keystroke};
-            \path (mess from) -- (mess to) node[midway, above, yshift=5mm] {$\vdots$};
-            \mess{dev}{}{host}
-            \path (mess from) -- (mess to) node[midway, above] {$\textsc{Pairing Input},E(\text{keystroke})$};
-            \path (mess from) -- (mess to) node[midway, above, yshift=5mm] {$\vdots$};
-            \stepcounter{seqlevel}
-
-            \mess{kbd}{}{dev}
-            \addtocounter{seqlevel}{-1}
-            \path (mess from) -- (mess to) node[midway, above] {\emph{enter}};
-            \mess{dev}{}{host}
-            \draw[->,>=angle 60] (mess from) -- (mess to) node[midway, above] {\textsc{Pairing Success}};
-        \end{sdblock}
-
-        \begin{sdblock}{Input passthrough}{Started after successful handshake or pairing}
-            \mess{kbd}{keystroke}{dev}
-            \path (mess from) -- (mess to) node[midway, below, yshift=-2mm] {$\vdots$};
-
-            \addtocounter{seqlevel}{-1}
-            \mess{dev}{}{host}
-            \path (mess from) -- (mess to) node[midway, above] {$\textsc{Data},E(\text{keystroke})$};
-            \path (mess from) -- (mess to) node[midway, below, yshift=-2mm] {$\vdots$};
-            \stepcounter{seqlevel}
-        \end{sdblock}
-    \end{sequencediagram}
-    \caption{A successful prototype protocol pairing}
-    \label{protocol_diagram}
-\end{figure}
-
-A successful pairing looks like this:
-\begin{enumerate}
-\item \textbf{Handshake.} \textsc{device} is connected to \textsc{host}
-\item \textsc{host} initiates pairing by sending \textsc{initiate handshake} to device
-\item \textsc{device} and \textsc{host} follow noise state machine for the \textsc{XX} handshake. See figure
-	\ref{crypto_diagram} for a complete flowchart of cryptographic operations during this handshake. The handshake and
-	subsequent Noise protocol communication are specified in \textcite{perrin01} and their security properties are
-	formally verified in \textcite{kobeissi01}. Section \ref{sec_prop} analyzes the implications of these security
-	properties for this research.
-\item After the handshake completes, both \textsc{device} and \textsc{host} have received each other's static public key
-    $rs$ and established a shared secret connection key. At this point, the possibility of an MITM attacker having
-	actively intercepted the handshake remains. At this point \textsc{device} and \textsc{host} will both notice they do
-	not yet know each other's static keys. \textsc{host} will respond to this by showing the pairing GUI dialog.
-	\textsc{deivce} will sound an alarm to indicate an untrusted connection to the user.
-\item \textbf{Channel binding.} Both \textsc{device} and \textsc{host} calculate the \emph{handshake hash} as per noise
-	spec\cite{perrin01}. This hash uniquely identifies this session and depends on both local and remote ephemeral and
-	static keys $le, re, ls, rs$.  Both parties encode a 64-bit part of this hash into a sequence of english words by
-	dictionary lookup. This sequence of words is called the \emph{fingerprint} of the connection.
-\item \textsc{host} prompts the user to enter the \emph{fingerprint} into a keyboard connected to \textsc{device}. The
-	user presses the physical pairing button on \textsc{device} to stop the alarm and start pairing. This step prevents
-	an attacker from being able to cause the device to send unencrypted input without user interaction by starting
-	pairing.
-\item As the user enters the \emph{fingerprint}, \textsc{device} relays any input over the yet-unauthenticated encrypted
-    noise channel to \textsc{host}. \textsc{host} displays the received user input in plain text in a regular input
-    field in the pairing GUI. This display is only for user convenience and not relevant to the cryptographic handshake.
-    A consequence of this is that a MITM could observe the \emph{fingerprint}\footnote{
-        A MITM could also modify the fingerprint information sent from \textsc{device} to \textsc{host}. This would be
-        very obvious to the user, since the fingerprint appearing on the \textsc{host} screen would differ from what she
-        types.
-    }. We show in section \ref{prot_ver} that this does not reduce the protocol's security.
-\item When the user has completed entering the fingerprint, the device checks the calculated fingerprint against the
-    entered data. If both match, the host is signalled \textsc{success} and \textsc{data} phase is entered. If they do
-    not match, the host is signalled \textsc{failure}\footnote{
-        Note that this means a MITM could intercept the \textsc{failure} message and forge a \textsc{success} message.
-        This means both are just for user convenience \emph{absent} an attacker. If an attacker is present, she will be
-        caught in the next pairing step.
-    } and \textsc{pairing} state is re-entered unless the maximum number of tries since powerup has been exceeded.
-    Failure is indicated to the user by \textsc{device} through a very annoying beep accompanied by angrily flashing
-    LEDs.
-\item \textbf{Data phase.} \textsc{host} asks the user for confirmation of pairing \emph{in case the device did not
-	sound an alarm} by pressing a button on the GUI. When the user does this, the host enters \textsc{data} state and
-	starts input passthrough.
-\end{enumerate}
-
-Roughly speaking, this protocol is secure given that the only way to MITM a (EC)DH key exchange is to perform two (EC)DH
-key exchanges with both parties, then relay messages. Since both parties have different static keys, the resulting two
-(EC)DH sessions will have different handshake hashes under the noise framework. The channel binding step reliably
-detects this condition through an out-of-band transmission of the \textsc{host} handshake hash to \textsc{device}.
-The only specialty here is that this OOB transmission is relayed back from \textsc{device} to \textsc{host} allowing the
-MITM to intercept it. This is only done for user convenience absent a MITM and the result is discarded by \textsc{host}.
-Since the handshake hash does as a hash does not leak any sensitive information about the keys used during the
-handshake, it being exposed does not impact protocol security.
-
-\subsection{Protocol verifictation}
-\label{prot_ver}
-\subsubsection{Noise security properties}
-\label{sec_prop}
-According to \textcite{perrin01} and proven by \textcite{kobeissi01} Noise's XX pattern provides strong forward-secrecy,
-sender and receiver authentication and key compromise impersonation resistance. Strong forward secrecy means an attacker
-can only decrypt messages by compromising the receivers private key and performing an active impersonation.  Strong
-forward secrecy rules out both physical and protocol-level eavesdropping attacks by malicious USB devices and implies
-that an attacker can never decrypt past protocol sessions. An implication of the static key checks done on both sides of
-the connection is that an attacker would need to compromise both host and device in order to remain undetected for e.g.
-keylogging.  Compromising only one party the worst that can be done is impersonating the SecureHID device to perform a
-classical HID attack. In this case, the attacker cannot read user input and the user would notice this by SecureHID
-indicating a not connected status and thus the keyboard not working.
-% FIXME possibly detect this by having session counter etc.?
-
-To verify that these security properties extend to the overall SecureHID protocol it suffices to show the following
-three properties.
-\begin{enumerate}
-\item The SecureHID implementation of Noise XX adheres to the Noise specification, i.e. the handshake is performed
-	correctly. \label{adh0}
-\item Both sides' static keys are verified. \label{adh1}
-\item All sensitive data is encapsulated in Noise messages after the handshake has ended, and none is sent before.
-	\label{adh2}
-\end{enumerate}
-
-\ref{adh0} has been validated by manual code review and cross-validation of our implementation against other Noise
-implementations. % FIXME write more, do more here
-\ref{adh1} has been validated by manual code review. %FIXME do simulation here
-Since all sensitive data in our application is handled on the device in a single place (the USB HID request handling
-routine), \ref{adh2} is easily validated by code review. USB HID reports are only transmitted either encrypted after the
-handshake has been completed or in plain during pairing. Since the host will only inject reports into the input
-subsystem that have been properly authenticated and encrypted (and not the unauthenticated reports sent during pairing),
-the protocol is secure in this regard. Since pairing keyboard input is only passed through after the host's pairing
-request has been acknowledged by the user with SecureUSB's physical pairing button the user would certainly notice an
-attack trying to exfiltrate data this way. Were pairing input passed through automatically without explicit user
-acknowledgement, an attacker could start pairing mode just as the user starts typing in a password prompt such as the
-one of \texttt{sudo} or a password field and might not notice the attack until they have typed out their entire password
-to the attacker.
-
-\subsubsection{Handshake hash non-secrecy}
-
-\begin{figure}[p]
-	\centering
-	\tikzset{%
-		h/.style = {->, very thick},
-		ck/.style = {->, very thick},
-		key/.style = {->},
-		ki/.style = {key, color=red},
-		kr/.style = {key, color=red},
-		ke/.style = {dashed},
-		ks/.style = {solid},
-		phaselbl/.style = {font=\bfseries, anchor=west}
-	}
-    \begin{tikzpicture}[scale=0.8]
-        \node(protoname) at (0, 0){\texttt{"Noise\_XX\_25519\_ChaChaPoly\_BLAKE2s"}};
-        \node[draw,thick,below=1em of protoname] (inithash) {$H$};
-		\node[below=2em of inithash, xshift= 6.5em] (ck){$ck$};
-		\node[below=2em of inithash, xshift=-6.5em] (h){$h$};
-		\coordinate (labelbase) at (-5,0);
-
-        \draw[->] (protoname) -- (inithash);
-		\draw[->] (inithash) -- ++(0,-2em) coordinate(im0) -| (ck);
-		\draw[->] (im0) -| (h);
-		
-		\node[right=7em of ck] (ei){$\mathbf{e_i}$};
-		\node[right=8.5em of ck] (er){$\mathbf{e_r}$};
-		\node[right=10em of ck] (si){$\mathbf{s_i}$};
-		\node[right=11.5em of ck] (sr){$\mathbf{s_r}$};
-
-		\node[draw,thick,below=3em of h] (mix0){MixHash};
-		\node[right=1em of mix0] (str0){\texttt{""}};
-		\node[left] at (str0 -| labelbase) (lbl0){\parbox{10em}{\raggedleft No preamble,\\use empty string}};
-
-		\draw[h] (h) -- (mix0);
-		\draw[->] (str0) -- (mix0);
-		
-%---
-		\node[draw,thick,below=2em of mix0] (mix1){MixHash};
-		\node[left] at (mix1 -| labelbase) (tok0){$e\rightarrow $};
-		\draw[h] (mix0) -- (mix1);
-		\draw[ki,ke] (ei) |- (mix1);
-
-		\node[draw,thick,below=2em of mix1] (mix2){MixHash};
-		\node[right=1em of mix2] (str2){\texttt{""}};
-		\node[left] at (str2 -| labelbase) (lbl2){\parbox{10em}{\raggedleft EncryptAndHash\\No payload and\\$k$ unset}};
-		\draw[->] (str2) -- (mix2);
-		\draw[h] (mix1) -- (mix2);
-
-		\coordinate (a) at ($ (mix0) !0.5! (mix1) $);
-		\coordinate (b0) at (a -| lbl0.south west);
-		\draw[dashed] (b0) -- ($ (b0 -| sr) + (1em,0) $);
-%---
-		\node[draw,thick,below=4em of mix2] (mix3){MixHash};
-		\node[left] at (mix3 -| labelbase) (tok3){$e\leftarrow $};
-		\draw[h] (mix2) -- (mix3);
-		\draw[kr,ke] (er) |- (mix3);
-
-		\coordinate (sync4) at (mix3 -| ck);
-		\node[draw,thick,below=2em of sync4] (kmix1){MixKey};
-		\node[left] at (kmix1 -| labelbase) (tok4){$ee\leftarrow $};
-		\node[draw,thick,right=1em of kmix1] (dh0){ECDH};
-		\draw[ck] (ck) -- (kmix1);
-		\draw[ki,ke] (ei) |- ($ (dh0.east) + (0,0.2em) $);
-		\draw[kr,ke] (er) |- ($ (dh0.east) - (0,0.2em) $);
-		\draw[->] (dh0) -- (kmix1);
-
-		\coordinate (sync5) at (kmix1 -| h);
-		\node[draw,thick,below=2em of sync5] (mix5){MixHash};
-		\node[draw,thick,right=2em of mix5] (enc5){$E$};
-		\node[left] at (mix5 -| labelbase) (lbl5){$s\leftarrow $};
-		\draw[h] (mix3) -- (mix5);
-		\draw[->] (enc5) -- (mix5);
-		\draw[->] ($ (kmix1.west) - (2em,0) $) -| (enc5);
-		\draw[kr,ks] (sr) |- (enc5);
-
-		\coordinate (sync6) at (mix5 -| ck);
-		\node[draw,thick,below=2em of sync6] (kmix6){MixKey};
-		\node[left] at (kmix6 -| labelbase) (tok6){$es\leftarrow $};
-		\node[draw,thick,right=1em of kmix6] (dh6){ECDH};
-		\draw[ck] (kmix1) -- (kmix6);
-		\draw[ki,ke] (ei) |- ($ (dh6.east) + (0,0.2em) $);
-		\draw[kr,ks] (sr) |- ($ (dh6.east) - (0,0.2em) $);
-		\draw[->] (dh6) -- (kmix6);
-
-		\coordinate (sync7) at (kmix6 -| h);
-		\node[draw,thick,below=2em of sync7] (mix7){MixHash};
-		\node[draw,thick,right=2em of mix7] (enc7){$E$};
-		\node[right=1em of enc7] (str7){\texttt{""}};
-		\node[left] at (mix7 -| labelbase) (lbl7){\parbox{10em}{\raggedleft DecryptAndHash\\ No payload}};
-		\draw[h] (mix5) -- (mix7);
-		\draw[->] (enc7) -- (mix7);
-		\draw[->] (kmix1.west) -- ++(-2em,0) |- ($ (enc5.south) !0.25! (enc7.north) $) -- (enc7);
-		\draw[->] (str7) -- (enc7);
-
-		\coordinate (a) at ($ (mix2) !0.5! (mix3) $);
-		\coordinate (b1) at (a -| lbl2.south west);
-		\draw[dashed] (b1) -- ($ (b1 -| sr) + (1em,0) $);
-% ---
-		\node[draw,thick,below=4em of mix7] (mix8){MixHash};
-		\node[draw,thick,right=2em of mix8] (enc8){$E$};
-		\node[left] at (mix8 -| labelbase) (lbl8){$s\rightarrow $};
-		\draw[h] (mix7) -- (mix8);
-		\draw[->] (enc8) -- (mix8);
-		\draw[->] (kmix6.west) -- ++(-2em,0) |- ($ (enc7.south) !0.25! (enc8.north) $) -- (enc8);
-		\draw[ki,ks] (si) |- (enc8);
-
-		\coordinate (sync9) at (mix8 -| ck);
-		\node[draw,thick,below=2em of sync9] (kmix9){MixKey};
-		\node[left] at (kmix9 -| labelbase) (tok9){$se\rightarrow $};
-		\node[draw,thick,right=1em of kmix9] (dh9){ECDH};
-		\draw[ck] (kmix6) -- (kmix9);
-		\draw[ki,ks] (si) |- ($ (dh9.east) - (0,0.2em) $);
-		\draw[kr,ke] (er) |- ($ (dh9.east) + (0,0.2em) $);
-		\draw[->] (dh9) -- (kmix9);
-
-		\coordinate (sync10) at (kmix9 -| h);
-		\node[draw,thick,below=2em of sync10] (mix10){MixHash};
-		\node[draw,thick,right=2em of mix10] (enc10){$E$};
-		\node[right=1em of enc10] (str10){\texttt{""}};
-		\node[left] at (mix10 -| labelbase) (lbl10){\parbox{10em}{\raggedleft EncryptAndHash\\ No payload}};
-		\draw[h] (mix8) -- (mix10);
-		\draw[->] (enc10) -- (mix10);
-		\draw[->] (kmix9.west) -| (enc10);
-		\draw[->] (str10) -- (enc10);
-
-		\coordinate (a) at ($ (mix7) !0.5! (mix8) $);
-		\coordinate (b2) at (a -| lbl2.south west);
-		\draw[dashed] (b2) -- ($ (b2 -| sr) + (1em,0) $);
-% ---
-		\coordinate (sync11) at (mix10 -| ck);
-		\node[draw,thick,below=5em of sync11,xshift=-1em] (finkdf){HKDF};
-		\node[below=2em of finkdf,xshift=-1em] (k1){$\mathbf{k_1}$};
-		\node[below=2em of finkdf,xshift= 1em] (k2){$\mathbf{k_2}$};
-		\node[left=1em of finkdf,yshift=2em] (str11){\texttt{""}};
-		\draw[ck] (kmix9) -- (finkdf.north -| kmix9);
-		\draw[ck] (k1 |- finkdf.south) -- (k1);
-		\draw[ck] (k2 |- finkdf.south) -- (k2);
-		\draw[->] (str11) -| ($ (finkdf.north) - (1em,0) $);
-
-		\coordinate (sync11a) at (finkdf.south -| h);
-		\node[below=2em of sync11a] (hout){$\mathbf{h}$};
-		\draw[h] (mix10) -- (hout);
-
-		\node[left] at (finkdf -| labelbase) (lbl13){\parbox{10em}{\raggedleft Split}};
-
-		\coordinate (a) at ($ (mix10) !0.5! (finkdf) $);
-		\coordinate (b3) at (a -| lbl10.south west);
-		\draw[dashed] (b3) -- ($ (b3 -| sr) + (1em,0) $);
-%---
-		\node[phaselbl, rectangle] at ($ (b0) !0.5! (b0 |- protoname) $) (setup){setup};
-		\node[phaselbl, circle] at ($ (b0) !0.5! (b1) $) (ph0){0};
-		\node[phaselbl, circle] at ($ (b1) !0.5! (b2) $) (ph1){1};
-		\node[phaselbl, circle] at ($ (b2) !0.5! (b3) $) (ph2){2};
-		\node[phaselbl, rectangle] at ($ (b3) !0.5! (b3 |- hout) $) (fin){fin};
-
-    \end{tikzpicture}
-    \caption{Cryptographic flowchart of Noise XX handshake.}
-    \label{crypto_diagram}
-\end{figure}
-
-To analyze the impact of disclosing the handshake hash to an adversary we must consider its definition. The noise
-protocol specification does not % FIXME double-check this 
-guarantee that the handshake hash can be disclosed to an adversary without compromising security. Figure
-\ref{crypto_diagram} is a flowchart of the derivation of both initiator-transmit and initiator-receive symmetric
-encryption keys $k_{1,2}$ and the handshake hash $h$ during the Noise handshake. Following are the definitions of
-MixHash and MixKey according to the Noise protocol specification.
-
-\begin{align}
-	\text{MixHash}(h,\text{input}) &= h' = H(h || \text{input})\\
-	\text{MixKey}(ck, \text{input}) &= (ck', k_\text{temp}) = \text{HKDF}(ck, \text{input}, 2)\\
-\end{align}
-
-Noise's hash-based key derivation function (HKDF) is defined using the HMAC defined in RFC2104\cite{rfc2104}. The hash
-function $H$ employed here depends on the cipher spec used. SecureHID uses BLAKE2s.
-\begin{equation}
-	\text{HMAC}(K, \text{input}) = H\left(\left(K \oplus opad\right)
-		|| H\left(\left(K \oplus ipad\right) || \text{input} \right)\right)
-\end{equation}
-
-The HKDF is defined for two and three outputs as follows.
-\begin{equation}
-	\text{HKDF}(ck, \text{input}, n_\text{out}) =
-		\left\{\begin{array}{ll}
-			(q_0, q_1) &: n_\text{out} = 2\\
-			(q_0, q_1, q_2) &: n_\text{out} = 3\\
-		\end{array}\right.
-\end{equation}
-
-The outputs $q_i$ are derived from chained HMAC invocations. First, a temporary key $t'$ is derived from the chaining key $ck$
-and the input data using the $HMAC$, then depending on $n_\text{out}$ the HMAC is chained twice or thrice to produce
-$q_{\{0,1,2\}}$.
-\begin{gather}
-	t' = \text{HMAC}(ck, \text{input})\\
-	\underbrace{\text{HMAC} \Bigl(t',
-	\underbrace{\text{HMAC} \bigl(t',
-	\underbrace{\text{HMAC} (t',
-		   1_{16})}_{q_0}
-		|| 2_{16}\bigr)}_{q_1}
-		|| 3_{16}\Bigr)}_{q_2}
-\end{gather}
-
-Relevant to this protocol implementation's security are the following two properties, both of which can be derived from
-figure \ref{crypto_diagram}:
-\begin{enumerate}
-\item Initiator and responder ephemeral and static keys are all mixed into the handshake hash at least once.\label{fp1}
-\item Knowledge of the handshake hash does not yield any information on the symmetric AEAD keys $k_1$ and $k_2$.\label{fp2}
-\end{enumerate}
-
-\ref{fp1} is evident since $e_i$ and $e_r$ are mixed in directly and $s_i$ and $s_r$ are mixed in after encryption with
-temporary encryption keys derived from $ck$ at the $s\rightarrow$ and $s\leftarrow$ steps during the handshake.
-We can see \ref{fp2} applies by following the derivation of $h$ backwards. If an attacker learned anything about $k1$ or
-$k2$ during an attack by (also) observing $h$ that they did not learn before, we could construct an oracle allowing both
-reversal of $H$ in the final invocation of $MixHash$ and breaking $E$ using this attacker. The attacker would have to
-reverse $H$ at some point since $h = H(\hdots)$ in the final invocation of MixHash. The attacker would have to recover
-the key of $E$ in at least one invocation since $s_i$ and $s_r$ are only mixed into $h$ after either being encrypted
-using $E$ or being used after ECDH to generate a key for $E$. Since the result of ECDH on $e_i$ and $e_r$ is mixed into
-$h$ in the $ee\leftarrow$ and following DecryptAndHash steps, $h$ is blinded to an attacker so that they cannot even
-determine a given $k_1$ and $k_2$ match a given $h$ without compromising ECDH security.
-This means that given the underlying primitives are secure, we do not leak any information on $k1$ or $k2$ by disclosing
-$h$.
-
-% FIXME find and consistently apply a nice name for this handshake method
-\subsection{Alternative uses for interactive public channel binding}
-\label{altuse}
-
-The channel binding method described above can be used in any scenario where a secure channel between two systems must
-be established where one party has a display of some sort and the other party has an input device of some sort. 
-
-\paragraph{Relation to screen-to-photodiode interfaces}
-There have been many systems using a flashing graphic on a screen to transmit data to a receiver containing a photodiode
-held against the screen. Such systems have been used to distribute software over broadcast television but have also been
-used for cryptographic purposes. One widely-deployed example is the ``Flickertan'' system used for wire transfer
-authorization in Germany where a smartcard reader with five photodiodes is held against a flickering image on the bank
-website's wire transfer form\cite{schiermeier01,schiermeier02,braun01}. Systems such as this one do not benefit from the
-interactive channel binding process described in this paper since they do not require any direct user interaction. They
-could however be used as an alternative means for channel binding in any system also supporting interactive pairing as
-described above. The handshake fingerprint would simply be encoded into the flicker signal and transmitted to the other
-endpoint in that way.  Similarly, QR-codes or other barcodes could be used to a device containing a camera. The primary
-advantage of photodiode-based systems is that they incur lower implementation complexity and don't require a potentially
-expensive camera.
-
-\paragraph{Adaption for SSH identity distribution}
-Our interactive channel binding method using a passphrase could be used for key establishment in an SSH setup.
-SSH includes a powerful built-in public-key authentication system, but does not include key management functionality.
-To grant and revoke public key-based access to a host or account, SSH expects the user to manually manage a textual
-\texttt{authorized\_keys} file containing all public keys allowed to login to a particular host or account. Mutual
-authentification is supported by default, using a trust on first use system storing host key fingerprints in a
-\texttt{known\_hosts} file. SSH's identity management system is well-tested and can be considered secure for almost any
-purpose. It is however very simplistic and shifts the burden of access management and identity synchronization to the
-user. Except in very simple use cases, the user will have to provide their own identity management layer on top of the
-primitives provided by SSH. Common implementations of this include offloading \texttt{authorized\_keys} functionality to
-LDAP or automatically generating \texttt{authorized\_keys} files from a configuration management system. The secure
-implementation of any such system incurs a large organizational overhead. SSH keys are too long to be practically
-read-out aloud which in case of small organizations often leads ot insecure practices such as sharing of SSH public keys
-through chat, email or wiki pages for initial access during say, onboarding of a new employee. Though such out-of-band
-key distribution schemes may well be secure often the OOB channel's security is not adequately considered in advance.
-
-The interactive channel binding method described in this paper could be used to interactively transfer an SSH key's
-public to another host by simply establishing a secure channel from source to target machine in the fashion outlined
-above, then copying the key through it. Compared to current common practice this approach would allow two users to
-transfer a key by simply reading out aloud the channel binding fingerprint. This reduces the problem of a digital
-out-of-band channel trusted for direct transfer of manipulation-sensitive key material to the problem of two users being
-sure whether they're actually talking to each other instead of an impostor.
-
-A scenario using the SecureHID hardware to improve SSH security would be to terminate the SSH connection inside the
-SecureHID hardware and this way prevent a compromised host from compromising the SSH remote. This approach has the
-primary drawback that it would incur a large implementation overhead providing new attack surface. Additionally this
-approach would only work when the user is solely interacting with the remote system through keyboard input and would
-break workflows that require copying files to the remote host, or running commands in an automated fashion like a
-configuration management system such as ansible would do.
-
-\section{Hardware implementation}
-\subsection{Hardware overview}
-To demonstrate the practicality of this approach and to evaluate its usability in an everyday scenario, a hardware
-prototype has been built. Based on an initial prototype consisting of a microcontroller development board and a bundle
-of wires a custom PCB fitting an off-the-shelf case has been produced that allows future % FIXME
-usability testing in practical settings.
-
-The hardware implementation consists of two ARM microcontrollers, one for the untrusted host side and one for the
-trusted device side. Both are linked using a simple UART interface. Both microcontrollers have been chosen by their USB
-functionality. For the integrated USB host controller, we had to chose a rather powerful microcontroller on the trusted
-device side even though a much less powerful one would have sufficed even though we are doing serious cryptography on
-this microcontroller. AES encryption is done on every data packet and must compelete in time for the overall system to
-meet its latency requirement, % FIXME go into details on input latency vs. usability somewhere else
-but is fast enough by a large margin. % FIXME benchmarks
-Similarly, the hash and ECDH operations during the cryptographic handshake are fast enough by a large margin. %FIXME benchmark
-Additionally, those operations are only invoked infrequently any time the device is disconnected or the host suspends.
-
-\subsection{Hardware security measures}
-% separate power supplies, possible future filtering of power/gnd and comms link signals
-
-\subsection{Usability considerations}
-
-\paragraph{Implementation robustness}
-In many systems such as common TLS-based systems, overall system security heavily depends on implementation details such
-as certificate checking and user interface details such as the precise structure of security warning messages and how
-they can be overridden. The complexity of these components in practice often leads to insecure systems, such as a system
-using TLS checking a certificate's internal validity but omitting checks on the certificate's chain of trust. A nice
-property of the key estabilishment system outlined in this paper is that it is both very simple, reducing surface for
-errors and it tightly couples the critical channel binding step during key establishment to the overall system's user
-interface. In a system using either keyboard or mouse-based interactive channel binding, an implementation that does not
-perform the channel binding step correctly would simply not work. If the host does not display the correct fingerprint
-the user cannot enter it and the device will not complete the binding step. If the device does not relay fingerprint
-data correctly during pairing the host application would clearly indicate to the user things are amiss with the input
-not matching the fingerprint.  Since the channel fingerprint is computed in a cryptographically well-defined way based
-on entropy contributed by both partners during pairing a implementer would not even be able to accidentially degrade
-fingerprint security.
-
-The critical point from an UI perspective in this pairing scheme is that the host application must display correct
-instructions to the user for them to complete pairing. In particular the host application must put emphasis on the user
-actually checking whether the device raised an alarm before confirming pairing after fingerprint input. Even if it
-didn't the user would notice the device not functioning, but an attacker might have gained unauthorized access in the
-meantime. Likewise, the device needs a clearly understandable method of indicating pairing failure to the user. In
-practice a loud buzzer and a few bright LEDs would likely suffice for this.
-
-\paragraph{Adaption to mice} Instead of a keyboard, a mouse can be used for pairing without compromising protocol
-security. In a basic scheme, the host would encode the fingerprint bit string into a permutation
-$\sigma(i) : \{n\in\mathbb N, n\le m\} \rightarrow \{n\in\mathbb N, n\le m\}$ 
-for an integer security parameter $m>0$
-and then display the sequence $\sigma(i)$ in a grid of buttons similar to a minesweeper field with an emualted mouse
-cursor driven by pairing input on top. The user would then click the buttons on the grid in numeric order. The device
-would do the same mouse emulation invisible to the user and would be able to observe the permutation this way. The
-fingerprint can finally be checked by decoding the permutation into a bit string and comparing. The security level for
-this method in bits is $\eta = \log_2(m!)$ or better than 80bit for $m=25$ in case of a 5x5 grid.  See figure
-\ref{mouse_mockup} for a mockup of what such a system might look like. 
-
-\begin{figure}[h]
-    \centering
-    \includegraphics[width=7cm]{mouse_mockup.png}
-    \caption{A mockup of what mouse-based interactive pairing might look like}
-    \label{mouse_mockup}
-\end{figure}
-
-\paragraph{Gamification}
-A second, slightly more complex approach to a mouse-based interface would be to adapt the popular game Minesweeper to
-compare fingerprints in our interactive setting. In Minesweeper, the user is presented with a fixed-size, say $20\times
-20$ $x-y$ grid of fields. Under each of $n$ of the $x\times y$ fields a mine is hidden. The user is tasked with
-uncovering all fields \emph{without} mines while \emph{flagging} those fields that contain mines.  Every time the user
-uncovers a field, the number of mines on adjacent fields is shown. If there are no mines on adjacent fields, all
-adjacent fields are automatically uncovered by the game in a recusive fashion. The user wins when all mine-free fields
-have been uncovered and all fields with mines flagged, and looses when they try to uncover a field with a mine on it.
-
-The fundamental approach to use minesweeper as a pairing method would be to encode the fingerprint into the minesweeper
-field. The host would encode the fingerprint, then let the user play the game using their mouse with the usual on-screen
-graphical representation of the game field. The device would besides forwarding all mouse input events to the host
-simultaneously trace all user actions in order to  Both host and device would emulate the game field and after a
-successful run the user will have marked all locations of mines, thereby out-of-band transferring the field
-configuration chosen by the host to the device.
-
-Minesweeper is very well-known and can be parametrized to be easily solved by most people. Compared to the task of
-sequentially clicking buttons as presented in the previous paragraph a user might prefer playing a game of minesweeper
-instead.  While various problems surrounding minesweeper are computationally hard\cite{demaine01}, field generation is
-easy. To place $n$ mines on a $x$ by $y$ grid one simply chooses an unordered subset of $n$ elements, of which there are
-$\tbinom{xy}{n}$. For the three default difficulty levels provided by the minesweeper game included in Windows XP the
-field state contains $\approx 40$, $\approx 156$ and $\approx 348$ bits of entropy respectively. This means even just
-two rounds on beginner difficulty, or a single round on intermediate difficulty already provide a cryptographically
-significant 80 bit security level. In the context of the interactive pairing protocol presented in this work, even a
-single beginner-level round of minesweeper already reduces the chance of an undetected man in the middle attack to a
-negligible level.
-
-A usability concern in this minesweeper-based pairing scheme would be user error. To improve user experience it would be
-wise to still consider a round, even if the user makes a mistake and looses the game. A simple way to do this that also
-intuitively handles user-set game difficulty levels would be to set a target entropy such as 40 bit, then repeat games
-until the target entropy is reached with each game's outcome contributing to the entropy level depending on the
-outcome's probability.
-with a multivariate hypergeometric distribution here, jk
-
-\paragraph{Adaption to button input}
-Adaption to button input using few buttons is a little bit harder. The obvious but impractical solution here is to have
-the user enter a very long numeric string. Entering an 80-bit number on a two-button binary keyboard is not
-user-friendly. One other option would be to emulate an on-screen keyboard similar to the ones used in arcade and console
-video games for joystick input. This would be more user-friendly and would likely be a natural interface to many users
-familiar with such games. One possible attack here is that if the host were to ignore dropped input packets, an attacker
-might selectively drop packets in order to cause a desynchronization of host and device fingerprint input states. The
-user would likely chalk up this behavior to sticky or otherwise unreliable keys and while they might find it
-inconvenient, they might not actually abort the procedure. Thus it is imperative that the host verify there are no
-dropped packets during pairing. This same observation is also true for keyboard or mouse-based pairing as explained
-above, but an attack would be much more noticeable there to users as mice and keyboards are generally regarded reliable
-by most users.
-
-\section{Evaluation}
-% FIXME
-
-\section{Future work}
-
-The aspects outlined in section \ref{altuse} provide potential future research directions. The adaption of the system to
-mouse input might be an interesting target for a user experience study, particularly in comparison with a purely
-keyboard-based system. The SSH key exchange method would be an interesting target for a general-use systems
-administration tool. Though we have done some basic security arguments in this paper, a more rigurous formalization
-might be interresting for future use of this technology. We have soundly argued about the user experience benefits of
-our method, but we have not performed any field experiments to back up these arguments. Future research might analyze
-the practical security a system as outlined in this paper yields under real-world conditions. The various trade-offs of
-e.g. keyboard vs. mouse input, fingerprint length and design details of the pairing UI might be analyzed with respect to
-practical usability and security.
-
-\section{Conclusion}
-% FIXME
-
-%\section{PCB design renderings}
-%\label{ch:renderings}
-
-%\begin{figure}[H]
-%    \centering
-%    \begin{subfigure}[b]{0.8\textwidth}
-%        \centering
-%        \includegraphics[width=0.8\textwidth]{pcb_front.png}
-%        \caption{PCB front}
-%    \end{subfigure} %
-%    \begin{subfigure}[b]{0.8\textwidth}
-%        \centering
-%        \includegraphics[width=0.8\textwidth]{pcb_back.png}
-%        \caption{PCB back}
-%    \end{subfigure}
-%    \caption{PCB design 3D renderings}
-%    \label{fig:pcb3d}
-%\end{figure}
-%
-%\begin{figure}[H]
-%    \centering
-%    \includegraphics[width=0.6\textwidth]{takachi_case.png}
-%    \caption{Off-the-shelf enclosure the PCB is made to fit}
-%    \label{fig:case}
-%\end{figure}
-
-%\subsection{Attack surface in reasonably secure systems}
-%\begin{figure}
-%\tikzstyle{block} = [rectangle, draw, text centered, minimum height=4em]
-%\begin{tikzpicture}[node distance=2cm, auto]
-%   \node[block](matrix){Key matrix}
-%   \node[block](hidctrl){Keyboard controller}
-%   \node[block](hubs){USB hubs}
-%   \node[block](roothub){USB host controller}
-%   \node[block](pcie){PCIe bus}
-%   \node[block](sys-usb-kernel){USB VM kernel}
-%   \node[block](sys-usb-agent){USB VM userspace agent}
-%   \node[block](dom0){dom0 agent}
-%\end{tikzpicture}
-%\label{qubes-hid-stack}
-%\caption{The USB HID input stack in a QubesOS setup}
-%\end{figure}
-
-\nocite{*}
-\printbibliography
-
-\appendix
-\section{Project state}
-A working prototype has been completed.
-
-\subsection{Completed}
-\begin{itemize}
-    \item Rough protocol design
-    \item Protocol implementation based on \textcite{perrin01} using noise-c (microcontroller) and noiseprotocol (python/host)
-    \item SRAM-based key storage with SRAM wear levelling
-    \item host/device signature checking
-    \item host/device key generation
-    \item proper circuit design (see appendix \ref{ch:renderings})
-\end{itemize}
-
-\subsection{Open issues}
-\begin{itemize}
-    \item Both noise-c and noiseprotocol have poor code and API quality. Since most noise functionality is not needed,
-        just implement the protocol in bare C/python based on cryptographic primitives and scrap higher-level protocol
-        implementations (though they've been useful so far during prototyping).
-    \item Implement HID mouse host support
-    \item Test USB hub support
-    \item Replace the serial link with a custom USB link using an STM32F103 instead of the CH340G USB/serial converter
-    \item Properly integrate prototype host client with qubes infrastructure
-    \item Implement photodiode/monitor-based pairing side-channel
-\end{itemize}
-
-\section{Possible directions}
-\begin{itemize}
-%    \item Elaborate handshake security properties
-%        \begin{itemize}
-%            \item Possibly investigate other applications of this type of interactive handshake
-%            \item Possibly contrast to carmera/other backchannel systems
-%            \item IMHO the pairing scheme is the most interesting part of this project from a scientific point of view
-% 			\item Prove security
-%        \end{itemize}
-%    \item Elaborate overall security properties of QubesOS-based system
-    \item Elaborate possible DisplayPort/HDMI-based display encryption $\rightarrow$ Bunnie's NeTV2 w/ HDMI/eDP converter
-%    \item Elaborate possible encrypted remote input (SSH) setups
-%        \begin{itemize}
-%            \item This might turn out to be really interesting
-%            \item For this to be usable the host needs to tell the device at least which keyslot to use which could turn
-%                out to be complex to implement securely
-%            \item Considering complexity, this might turn into its own research project
-%        \end{itemize}
-%    \item Showcase secure hardware interface design, contrast with wireguard protocol design
-%        \begin{itemize}
-%            \item Formally derive handshake security properties
-%            \item Formally derive host/device protocol security properties using noise spec
-%            \item Formally verify and thouroughly unit-test the host/device protocol implementation on all layers
-%            \item IMHO this is the most interesting part of this project from an engineering point of view
-%        \end{itemize}
-% Waiting
-    \item Create custom hardware prototype
-    \item Benchmark cryptography routines (will likely turn out to be ``wayyy fast'' for HID, fast enough for full-speed
-        USB. High-speed cannot be done with the current architecture as we can't get data out the chip at high-speed
-        data rates. \textcite{srivaths01} raise the issue of running crypto on embedded systems, but in this case it
-        turns out with somewhat modern hardware and cryptography there is no problem at all.
-\end{itemize}
-\end{document}