diff options
Diffstat (limited to 'paper/research_directions.tex')
| -rw-r--r-- | paper/research_directions.tex | 880 |
1 files changed, 880 insertions, 0 deletions
diff --git a/paper/research_directions.tex b/paper/research_directions.tex new file mode 100644 index 0000000..602d09b --- /dev/null +++ b/paper/research_directions.tex @@ -0,0 +1,880 @@ +\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} |