paper: WIP

1 files changed, 79 insertions, 10 deletions

diff --git a/paper/securehid.tex b/paper/securehid.tex
index 602d09b..4cc5a11 100644
--- a/paper/securehid.tex
+++ b/paper/securehid.tex
@@ -48,26 +48,96 @@
 \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}
+\author{Jan Götte {\texttt<secureusb@jaseg.de>}, HIIG}
+\title{Defending against malicious USB peripherals}
+\date{2021-03-02}
 \begin{document}
 \maketitle
 
+\section{Abstract}
+USB is a significant weak spot in modern end-user computer security. Key design decisions of the USB specification were
+made decades ago, in a world where few considered malicious uses of computers. Throughout the years, multiple attempts
+have been made at securing the USB interface, yet due to compatibility and user experience obstacles, none have so far
+been widely adopted.
+
+Our approach uses a small hardware device connected between host USB ports and sensitive HID peripherals to address
+these issues. It transparently augments standard hardware with authenticated USB ports that are secure against malicious
+USB device connected to the same system. Besides its USB security aspects, it allows for novel applications in network
+security: Our prototype allows secure administration of a remote server from a fully compromised client system.
+
 \section{Introduction}
-\subsection{Problem definition}
+USB is a blind spot in modern desktop and laptop computer security. USB is an extraordinarily versatile interface that
+is used for a variety of purposes in several places of any modern desktop or laptop computer. These uses range from
+connecting keyboards and mice through the USB human interface device (HID) series of standards to connecting hard disks
+or USB flash drives through the USB mass storage device class (MSC) standard. While the USB's flexibility is great for
+user convenience and significantly simplifies low-level driver and hardware design by standardizing a wide range of
+peripherals onto a single bus standard, it also carries significant risks.
+
+USB bus infrastructure occupies a highly privileged spot in a normal computer's security architecture. With few
+exceptions for very legacy PS/2 devices and bluetooth keyboards and mice, all user input passes into the computer
+through USB.  At the same time, an user may plug in any USB device into any port on the machine with no distinction
+between ports on any level from hardware to operating system.
+
+Considering its use for senstive devices such as keyboards, there are
+two main issues with USB. The first boils
+down to the interface being exceptionally versatile yet not considered security-critical when it was conceived. When a
+USB device is plugged into a computer, to the computer the device could be anything from a keyboard to a USB cup warmer.
+The key issue is that the computer has to fundamentally trust the device's description of its functionality if it wants
+to avoid asking the user to select the type of device they just plugged in from a giant list of thousands of device
+types. This first issue is hard to fix since it fundamentally stems from the way USB is intended to work by
+its specification.
+
+The second issue is that USB is fundamentally vulnerable towards eavesdropping attacks. While through the last
+decades most network communication has been moved to encrypted protocols, for backwards-compatibility reaseons USB is
+stuck with plaintext protocols even for sensitive application such as keyboard input. This makes USB vulnerable to
+eavesdropping attacks \cite{sgry17,nbk16}. In its most basic form this eavesdropping can happen at the physical level,
+performed by a neighboring device connected electrically nearby. It can also happen at the protocol level when e.g.\ an
+intermediate hub's firmware or a kernel driver gets compromised.
+
+In the past, there have been numerous attempts to approach these two issues \cite{kstu09}. Broadyly, we can attempt a four-way
+categorization of these approaches.
+\begin{description}
+    \item[Device authentication] attempts to whitelist devices for a particular use. The key here is that a device has
+        to provide an identity to the host for the host to recognize the device. A prominent project in this category is
+        the USB implementers forums' ongoing specification of cryptographic whitlelisting of device types through an
+        hierarchical PKI \cite{usb17} but a simple teaching approach where the user has to explicitely acknowledge any
+        device on first use is also possible \cite{gps17,wjs12,hlks14,usb01}.
+    \item[USB firewalls] attempt to limit USB devices on the protocol level. Beyond disallowing devce configurations
+        that are legal according to the standard but unlikely in practice such as rare device types, USB firewalls can
+        also limit what device types work on which port of the host computer. Like in USB device authentication, a
+        learning approach where the user teaches the system is an option \cite{tsbb16,ks17,tbb15,redhat19}.
+    \item[Logical isolation] attempts to split apart the unified USB stack into discrete components and prevent these
+        components from compromising each other. For example, QubesOS isolates USB drivers inside their own virtual
+        machine and only allows certain device types. In setups that use privileged devices like keyboards, this
+        technique alone cannot prevent host compromise as the (isolated) driver VM still has complete control over the
+        system's keyboard input \cite{awlb16,lhkl16}.
+    \item[Bus encryption] tries to prevent eavesdropping attacks by encrypting data sent through USB some of the way
+        between device and application \cite{nbk16}.
+\end{description}
+
+In this paper, we wish to consider one particular use case in the field of general USB security: The user of a desktop
+or laptop computer uses USB for various privileged devices such as mouse, keyboard and webcam but also wishes to connect
+untrusted USB devices to their system. These untrusted device may be ones like other people's USB flash drives or a
+shared USB presenter remote in a conference room. 
+
+% HERE, ^^^^ new / old vvvv
+
+In this paper we focus on limiting the impact of a malicious USB device plugged into a computer by its user. While there
+are other interesting scenarios, this scenario encompasses a multitude of everyday use cases such as the common one of
+inserting an untrusted USB flash drive into one's computer.  What this attack model does not capture are direct physical
+attacks. We do not try to prevent an attacker who has in-person physical access from compromising the target system. 
+
 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}
+\section{Related work}
 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}.
@@ -108,7 +178,7 @@ keyboard that does not have its own dedicated PCIe USB host controller, as any n
 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}
+\section{Threat model and use cases}
 
 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
@@ -144,8 +214,7 @@ inconvenient. A journalist or politician will frequently have to read USB flash
 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}
+\section{System architecture}
 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
@@ -170,7 +239,7 @@ formally verified in the past and the protocol has been kept simple enough to al
     \label{diagram_with}
 \end{figure}
 
-\subsection{System security properties}
+\subsection{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