In Copyright - Non-Commercial Use Permitted Rights / License: … · 2020-02-15 · should also provide security guarantees. Additionally, securing software applications on the computer

Research Collection

Master Thesis

USB Communication Security: Threats and Countermeasures

Author(s): Yu, Der-Yeuan

Publication Date: 2012

Permanent Link: https://doi.org/10.3929/ethz-a-010624676

Rights / License: In Copyright - Non-Commercial Use Permitted

This page was generated automatically upon download from the ETH Zurich Research Collection. For moreinformation please consult the Terms of use.

ETH Library

https://doi.org/10.3929/ethz-a-010624676

http://rightsstatements.org/page/InC-NC/1.0/

https://www.research-collection.ethz.ch

https://www.research-collection.ethz.ch/terms-of-use

USB Communication Security:Threats and Countermeasures

Master Thesis

Der-Yeuan [email protected]

Tuesday 23rd October, 2012

Advisers:Prof. Dr. Srdjan Capkun

Ramya Jayaram MastiClaudio Marforio

Davide Zanetti

Department of Computer ScienceETH Zurich

To Grandma

Abstract

The Universal Serial Bus (USB) specification is a popular standard forcommunication between computers and their peripherals. Today, avariety of devices support the USB interface, ranging from mass storageto personal healthcare products. Although these devices may containsensitive information, they are often security-agnostic (e.g., they senddata to the host in plaintext). The commercial nature of these devicesoften implies that modifying them (or their accompanying software) isimpractical.

In this thesis, we investigate the security of the USB communicationstack. We discuss the effects of the compromise of hardware or soft-ware components in the stack and show that various attacks (e.g. im-personation of USB devices) are possible even if an adversary does notcontrol the host OS. To prevent these attacks, we propose a solutionconsisting of two parts: a USB device access control module and a se-cure USB bridge. The USB device access control module uses securitymechanisms existing in modern operating systems to prevent accessfrom unauthorized or altered software. The secure USB bridge acts asa proxy between a USB device and the host, providing a secure chan-nel between them. Our design is compatible with existing commodityproducts without further modification. We show the feasibility of re-alizing our solution through a prototype implementation of the secureUSB bridge and evaluate its performance.

ii

Acknowledgment

I would like to thank Professor Srdjan Capkun for providing a motivating en-vironment for security research and directing me towards a future academiccareer. I thank my supervisors Ramya Jayaram Masti, Claudio Marforio,and Davide Zanetti for advising my thesis and providing helpful insightsand feedback. I also thank my colleagues and friends Nikos Karapanos, Hu-bert Ritzdorf, Petar Tsankov, Michele Feltz, Luka Malisa, Nan Zhong, andIlias Rinis for their valuable input.

iii

Contents

Contents iv

1 Introduction 1

2 Background 32.1 USB Specification . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Device Classification . . . . . . . . . . . . . . . . . . . . 32.1.2 Device Hierarchy . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Device Enumeration . . . . . . . . . . . . . . . . . . . . 62.1.4 Communication Types . . . . . . . . . . . . . . . . . . . 62.1.5 Data Packet Format . . . . . . . . . . . . . . . . . . . . 72.1.6 Data Connectivity . . . . . . . . . . . . . . . . . . . . . 8

2.2 Linux USB Host Subsystem . . . . . . . . . . . . . . . . . . . . 9

3 Related Work 113.1 USB Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Software Security . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Launch-time Security . . . . . . . . . . . . . . . . . . . 123.2.2 Run-time Security . . . . . . . . . . . . . . . . . . . . . 133.2.3 Post-execution Security . . . . . . . . . . . . . . . . . . 15

4 Problem Statement 164.1 System Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Goals of the Adversary . . . . . . . . . . . . . . . . . . . . . . . 174.3 Thesis Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Security Analysis of Linux USB Communication 195.1 Definition of Attacks . . . . . . . . . . . . . . . . . . . . . . . . 195.2 Feasibility of Attacks . . . . . . . . . . . . . . . . . . . . . . . . 215.3 Refined Adversary Model . . . . . . . . . . . . . . . . . . . . . 29

iv

Contents

6 Design of a Secure USB Communication Stack 306.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.2.1 USB Device Access Control Module . . . . . . . . . . . 336.2.2 Secure USB Bridge . . . . . . . . . . . . . . . . . . . . . 34

6.3 Security Analysis of Our Design . . . . . . . . . . . . . . . . . 37

7 Implementation and Evaluation 387.1 Key Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397.2 Message Encryption . . . . . . . . . . . . . . . . . . . . . . . . 417.3 Preliminary Evaluation . . . . . . . . . . . . . . . . . . . . . . . 44

7.3.1 Bulk Device . . . . . . . . . . . . . . . . . . . . . . . . . 457.3.2 Flash Drive . . . . . . . . . . . . . . . . . . . . . . . . . 587.3.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 65

8 Conclusion and Outlook 66

Bibliography 68

v

Chapter 1

Introduction

The Universal Serial Bus (USB) specification has been a popular standardfor communication between computers and peripherals. Today, a large num-ber of devices support the USB interface. The industry is now shippingmore than 3 billion USB devices a year [1], ranging from keyboards, mice,to flash-based storage drives, smart phones, and healthcare devices. Withthe proliferation of USB, users are storing more data in USB devices, whichmay include sensitive data such as personal medical information. However,some USB products are designed without security considerations. For ex-ample, we have discovered a commercial blood pressure meter which sendsout the measurements of patients using an unencrypted protocol [2]. Addi-tionally, the devices and their accompanying software are often provided bymanufacturers as-is and are therefore impractical to modify.

To interact with USB devices, users typically use software applications, pro-vided either by their manufacturers or the operating system. Unfortunately,security-agnostic USB products expose their communication with comput-ers to potential attacks. For example, in [3], implementation flaws were dis-covered in an automated external defibrillator (AED) with a USB program-ming interface and its accompanying software, allowing the AED firmwareto be maliciously reprogrammed by an adversary. In addition, the lack ofmessage-level security allows an adversary in the communication channelto intercept and insert data, posing a threat to both the USB device andthe software application. Hardware adversaries such as USB sniffers andfuzzers [4] exist to passively eavesdrop or actively modify transmitted data.Software adversaries may also interfere with the communication by exploit-ing vulnerabilities of the underlying operating system.

Efforts in securing USB communication have mostly been focused on USBmass storage devices such as USB flash memory or hard disk drives byproviding data encryption and user authentication [5, 6]. On the otherhand, any other USB device which potentially exchanges data with software

1

should also provide security guarantees. Additionally, securing softwareapplications on the computer from USB-related attacks is also an importantissue.

This research aims at investigating threats surrounding general USB com-munication, both to the device and its application. We explore possibleattack vectors in the USB communication environment to identify adversarymodels and their capabilities. Our objective is to provide communicationsecurity for a generic USB device and its software, while also specifying andenforcing software policies on the computer to prevent malicious softwarefrom interfering with the communication.

Our solution consists of two parts:

• A USB software access control module, which uses the existing tech-nologies for discretionary/mandatory access control and integrity ver-ification in the OS to allow only authorized and unaltered software toaccess the USB device.

• A secure USB bridge, which acts as a proxy for a generic USB deviceto communicate with the host computer. The bridge creates a securechannel between the device and the host such that their communica-tion provides message integrity and confidentiality.

This solution is transparent to both the USB device and its application, andis suitable for a generic, security-agnostic USB product. Most importantly,no modification is required on the USB device or its application.

Based on our design, we implement a prototype secure USB bridge and aLinux kernel module to serve as a proof-of-concept realization of securedUSB communication. We measured the performance of our implementa-tion with commodity USB devices. When encrypting communication (formessage confidentiality) using RC4, our prototype bridge decreases the per-formance by 82.5% for file reading and 74.2% for file writing operations;when the bridge uses AES encryption, the performance decreases by 90.8%and 80.7% respectively. Based on a series of benchmarks, we evaluate thefeasibility of our solution and discuss our findings.

This thesis begins by highlighting some background information on the USBspecification and the Linux USB software stack in Chapter 2. In Chapter 3we investigate related work to secure a communication between USB de-vices and host computers. We present our problem statement in Chapter4. Chapter 5 analyses the attack surface in our system model based on var-ious adversary capabilities. Based on the analysis, we propose our solutionin Chapter 6. Chapter 7 covers the implementation and evaluation of theprototype bridge. We conclude our study in Chapter 8.

2

Chapter 2

Background

In this chapter, we first provide a highlight of the USB specification whichis essential to the comprehension of this thesis. As a case study, we inves-tigate how USB support is implemented in modern operating systems byexamining the Linux USB host subsystem.

2.1 USB Specification

USB is a standard for communication between computers and electronic de-vices, introduced in 1996 and maintained by the USB Implementers Forum(USB-IF) [7]. The standard defines hardware connector specifications andcommunication protocols between a USB host computer and a USB periph-eral device. All USB devices are connected to the host controller throughUSB hubs. The USB standard has progressed from version 1.0 to 1.1, 2.0,and the latest USB 3.0. For the scope of our study, we focus on USB 2.0,which is currently the most widely version supported by hardware manu-facturers.

2.1.1 Device Classification

A USB device is categorized using a three-level classification defined by USB-IF, which consists of: a base class, a subclass, and a protocol. Base on thisclassification, the host computer OS often contains generic drivers whichare developed for each device type such that they can communicate withdevices regardless of their manufacturers. This classification information isstored in the device and sent to the host computer when it is plugged in.Table 2.1 shows some popular predefined base classes. Complete base classinformation as well as definitions of subclasses and protocols can be foundin [7].

3

2.1. USB Specification

Base Class Description

0x01 Audio0x03 Human Interface Device0x06 Image0x07 Printer0x08 Mass Storage0x09 USB Hub0x0B Smart Card0x0E Video0x0F Personal Healthcare0x10 Audio/Video Composite0xE0 Wireless Controller0xFF Vendor Specific

Table 2.1: Common base classes defined by USB-IF

2.1.2 Device Hierarchy

The USB standard allows a single device to perform multiple functions; e.g.,a keyboard integrated with a USB hub. Devices with multiple functionsare known as composite devices. The USB specification utilizes a hierarchi-cal tree-like data structure which defines each of these functions in detail. AUSB device hierarchy consists of a top level device as the root, which containsnumerous configurations from which the host chooses to activate one. Eachconfiguration provides power demand information, as well as the number ofinterfaces this configuration offers when its active. Each interface representsa particular function, such as the keyboard or the USB hub in the previousexample, and contains information on the endpoints used for this interface.Endpoints, as the name indicates, are the communication endpoint withwhich the host exchanges data, and are the terminal nodes in the hierar-chy. The endpoints can be further classified into two types: IN endpoints,from which the host receives data, and OUT endpoints, to which the hosttransmits data. When a configuration is active, all of its specified interfacesand their corresponding endpoints are available for communication with thehost. For example, a composite device functioning as a wireless dongle anda flash drive would expose the two functions as two independent interfacesin a single configuration, each defining their own sets of endpoints to com-municate with the host computer. An example hierarchy tree is provided inFigure 2.1.

To assist the USB host computer in learning its functional hierarchy, the de-vice reveals structural information through descriptors that the host queries.Descriptors are data structures with predefined data fields that contain in-formation essential to the host. Based on the hierarchy of the USB device,

4


Figure 2.1: USB peripheral hierarchy. Each node is represented by a descrip-tor which will be sent to the USB host during the enumeration process.

there are five types of descriptors.

• Device descriptors, representing the device. The vendor and productIDs are specified here, as well as the classification information. Theclassification may also be empty, suggesting a composite device, inwhich case each function class is stored in its respective interface de-scriptors.

• Configuration descriptors, representing a configuration. The powerrequirements and the number of interfaces when this configuration isactive.

• Interface descriptors, representing an interface. This descriptor con-tains the USB classification specific to this interface as well as the num-ber of endpoints available. For composite devices, the classificationinformation of each function is also specified here.

• Endpoint descriptors, representing an endpoint. The endpoint ad-dress, ranging from 1 to 15, and the direction of data transmission(IN or OUT) is specified here. Additionally, the endpoint descriptoralso specifies the maximum number of bytes which the endpoint cantransmit or receive at a time.

• String descriptors, storing an array of strings to which data fields inthe above descriptors may refer. For example, the device descriptorcontains a field specifying the device manufacturer name, which is aninteger index to the array of strings defined here.

The USB host requests these descriptors from the device during the enumer-ation process to configure the host-side driver. By default, an endpoint zerois always available and is dedicated to host-device communication duringenumeration.

5


2.1.3 Device Enumeration

USB communication is host-driven. Namely, data is only sent from the de-vice upon request by the host. The USB host computer contains a USBhost controller, which is commonly implemented as a hardware chip or di-rectly integrated into the south bridge of the motherboard with a USB hostfirmware.

When a USB device is plugged in, the host initiates the driver enumerationprocess to identify the device and load the corresponding driver. In detail,the USB hub notifies the host that a new device is attached. The host thencommunicates with the device to identify the supported speeds, acquire itsdescriptors and finally assigning the device a unique address on the bus. Thedevice class, vendor and product information contained in the descriptorsact as the primary reference for the host computer to load the proper devicedriver. The driver communicates with the device through the USB stack ofthe OS, exposing the device resources in a logical level to the user, such as awebcam or storage space.

2.1.4 Communication Types

As previously mentioned, communication with the USB device involvessending and receiving data to and from endpoints. The host communicateswith endpoint zero to obtain essential information such as USB descriptorsduring the enumeration step. After the endpoints of the interfaces are iden-tified, the host sends tokens to them to initiate various types of data transfer.

The USB standard defines the following four data transfer types. Each end-point takes upon one of these types.

• Control transfers. The host may use control transfers to acquire in-formation, such as the USB descriptors, from the device during enu-meration. Control transfers may also be used for any miscellaneousconfiguration requests defined by a USB vendor. Messages transferredduring control transfers are specially formatted as setup packets. Eachsetup packet consists of either a standard command to the device (e.g.,fetching a descriptor or assigning a device configuration) or a product-specific command defined by the vendor. During control transfers, anadditional data field of variable length may also be associated withthe setup packet. This field may be filled either by the host to sendspecific data to the device or by the device to contain its response (e.g.,the device descriptor) to the command in the setup packet.

• Bulk transfers. The bulk transfer is the basic method of transmissionand is typically used for high-volume data communication such asprinting documents or storing files in mass storage. Bulk transfersguarantees data delivery but provides no dedicated bandwidth.

6


• Interrupt transfers. When a device requires the attention of the host,an interrupt transfer is used to send data. Since the communicationis host-driven, the host should regularly poll to check if any inter-rupt data is available from the device. Interrupt transfers guaranteean upper-bound on the latency of transmission and provide error de-tection and retransmission mechanisms. A HID peripheral such as amouse often uses interrupt transfers to achieve instantaneous responsefor the sake of smooth user experience.

• Isochronous transfers. Devices providing data with a limited timewindow of validity may use isochronous transfers to send it. Exam-ples include streaming video from a webcam or streaming audio froma microphone. Isochronous transfers do not provide guaranteed deliv-ery. However, for timely delivery of data, the host reserves a portionof the USB bandwidth for isochronous transfers.

2.1.5 Data Packet Format

The USB specification defines protocols for data packets exchanged betweenthe host and the device. Each data packet contains information about thetransfer and its corresponding data. The header information consists of thefollowing fields.

• The SYNC field, a coded sequence used for data alignment and clocksynchronization on the recipient hardware.

• The Packet field, containing the following information.

– Packet identifier (PID), data type tokens (IN, OUT, Start-of-Frame,and SETUP) and various handshake information.

– Function address (ADDR), containing the address of the functionassigned by the host after enumeration.

– Endpoint address (ENDP), containing the endpoint number of thefunction.

– Frame number, a counter for the number of data frames trans-ferred.

– Data, the actual data to be transferred.

– Cyclic redundancy check, allowing error checking of all fields ex-cept the PID field.

7


(a) Downstream broadcasting.The hub broadcasts down-stream data packets to alldown connected downstreamports.

(b) Upstream forwarding. Thehub forwards data from onedownstream port to the up-stream port.

(c) Idle. All connectivity is dis-abled and no data packet isrouted.

Figure 2.2: Hub connectivity illustration. The hub contains one upstreamport (green) and multiple downstream ports (four in blue) as well as itsrouting logic (gray). In this scenario, three of the downstream ports areconnected with USB devices.

2.1.6 Data Connectivity

Now we introduce the actual routing of data packets in the USB specification.Recall that all USB devices are connected to the host computer through USBhubs. The host controller exposes a root hub which serves as the first tier inthe USB topology. A USB hub contains an upstream port, connected to thehost side, and potentially multiple downstream ports, which are connectedto devices. Routing logic built in the USB hub forwards data between the up-stream and downstream ports in different ways depending on the directionof the data packets.

Figure 2.2 illustrates three states the hub may take upon during messagetransmission. When data packets are detected from the upstream port, thehub broadcasts them to all downstream ports. Devices connected to thedownstream ports are responsible for observing the function address (ADDR)field and discarding any packets other than the ones which match theirassigned address during enumeration. Before enumeration is complete, thedefault address for the device is 0, to allow enumeration over its defaultendpoint zero. When the hub detects data sent from a downstream port, itenables only its connection with the upstream port and forwards the datapacket. As a result, no other downstream ports on the hub observes the datapacket. An idle state is also defined for the USB hub in the absence of datapackets from both the upstream and the downstream ports. In this case theUSB hub disables all connectivity and awaits the detection of data packetsfrom either end.

8

2.2. Linux USB Host Subsystem

Figure 2.3: The Linux USB host software stack

2.2 Linux USB Host Subsystem

The Linux kernel supports USB host-side communication via two main com-ponents, usbcore, the central framework for USB communication, and aUSB host controller driver, used to control a vendor-specific USB host con-troller in hardware to actually communicate with USB devices. usbcore pro-vides a unified programming interface for software to access USB devicesand interacts with host controller drivers, which is specific to various USBhost controller manufacturers. The usbcore module exposes USB function-ality through kernel-space functions for kernel-space software and a virtualfile system (vfs) known as the USB File System (usbfs) for user-space ap-plications. Figure 2.3 provides an overview of the USB subsystem and itsinteraction with USB software.

Kernel-space device drivers for common USB devices such as keyboards,mice, and mass storage, communicate with USB devices using kernel-spacefunctions provided by usbcore [8]. USB Request Blocks (URBs) are basicelements to initiate data transfer with USB devices, consisting of essentialinformation including

9

2.2. Linux USB Host Subsystem

• USB device information

• Transfer type and various settings

• Pointers to memory space either containing the data to transmit or thebuffer prepared to store received data

• A completion handler function, invoked after the USB transfer is com-pleted

Kernel modules may also make use of Linux memory I/O primitives such asDirect Memory Access (DMA) or Scatter/Gather data structures to improvethe efficiency of transmission [9]. DMA relieves the burden on the CPU fordata copying by delegating communication between the main memory andthe USB host controller to an external DMA controller. The Scatter/Gatherdata structure allows transferred data to be stored in non-contiguous mem-ory space.

With various helper functions to initiate a URB data structure, kernel-spaceUSB drivers pass the URB data structure to the kernel function (namedusb submit urb) to schedule the transfer. After the transfer completes suc-cessfully or fails due to errors, the completion function is called to post-process the transmission and execute clean-up routines. To user-space, ker-nel USB drivers ultimately expose USB device functionality through devicefiles in the file system, which may be accessed by user-space programs. Forexample, Linux webcam drivers abstract the low-level USB communicationspecifics and provide the device files /dev/video* for user-space webcamsoftware to access using ioctl calls [10].

In the absence of a kernel-space driver for a particular USB device, user-space software may still interact, using ioctl, with USB devices by accessingthe usbfs, which directly exposes USB devices as device files. The usbcore

module processes requests sent through usbfs and creates URB requestssimilar to those issued by kernel-space drivers. In this case, the user-spacesoftware is responsible for implementing the communication protocols tocommunicate with the device. Software libraries such as libusb [11] providean abstraction layer to these device files and allow easier access for user-space software.

10

Chapter 3

Related Work

3.1 USB Security

The widespread use of external computer peripherals has raised securityawareness regarding their impact on overall system security [12]. Particu-larly, the popularity of USB in the consumer electronics market has led tosecurity research in USB devices. In [13], the authors introduce multipleways of compromising a host computer such as abusing auto-run featuresin the OS to automatically execute malware or exploiting host USB driversby unexpected protocol messages. In [14], the author explores possibilitiesof programmable HID devices sending mouse or keyboard signals to thehost computer to issue administrative commands or execute malicious pro-grams. Hidden channels were identified in [15], which allow a USB deviceand a host computer program to collude and leak host-side information.For example, malicious software may send personal information found inthe host computer to a malicious USB keyboard using special sequences ofchange notifications for Caps Lock, Num Lock and Scroll Lock states. Toprevent against attacks from malicious devices, it has been suggested thatin a security-sensitive environment, USB devices be audited and whitelistedwhen plugged into the computer, allowing only recognised devices to inter-act with host drivers [16].

Another aspect in USB security lies in identifying potential attacks over thecommunication channel between a legitimate USB device and a host [3].Generally, USB devices capable of exchanging sensitive data should imple-ment security features to ensure message integrity or confidentiality. How-ever, studies have shown that these secure protocols, although existent, havenot been able to provide high security guarantees due to design and imple-mentation flaws. In [17], the authors investigated communication betweenpersonal health record devices and their corresponding device applications,and identified vulnerabilities in password storage and during authentication

11

3.2. Software Security

processes. Furthermore, these devices often contain backdoor functions foremergency purposes, allowing partial data access without password authen-tication but posing as a threat to personal information privacy. In [18], somecommercially available USB flash drives with data encryption features wereanalysed, revealing weaknesses in communication protocols and retrievingaccess passwords. As a solution, various USB communication protocols havebeen proposed to provide secure user authentication [19]. Secure commu-nications specifically for USB mass storage devices have also been exploredand evaluated for their performance impact [5, 6]. Additionally, in [20], apatent was filed disclosing a mechanism which makes use of trusted execu-tion environments in the host computer to process sensitive USB traffic.

Previous efforts, as mentioned above, explore security issues for specific USBdevices. However, there has been limited research in analysing security ofa communication environment consisting of generic USB devices and theirsoftware applications, which is addressed by this thesis.

3.2 Software Security

There has been extensive research in providing a secure environment to pro-tect legitimate applications and enforcing policies during software execution.Here we classify these techniques into three categories: launch-time, run-time,and post-execution software security.

3.2.1 Launch-time Security

Before execution, the system (the entity that loads the binary) must decidewhether the binary is allowed to run. Efforts can be classified into blacklistingand whitelisting, as listed below.

• Blacklisting

– Antivirus software currently available in the market provides de-tection of malware such as rootkits, worms, and quarantines sus-pect malware to prevent user execution. The software functionsby scanning the computer and searching for known malware sig-natures collected in a database. In some cases, certain heuristicsare also used to identify possible zero-day attacks [21, 22].

• Whitelisting

– Verified kernels like Coyotos [23] and seL4 [24] are efforts to con-struct small and trustworthy kernels through development withformal methods, providing a reliable basis for software execution.However, their stress on formally-proven reliability and does notscale well for use in modern OSes.

12


– Trusted computing techniques aim at guaranteeing code integrity.Fail-stop mechanisms can be designed to prevent software execu-tion whenever its integrity measurement is inconsistent with thatof a known good state [25, 26, 27, 28].

– In the particular case with device drivers, authenticating driversoftware based on their signatures allows only legitimate vendordrivers to be loaded into the system. This mechanism is currentlyemployed in modern Microsoft Windows operating systems [29].Moreover, all modern operating systems make efforts to includedrivers of most devices in the kernel or a trusted repository forinstallation [30, 31]. Regardless of these safeguards, users inter-vention are often required to allow loading of unauthenticateddrivers. As a result, the threat of malware infection still remainsdue to user negligence.

3.2.2 Run-time Security

Run-time security measures address two issues: protecting the system envi-ronment and ensuring correct software execution [32]. The common solutionto achieving either goal is isolation. In the former case, a sandbox is oftencreated to envelop an application from unwanted access to the host envi-ronment. In the latter case, guaranteeing platform integrity can normallybe ensured by applying the measures described previously to ensure a safeexecution environment, thereby creating a Trusted Computing Base (TCB).Furthermore, there have been efforts to reduce the code size of the TCB suchthat the system can be booted with some compromised components yet stillguarantee correctness of program execution.

• Sandboxing

– Virtualization and hypervisors such as VirtualBox [33] and Xen[34] allows users to create individual virtual environments inwhich untrusted applications may run in isolation from other sys-tem software.

– Program shepherding [35] is a method for monitoring controlflow transfers during program execution, and specifically 1) re-stricts executions of code, 2) restricts control transfers, and 3) en-forces software policies.

– Information flow control [36, 37] is similar to program shepherd-ing but focuses on containing the transfer of important data. Trustedsoftware modules oversee the exchange of sensitive data with un-trusted software to ensure confidentiality and integrity.

13


– Mandatory access control, which is implemented by software likeAppArmor [38] and SELinux [39], restricts privileges of individ-ual software based on custom defined rules and constraints.

– SUD [40] is an effort to secure the Linux kernel by migratingkernel-space drivers to user-space such that malicious drivers donot compromise the kernel. In addition, further constraints areimposed to restrict device hardware from accessing memory byusing existing components like the IOMMU.

• Trusted Computing Base Minimization

– Flicker [41] allows applications to run in trusted virtualized en-vironments provided by modern Intel and AMD processors, ef-fectively removing the need to trust a potentially compromisedoperating system. This method requires modification of the appli-cation and constant use of the physical Trusted Platform Module(TPM), which is often slow [42].

– TrustVisor [43] is an improvement of Flicker which is a hypervisorthat utilizes a software dynamic root of trust on guest virtualiza-tions. This removes the computational overhead of cryptographicfunctions in the TPM.

– CARMA [44] exploits the Cache-as-RAM mechanism on ModernCPUs, which is originally used to load the memory controller dur-ing bootstrap, and uses it as an isolated execution environmentfor generic software. As a result, the correctness of the applica-tion relies on the integrity of the CPU. However, this solutiondepends on specific hardware setup.

– TRESOR [45] is a patch to the Linux kernel which implementsthe AES encryption algorithm and key management solely on theprocessor, thereby also excluding the memory from the TCB. TRE-SOR makes use of the CPU support for AES-NI instructions forAES encryption but is not applicable to generic software applica-tions.

• Specialized security hardware is also another direction in research.

1. AEGIS [46] is a processor architecture which contains physicalrandom functions and off-chip memory protection mechanisms.However, the requirement for special hardware for these solutionsdoes not fit our user environment, which consists of general per-sonal computers.

14


3.2.3 Post-execution Security

After software has completed execution, an intuitive solution to guarantee-ing correctness is often done by comparing the system state with a knowngood state. With the help of the TPM, we may perform remote attestation [47],which proves to an external entity the integrity of the system.

Another more extreme solution which shifts the reliance on a single com-puter to multiple computers is secure multi-party computation [48], from whicha correct computation result can be generated through cryptographic proto-cols and consensus despite the existence of compromised computers. Thissolution aims at computation correctness through redundancy, and are there-fore infeasible for general personal computing.

15

Chapter 4

Problem Statement

After introducing background information, this chapter provides an overviewdiscussion of our problem. We begin by introducing the system model ofUSB communication in a general setting and identify the goals of the ad-versary. Based on the system model and adversary goals, we outline theobjectives of our thesis.

4.1 System Model

Generally, a USB communication between a device and a host computerconsists of the following components.

• A USB device provided by a vendor, later referred to as the device.

• A computer, later referred to as the host, which runs an OS supportingboth the device and its application. In our study, we focus on the LinuxOS.

• A software application which communicates with the device, later re-ferred to as the device application. This includes user applications anddevice drivers included in the host or provided by the vendor of thedevice.

The interaction between the host computer is depicted in Figure 4.1.

In this environment, a typical use case includes the following steps.

1. As an optional step, the user first installs the device driver.

2. The user plugs the device into the computer.

3. The user starts the device application.

4. The user interacts with the device through the device application.

16

4.2. Goals of the Adversary

USB Device

Device application

Host computer

Figure 4.1: The system model for general USB communication, consisting ofthe USB device, the device application, and the host computer.

The Linux kernel USB subsystem, as introduced in Section 2.2, provides theabstraction for software applications to interact with the USB device. Thedevice application may interact with the device through kernel-space devicedrivers or the usbfs virtual file system.

4.2 Goals of the Adversary

From the security perspective, we differentiate between two types of mali-cious goals of the adversary.

• Steal information. The adversary may wish to passively obtain sensi-tive data from the communication between the device and the deviceapplication. The sensitive data could be, for example, medical recordsof a patient stored on a USB personal healthcare device. Informationstealing can be achieved by eavesdropping the USB data transferredduring communication. In addition, an unsecured communicationprotocol also allows the adversary the possibility of communicatingdirectly with the device or its application.

• Interfere with communication. In contrast to the passive attack ofstealing information, the adversary may intend to perform an activeattack by interfering with the messages exchanged between the end-points. For example, in the case of a personal healthcare device, boguspersonal records may be sent to the device application. Erroneous con-figurations may also be sent to the device to affects its proper functions.The adversary may achieve this by compromising certain componentsof the system, or communicate directly with the endpoints if the com-munication protocol is insecure.

17

4.3. Thesis Objectives

4.3 Thesis Objectives

In this thesis, we investigate potential security issues with USB communi-cation. We first survey previous work, as summarized in Chapter 3, onthe security of USB communication and discuss their differences with thisstudy. We then identify the attack surface under the system model with aLinux-based host computer, and analyse all possible attacks the adversarymay perform to achieve her goals as well as the feasibility of various attacks.Based on the feasibility analysis, we define a realistic model of adversarycapabilities, and provide a solution to ensure communication security forgeneric security-agnostic USB device and their applications under this threatmodel.

18

Chapter 5

Security Analysis of Linux USBCommunication

In this chapter, we provide definitions of attacks by the adversary, and dis-cuss how they can be realized in the USB communication stack such that theadversary may achieve her goals defined in Section 4.2.

5.1 Definition of Attacks

To achieve the goals as previously defined, the adversary utilizes the follow-ing five attack primitives over the communication.

• Eavesdropping

• Modification

• Insertion

• Deletion

• Impersonation

The first four attacks assumes that two legitimate endpoints1 have estab-lished connection and started communicating. We now continue to thedefining these attacks.

We break down communication to single-direction message transmissionsbetween legitimate endpoints A and B, namely, the device and its applica-tion, or the application and the device respectively; the adversary is repre-sented by E. The attack primitives are illustrated in Figure 5.1.

1We use the term endpoint here to refer to the entities on either end of a communicationchannel. This is not to be confused with the endpoint defined in the USB specification.

19

5.1. Definition of Attacks

A BE(a) Eavesdropping

A BE(b) Modification

(c) Insertion (d) Deletion

A BEid = 'A'

(e) Impersonation

Figure 5.1: The attack primitives for message eavesdropping, modification,insertion, and deletion. An variant of the insertion attack is the imperson-ation attack, in which the adversary sends false identity information to oneendpoint. Dotted lines imply that the entity may or may not be active in thecommunication session.

Eavesdropping

Eavesdropping is the act of obtaining messages exchanged between two end-points while they communicate with each other.

• Endpoint A sends x ∈ Σ

• Endpoint B receives x

• Adversary E receives x

Modification

Modification is defined to be modifying messages sent between endpointssuch that a message received at the destination endpoint is different fromthe one sent from the source endpoint.

• Endpoint A sends x ∈ Σ

• Endpoint B receives x, where x 6= x.

Insertion

Insertion is defined as a synthesis of a message to send to one endpoint,misleading it to interpret the synthesised message as originated from thesource endpoint currently in communication.

20

5.2. Feasibility of Attacks

• Endpoint A does not send any message.

• Endpoint B receives x.

Deletion

Deletion is defined to be the elimination of a message during transit suchthat a message sent from a source endpoint does not reach its destinationendpoint.

• Endpoint A sends x.

• Endpoint B does not receive any message.

Impersonation

Impersonation is defined as the adversary establishing a communicationchannel independent of a legitimate endpoint with the other endpoint whileclaiming itself as be legitimate. Note that with impersonation attacks, onlythe targeted endpoint needs to exist.

5.2 Feasibility of Attacks

After identifying the different types of attacks, we investigate how they canbe accomplished by the adversary.

From the Linux host USB subsystem introduced in Section 2.2, the followingcomponents could be controlled by the adversary.

• A malicious device

• Compromised physical connection between the device and host

• Compromised user account in the host OS

• Compromised host OS kernel

• Compromised host hardware

These different levels of system compromise grants the adversary variouscapabilities to mount the attacks defined in Section 5.1. We discuss thefeasibility of these attacks and their requirements. Table 5.1 overviews thecapabilities of the adversary in these different levels. We further base thefollowing discussions on how attacks can be achieved. The summary ofthese dicussions are shown in Tables 5.2, 5.3, and 5.4.

21


Controlled Entity Essential Components Achievable AttacksMalicious device A USB device which is

connected to the hostImpersonation of device,eavesdropping datafrom host, and insertingdata to host

Physical connection USB cables, hubs Any

Host User-levelprivileges

User-space resourcessuch as files, envi-ronment variables, orruntime memory space

Potentially any attack,depending on how theresources used by the de-vice application can beexploited

OS Kernel-space resourcessuch as modules andthe USB subsystem

Any

Hardware CPU, memory compo-nents, USB host con-trollers, etc.

Any

Table 5.1: Summary of the capabilities of the adversary under various levelsof compromise

A malicious device

Consider the case where the adversary is a malicious USB device (exceptfor a USB hub) plugged into the host computer. Given an insecure commu-nication protocol between the legitimate device and its application, she canreplicate insecure communication protocols and therefore achieve imperson-ation attacks by pretending to be a legitimate device while communicatingwith the device application.

As an instance, the malicious device is plugged into the computer alongwith the legitimate device. The device application starts and observes twocompatible devices available for use. The attack would be successful if themalicious device is selected, either with or without user intervention.

Recall in Section 2.1.6, the USB hubs broadcasts all data sent from the hostto all downstream devices, placing the responsibility of ignoring unrelateddata on USB devices. As a result, the malicious device may eavesdrop onUSB data sent from the host by recording all traffic received, regardlessof the values in the function address field. When dealing with upstreamdata sent from devices to the host, USB hubs forwards data packets withoutverification from downstream ports to the host whenever available. This

22


grants the adversary the potential to mount insertion attacks on the host bysending out data packets to the host with a forged function address andendpoint address.

Other attacks, namely, eavesdropping data sent from other devices, insertingdata to devices, modifying or deleting data sent from either the host or thedevice would not be accomplished due to the lack of connectivity definedby the specification of USB hubs.

Compromised connection between the device and host

The physical connection, including the USB cables and USB hubs, can becompromised by the adversary through techniques from basic wire-tappingto controlling a USB hub. In this event, all attacks can be achieved if thecommunication protocol is insecure. The adversary processes all traffic be-tween the device and its application and trivially achieves eavesdropping,modification, insertion, and deletion of USB traffic. Additionally, she mayalso actively send bogus messages to either end and achieve impersonationattacks.

Compromised user account in the host OS

The device application is executed by a user, and uses a set of resources in thehost OS to which the user is granted access. These resources may includethe following.

• Files such as pipes, dynamically-linked libraries, software configura-tions, special files mapping to system states and components

• Environment variables

• System calls

• Memory

Compromising these resources may be achieved if the adversary has the ac-cess rights to them under the discretionary access control model in Linux, orif the adversary succeeds in an application level exploit to escalate her priv-ileges. Once a resource accessed by the device application is compromisedby the adversary, she can potentially attack the device as well as the applica-tion. The level of threats depends on the resources used by the application.Here we provide a few examples.

• A dynamically-linked library file which provides functions for hand-shaking, reading from, or writing to the device may be replaced witha malicious version. The malicious library may either passively storeall messages transmitted, or actively modify, insert, and delete mes-sages. In addition, impersonation attacks on the application can alsobe achieved by creating a bogus instance of a USB device.

23


• Environment variables, should they be used to contain configurationsof the device application, can also be altered to disrupt its execution.A poor application design might read the USB device file path storedfrom an environment variable. By changing the this value, the adver-sary can redirect its communication to a malicious USB device andachieve an impersonation attack.

• The run-time memory of an application is often a major target of soft-ware attacks. One example would be exploiting the software vulnera-bilities, such as buffer overflow, to execute arbitrary code. In the casewhere the software is bug-free, the adversary may also attach debug-gers like gdb to the runtime execution and modify the stack and heapmemory. Consider the example of the device application opening theUSB device node file using the open system call, where the argumentsare stored in the stack memory. By modifying the file path in gdb,the adversary may have the application open another device withouttriggering a warning, thereby performing a successful impersonationattack. Generally, when the adversary attaches gdb to a running ap-plication, its stack and heap memory space are open for modification,and any variables used by the application can be altered to achieve anyattack possible.

We listed some example methods which may be employed by an adversarywith the necessary access rights to compromise the components. Other re-sources such as signals or network sockets, if compromised, may also posea threat to the correct execution of the device application.

Note that in addition to attacking the device application, the adversary mayeven simply execute a malicious application of its own and communicatewith the device, thereby achieving an impersonation attack while the legit-imate device application is either blocked from accessing the device or noteven executing.

Compromised host OS kernel

The host computer OS kernel is the heart of the software that provides thedevice application an execution environment to communicate with the de-vice. The major component involved in the kernel is the USB subsystem. Ifthe kernel is compromised, any attack is possible. Here we lists some attacksthat combined will cover all those we have defined.

• The kernel module usbmon provides an interface where all USB mes-sages are stored for debugging purposes. A malicious takeover of thekernel could imply sending these privileged data to a remote storage.

• The usbcore, which handles all USB communication in Linux, can becompromised by the adversary to achieve any attack.

24


• A compromised kernel may start any user level program, including amalicious version of the device application, to communicate with a le-gitimate device, thus achieving an impersonation attack on the deviceendpoint.

• System calls provide an interface for user-space applications to interactwith the OS kernel. Should their functions be altered, the adversarymay also accomplish certain attacks. Impersonation attacks can be per-formed by modifying the open system call, which is used to open USBdevice nodes. Eavesdropping, modification, insertion, and deletionattacks can be achieved by modifying the ioctl, read, write systemcalls.

Generally, if the OS of a host computer is compromised by the adversary,any attack we have defined is possible.

Compromised host hardware

All attacks are achievable when important USB hardware is compromised.If the adversary controls a USB host controller, then she may easily eaves-drop, modify, insert, or delete messages sent to USB devices. Even forginga fake device to the OS as well as sending arbitrary messages to the deviceis possible, thus achieving impersonation attacks.

25


Adv

ersa

ryPr

esen

ceA

ttac

kA

dver

sary

Impl

emen

tati

on

Mal

icio

usD

evic

eEa

vesd

rop

Rec

ord

allb

road

cast

data

sent

from

host

Mod

ify

N/A

Inse

rtSe

ndda

taw

ith

forg

edfu

ncti

onad

dres

ses

ofot

her

devi

ces

toth

eho

stD

elet

eN

/AIm

pers

onat

eIm

pers

onat

ede

vice

:im

plem

ent

prot

ocol

toco

mm

unic

ate

wit

hho

stPC

Phys

ical

Con

nect

ion

Eave

sdro

p

Impl

emen

tm

alic

ious

hub

tom

onit

oran

dal

ter

data

Mod

ify

Inse

rtD

elet

eIm

pers

onat

eIm

pers

onat

ede

vice

:im

plem

ent

prot

ocol

toco

mm

unic

ate

wit

hap

plic

atio

nIm

pers

onat

eap

plic

atio

n:im

plem

ent

prot

ocol

toco

mm

unic

ate

wit

hde

vice

Hos

tH

ardw

are

Eave

sdro

pM

alic

ious

CPU

:Exe

cute

arbi

trar

yco

deto

achi

eve

alla

ttac

ksM

alic

ious

mem

ory

com

pone

nts:

Mon

itor

oral

ter

mem

ory

cont

ents

toco

rrup

tda

taor

exec

utab

leco

deto

achi

eve

alla

ttac

ksM

alic

ious

USB

host

cont

rolle

r:M

onit

oror

alte

rda

tato

bese

ntto

eith

eren

dpoi

nt,g

ener

ate

bogu

sda

tato

impe

rson

ate

devi

ceor

appl

icat

ion

Mod

ify

Inse

rtD

elet

eIm

pers

onat

e

Tabl

e5.

2:Im

plem

enti

ngat

tack

sex

tern

alto

the

host

com

pute

r

26


Adv

ersa

ryPr

esen

ceA

pplic

atio

nPr

ivile

geD

rive

rEx

ecut

ion

Spac

eA

ttac

kA

dver

sary

Impl

emen

tati

on

Reg

ular

Adm

inis

trat

orK

erne

l-sp

ace

Eave

sdro

pN

/Aus

erM

odif

yN

/AIn

sert

N/A

Del

ete

N/A

Impe

rson

ate

N/A

Reg

ular

user

Ker

nel-

spac

eEa

vesd

rop

1.If

devi

ceap

plic

atio

nis

runn

ing,

kill

it2.

Mod

ify

appl

icat

ion

reso

urce

s(l

ibra

ries

,env

iron

men

tva

riab

les,

confi

gura

tion

s)to

cove

rtly

eave

sdro

p,m

odif

y,in

sert

orde

lete

data

3.If

devi

ceap

plic

atio

nw

aski

lled,

rest

art

it

Mod

ify

Inse

rtD

elet

e

Impe

rson

ate

Impe

rson

atea

pplic

atio

n:re

leas

eap

plic

atio

ncl

aim

onU

SBin

terf

ace,

exec

ute

mal

icio

usap

plic

atio

n

Reg

ular

user

Use

r-sp

ace

Eave

sdro

p1.

Ifde

vice

appl

icat

ion

isru

nnin

g,ki

llit

2.M

odif

yus

er-s

pace

driv

eror

appl

icat

ion

reso

urce

s(l

ibra

ries

,env

iron

men

tva

riab

les,

confi

gura

tion

s)to

cove

rtly

eave

sdro

p,m

odif

y,in

sert

orde

lete

data

3.If

devi

ceap

plic

atio

nw

aski

lled,

rest

art

it

Mod

ify

Inse

rtD

elet

e

Impe

rson

ate

Impe

rson

ate

appl

icat

ion:

rele

ase

appl

icat

ion

ordr

iver

clai

mon

USB

inte

rfac

e,ex

ecut

em

alic

ious

appl

icat

ion

ordr

iver

Tabl

e5.

3:Im

plem

enti

ngat

tack

sas

are

gula

rus

erof

the

host

OS.

Her

ew

eha

veto

dist

ingu

ish

the

exec

utio

npr

ivile

ges

ofth

ede

vice

appl

icat

ion

and

the

exec

utio

nsp

ace

ofth

ede

vice

driv

er.

27


Attack Adversary Implementation

Eavesdrop Generic way:1. If device application is running, kill it2. Replace driver with malicious version, installmalicious USB subsystem, or modify applicationresources (libraries, environment variables,configurations) to covertly eavesdrop, modify, insertor delete data3. If the device application was killed, restart it

To eavesdrop, use usbmon

ModifyInsertDelete

Impersonate Impersonate application: release any claim on USBinterface, load malicious module or applicationImpersonate device: forge device file, load maliciousdriver

Table 5.4: Implementing attacks as the administrator (root) of the host OS.Note that since the adversary in this scenario is given root privileges, wecombine the discussion of application execution privileges and executionspace of device drivers.

28

5.3. Refined Adversary Model

5.3 Refined Adversary Model

As discussed in the previous text, security issues of USB communicationstems from the fact that various compromised components in the systemmodel allow the adversary to perform attacks in different ways. We nowestablish an adversary model for our problem to define the scope of theresearch.

The adversary as a malicious USB device or part of the physical connectionto the host computer poses a viable threat to the computer. Consideringthe limited previous work on generic USB communication security, we areinterested in finding a solution to this problem.

For adversaries on the host computer with access to the OS kernel (this in-cludes adversaries in user space with root privileges), solutions already existto provide isolated execution environments for software such that applica-tions can be protected from attacks from the OS. For solutions employingTCB minimization, the isolated execution environment would have to in-clude any resource from the OS that is accessed by the device application,which significantly increases the code size of the isolated environment andtherefore contradicts the original intent of minimizing trusted code size. Ad-ditionally, all USB software would require modification of its source code tomake use of modern isolated execution technologies, which is impracticalto implement on commodity USB products. On the other hand, for isolatedexecution based on hypervisors, the entire OS of the host computer has tobe re-installed, which is also infeasible to realize. To provide a solution forgeneric USB devices, device applications, and the use case in the generalsystem model, we therefore assume that the OS of the host computer istrusted and is not compromised by the adversary. This allows us to focusour research on the security of USB communication.

We focus on a refined adversary model to design our solution. The adver-sary we consider in this thesis is composed of the following.

• Malicious hardware. The adversary may control malicious USB de-vices, USB hubs, cables, and even the USB host controller on the hostcomputer.

• Malicious software with regular user privileges with access rights tocertain secure-agnostic USB devices and device applications.

29

Chapter 6

Design of a Secure USBCommunication Stack

We introduce the solution to our problem by first specifying the require-ments based on our refined adversary model, followed by the design whichfulfils them. Finally, we analyse the security of our architecture and dis-cusses how it prevents various attacks under our adversary model.

6.1 Requirements

We first identify the requirements for our design of a secure communicationenvironment against the adversary model mentioned in 5.3.

Requirement 1 The solution should ensure authorized access to the device fromthe host computer.

This requirement is essential to prevent the software adversary from com-promising the communication between the device and application.

Requirement 2 The solution should provide a secure communication channel whichprovides message confidentiality and integrity to messages that are exchanged be-tween the device and application.

The fulfilment of this requirement prevents the hardware adversary fromcompromising the communication between the device and the device ap-plication to achieve eavesdropping, modification, insertion, deletion, andimpersonation attacks.

Requirement 3 The device and the device application are not changed.

Considering the infeasibility of modifying the hardware of the device andsoftware of the device application for generic USB products, the designshould provide the security guarantees described in the first two require-ments independently from the USB product implementation.

30

6.2. Design

Figure 6.1: Solution design. Green marks the USB device access control mod-ule (and its associated software) which uses existing access control mecha-nisms in the OS to allow only authorized device applications to access thedevice. Blue components belong to the secure USB bridge solution which en-sures communication channel security. Red boxes represent trusted regionsin the environment.

6.2 Design

To fulfil the requirements, our design introduces various components intothe original system model, as shown in Figure 6.1. The design consists ofthe following two parts.

• USB Device Access Control Module. The USB device access controlmodule uses existing DAC, MAC, and software integrity checks in thehost OS to control access to USB devices from software applications.

• Secure USB Bridge. The secure USB bridge, which establishes a sharedsecret with the host computer and communicates with the host OS toprovide message confidentiality and integrity over the communicationchannel. The host OS uses a secure USB bridge pairer software to es-tablish the shared secret with the bridge, and communicates with thebridge securely using a secure USB relay module.

31

6.2. Design

MoonBook

Original/unchanged protocol

Secure communication

Authorized and unaltereddevice applicationUSB Device

Secure USB Bridge Host Computer

Figure 6.2: Illustration of the secured communication channel between thebridge and host computer.

To make use of the solution, the user now interacts with the device throughthe application in the following steps.

1. Optionally, the user installs the device driver and the device appli-cation using the secure USB software installer, which measures thevarious features of the device application such as the hash of the exe-cutable file.

2. The user attaches the bridge to the host computer.

3. The secure USB bridge pairer is executed to establish a shared secretbetween the bridge and relay through a key exchange protocol. Aftersuccessful pairing, the bridge now waits for the device to be connected.

4. The user attaches the device to the bridge.

5. The bridge enumerates the device to obtain basic device informationand exposes a USB instance containing the device information to theconnected host computer.

6. The user starts the device application, which is granted access by theUSB device access control module based on a series of access controlchecks and integrity verifications.

7. The user uses the device application to communicate with the device,during which the bridge and relay encapsulates communication be-tween the USB subsystem and the bridge in a secure channel.

The resulting secured communication environment is illustrated in Figure6.2.

We now describe how the USB device access control module (control module)and the secure USB bridge (bridge) are designed.

32

6.2. Design

6.2.1 USB Device Access Control Module

To avert attacks from malicious software, we propose a solution to enforceaccess control policies on the host computer OS based on whitelisting. Thesolution stores information about programs which are authorized to accessUSB devices through an initial setup step, and verifies the program stateduring launch-time. This prevents unauthorized or altered software fromaccessing the USB device.

The existing discretionary access control (DAC) in the OS is insufficient forpreventing malicious software from accessing USB devices, since an applica-tion access to system resources is granted/denied based solely on the accessrights associated with the user. As a result, mandatory access control (MAC)has to be introduced to restrict access of applications to only a subset of allresources based on predefined policies. In Linux, implementations of MACinclude as AppArmor [38], SELinux [39], TOMOYO Linux [49], and SMACK[50], which are all part of the Linux kernel. Linux MAC implementationsmake use of the Linux Security Modules [51] framework to restrict resourceaccess from applications based on access policy rules, either predefined dur-ing installation or added by administrators.

In addition to MAC, the USB device access control module also verifiesthe integrity of applications before they access resources in the OS. Variousapproaches for software whitelisting and fail-stop mechanisms have beenwidely investigated and designed [25, 26, 27, 28]. These solutions allow theexecution of an application only if the integrity of its executable is verified.

To provide a tighter access control, the control module combines the well-established use of DAC, MAC and integrity fail-stop mechanisms. A SecureUSB Software Installer registers an application to a USB device which it is al-lowed to access and measures the application files and system environmentfor future integrity verification. As an example, measurement of files andsystem environment may include hashes of files or certificates. The regis-tration and application information is stored in an access control databasewhich is only accessible by the kernel. Whenever an application accesses aUSB device, the control module fetches the its registered information in thedatabase and allows access only if all of the following conditions are met.

• The user account is granted access to the USB device.

• The device application is granted access to the USB device.

• The integrity of the device application is verified.

Under this mechanism, it is therefore important to identify outstanding fea-tures of device software such that a comprehensive measurement of its legit-imate state can be obtained for integrity verification. This is orthogonal tothis thesis and is therefore considered as future work.

33

6.2. Design

6.2.2 Secure USB Bridge

To achieve communication security, we encapsulate the original communi-cation protocols between the device and application in a secure channel.Specifically, we establish a secure channel in their communication to provideconfidentiality and integrity. In addition, the secure communication chan-nel does not modify the device and application, according to Requirement3. Therefore, we introduce the secure USB bridge solution which actuallyconsists of the following entities.

• The Secure USB Bridge, referred to as the bridge, which is connectedbetween the USB device and the host computer

• A software module called the Secure USB Relay, later referred to as therelay, on the host computer

Since many USB devices, such as mass storage or digital imaging devices,communicate with the host computer with high data rates in the order ofa few megabytes per second, we adopt symmetric encryption to securedata communication. This requires a shared secret known only betweenthe bridge and relay, and we therefore introduce an initialization phase forsecret establishment.

A software module called the Secure USB Bridge Pairer, later referred toas the pairer, is used to establish a shared secret between the relay andthe bridge using key exchange protocols, such as the Diffie-Hellman keyexchange [52]. To prevent adversaries from disrupting the protocol (e.g.,man-in-the-middle attacks), messages exchanged between the bridge andrelay must be verified for their authenticity. This can be achieved, for exam-ple, using digital signatures based on public key cryptography or password-authenticated key exchange protocols. The sequence diagram for the pairingprocess is shown in Figure 6.3.

After a shared secret is established between the bridge and the relay, theactual USB communication between the device and application is enabled.The same key is used for secure communication of any devices that may beattached to the bridge after the key exchange. When the device is sendingdata, the bridge encrypts and sends it to the relay. Upon reception, therelay on the host computer decrypts the ciphertext, verifies its integrity andforwards the resulting plaintext to the device application. Similarly, whenthe device application sends data to the device, the relay encrypts the dataand sends it to the bridge. The bridge decrypts the ciphertext, verifies itsintegrity, and forwards it to the USB device in its original plaintext format.

The bridge should be directly connected to the device to alleviate concerns ofmalicious intermediate hardware such as USB sniffers. A sequence diagramillustrating the communication between the device and application after theadding the bridge and the relay is shown in Figure 6.4.

34

6.2. Design

Device Secure Bridge USB Subsystem Driver/Application

Attach

Enumerate

Bridge info

Key generation

Key exchange

Key Exchange ProtocolKey Exchange Protocol

Shared keyDerive key

Shared key

PairingPairing

Figure 6.3: Pairing process between the enhanced host OS and the securebridge. After pairing, a shared secret is generated for efficient secure com-munication.

35

6.2. Design

Device Secure Bridge USB Subsystem Driver/Application

Attach

Query

Device info

Attach device

Encrypted query

Encrypted device info

Device connected

Request

Encrypt

Encrypted request

Decrypt, verify

Request

Reponse

Encrypt

Encrypted response

Decrypt, verify

Response

Secure Message ForwardingSecure Message Forwarding (iterates until device disconnection)

Figure 6.4: Secure communication between the device and an authorizeddriver/application. Here the security of messages are implied by the sharedsecret established between the secure bridge and the host OS during thepairing process.

36

6.3. Security Analysis of Our Design

6.3 Security Analysis of Our Design

Our USB device access control module aims at preventing the software ad-versary, discussed in 5.3, from achieving any of the the attacks defined in5.1. The secure USB software installer measures the device application dur-ing installation. The control module makes use of existing solutions forDAC, MAC, and software integrity verification to prevent unauthorized ac-cess of the device from an unregistered or altered device application. Thesesecurity features fulfil Requirement 1.

We now discuss the secure USB bridge design to aim at fulfilling Require-ment 2. The secure key exchange protocol ensures that no entity may derivethe shared key without the knowledge of the secret on either the bridge orthe host. Additionally, the shared key is secure against man-in-the-middle at-tacks since the host and bridge verify the authenticity of the messages whichthey receive during the pairing process. As a result, the encrypted commu-nication channel protects against passive adversaries from obtaining mean-ingful information by eavesdropping. The integrity checks of decryptedmessages performed by the bridge and relay further prevents insertion andmodification attacks from an active adversary. Impersonation attacks beingan instance of insertion attacks, are also prevented.

However, our solution does not resolve insertion or impersonation attacksfrom the device side of the bridge, which may require techniques such asdevice identification. Minimally, we need to be able to write an identifierto the device, which is not supported by many USB devices and thereforeremains a limitation of our solution.

For deletion attacks, the adversary in the secure communication channelmay still be able to deny the transmission of encrypted messages. For ex-ample, a malicious hub may simply refuse to route the encrypted messagesto the bridge or the host. Our solution therefore does not address denial-of-service attacks by the adversary, though such attacks would result in thedisruption of communication which is often noticeable by the user.

37

Chapter 7

Implementation and Evaluation

Given that there has already been significant research on software security,as discussed in Chapter 3, we focus on realizing the design of the secureUSB bridge. Realizing such a channel in a generic way is a challenge be-cause there are several types of USB devices each with their own speed andperformance requirements. Moreover, even devices of the same class differwith one another in the way they define interfaces and endpoints.

We implemented a prototype implementation of the secure USB bridge us-ing the BeagleBone [53] development board with an ARM Cortex-A8 [54]microprocessor produced by Texas Instruments [55]. The board consists ofa USB controller supporting Direct Memory Access (DMA) and exposes aUSB host-side port to connect to USB devices as well as a USB device-sideport which connects to a USB host such as a computer. By connecting thehost-side port to the USB device and the device-side port to the computerrunning the device application, the development board can act as a proxy forthe USB device which processes the communicated data. We implementeda bare-metal software module using the StarterWare library [56] (i.e., it doesnot run on an OS) on the development board to forward data between thedevice and the host computer.

For the host computer, we use a Lenovo ThinkPad T420 laptop runningUbuntu 11.10, with specifications listed in Table 7.1. We implement a kernelmodule on the host OS to act as the relay which communicates with thebridge.

For cryptographic operations during implementation, we used PolarSSL [57]for its compatibility with bare-metal platforms.

The following sections discuss how key exchange and message encryptionare implemented.

38

7.1. Key Exchange

Lenovo ThinkPad T420

CPU Intel Core i7-2620M @ 2.7GHzMemory 4GBOS Ubuntu Linux 11.10Kernel version 3.0.0.26-generic-pae

Table 7.1: The host computer specifications

7.1 Key Exchange

For the key exchange phase, we adopt the Diffie-Hellman key exchangeprotocol with RSA signatures (DHE-RSA [58]) for the messages transferredbetween two parties. The bridge and the relay each generates a 1024-bitRSA keypair. The bridge is given the public key of the relay; similarly, therelay is given with the public key of the bridge. This allows the bridge andthe relay to verify the authenticity of the messages exchanged during theDiffie-Hellman key exchange process.

The bridge, upon attachment to the host computer, first exposes itself as aUSB device with one configuration containing a bridge handshake interface.The bridge handshake interface consists of one endpoint for IN type bulktransfers and one endpoint for OUT type bulk transfers. Since USB devicesare passive, the bridge waits for the host computer to initiate the pairingprocess.

On the host side, we implement a user-space program which initiates thepairing process. This program is executed with root privileges to prevent ac-cess from software adversaries with as defined in 5.3. The program proceedsas follows.

1. Generating Diffie-Hellman parameters.

• The modulus prime number p

• The generator prime number g

• A randomly chosen secret integer a

• The key contribution A = ga mod p

2. Obtain hash hA of p|g|A using SHA1. 1

3. Sign hA with its private key to obtain sA.

4. Send p|g|A|sA to the USB bridge handshake interface OUT endpoint.

1The | symbol is the concatenation operation.

39

7.1. Key Exchange

USB Bridge Host Computer

Generate DH parameters01 p, g, a, A = ga mod psA = sign(SHA1(p|g|A))

p, g, A, sA

Verify sAGenerate DH parameters01 b, B = gb mod psB = sign(SHA1(B))

B, sB

Verify sB

S = Ab mod p S = Ba mod p

Figure 7.1: An example sequence of successful pairing under our imple-mented DHE-RSA protocol for key exchange between the bridge and thehost computer.

5. Obtain the bridge key contribution B′ and the signature of its hash s′Bfrom its response.

6. If the authenticity of the Diffie-Hellman contribution passes verifica-tion, derive the shared secret Sa = (B′)a mod p. Otherwise reportfailure and terminate execution.

The bridge passively waits for the data to be sent into its OUT endpoint. Itproceeds as follows.

1. Wait until data is received through the OUT endpoint.

2. Unpack the message to obtain p′, g′, A′, and s′A.

3. Obtain hash h′A of p′|g′|A′ using SHA1.

4. If the signature s′A is verified with the public key of the host, proceed.Otherwise, the message is discarded and the bridge returns to Step 1.

5. Generate its Diffie-Hellman parameters.

• A randomly chosen secret integer b.

• The key contribution B = (g′)b mod p′.

• Obtain hash hB of B using SHA1.

40

7.2. Message Encryption

• Sign hB with its private key to obtain sB.

• Place B|sB in the buffer of the USB bridge handshake interface INendpoint for the host to read.

• Derive the shared secret Sb = (A′)b mod p′.

If a key exchange session is successful, then

p′ = pg′ = gA′ = A = ga

B′ = B = gb

which implies an identical shared secret key is established.

Sb = (A′)b mod p′

= gab′ mod p= (B′)a mod p= Sa

As an example, a successful execution of the key exchange protocol duringthe bridge-relay pairing process is illustrated in Figure 7.1. Failures in datainterpretation or signature verification would reset the protocol state of boththe bridge and relay.

7.2 Message Encryption

Based on Figure 6.4, after establishment of a shared secret, the bridge waitsfor a USB device to connect to its host-side port. When a device is connected,the bridge enumerates the device and obtains a copy of its descriptors. Thebridge then activates its device instance to the connected host computer,providing (upon request) the copy of descriptors appended with an addi-tional bridge interface to each configuration. The appended bridge interfaceconsists of a set of bulk IN/OUT endpoints, similar to that during bridge-relay key-exchange, and is used for encrypted message transmission andreception. As a result, after the host computer enumerates the new deviceinstance exposed by the bridge, the actual USB device information is passedto the host. This enables successful detection of the original device and ex-ecution of its driver or application. To avoid inadvertent communicationbetween host USB drivers and the bridge interface, we specify the USB classof this interface as Vendor Specific (0xFF in Table 2.1).

41


As discussed in Section 2.2, software which communicates with the USB de-vice ultimately invokes the usb submit urb kernel function in the usbcore

module to send or receive messages in URB data structures. In our solu-tion, the requests for USB data transfer are detected by hooking calls tousb submit urb using jprobes [59]. The jprobes hook function manipu-lates the data buffer, endpoint information, transmission type in the URBstructure to redirect traffic to communicate with the bridge interface. Thisreduces the risk of the adversary distinguishing the traffic data based on itsendpoint addresses and transfer types.

Our implementation currently redirects control transfers after enumeration,and any IN or OUT requests sent to device endpoints. Since the requestto any endpoint of the USB device is routed to the bridge interface, theredirection logic appends the destination information and transfer type ofthe original URB as header information to the data sent to the bridge. Thefollowing describes a simple message forwarding protocol we implementon the jprobes relay and the bridge for each type of transfer. The format ofdata sent to the bridge for each type of transfer are shown in Figure 7.2.

When encrypting the message, we apply either RC4 or AES (in CTR mode)encryption to the plaintext data, which consist of essential header informa-tion prepended to the original USB message and a SHA1-128 hash of theentire message. The decryption process consists of decrypting the cipher-text and verifying its hash. Messages with invalid hashes after decryptionare ignored.

• Control transfers. Recall in Section 2.1.4 that a control transfer consistsof a setup packet and an associated buffer field containing data to besent to or received from the device. When the relay detects the controltransfer, it proceeds as follows.

1. Create a new data buffer, containing the concatenation of thesetup packet and the data buffer, prepended with header infor-mation.

2. Encrypt the data buffer on the host and send it to the bridge OUT

endpoint.

3. Alter the current URB to request data from the bridge IN end-point.

4. Decrypt received data on the host and place it into the originalURB data buffer

5. Invoke the URB completion handler originally specified by thedriver.

42


The bridge, processes these control transfers as follows.

1. Decrypt the relay request and issue an actual control transfer re-quest to the device.

2. Encrypt the data returned by the device and place them in thebuffer of the bridge OUT endpoint.

• IN token transfers. In the case with IN token transfers, the relay shouldalso indicate to the bridge which endpoint of the device is addressedby the URB. The relay takes the steps similar to handling control trans-fers, as listed below.

1. Create a new data buffer which consists of the header information,appended by the size of the data buffer the URB is requesting (inbytes).

2. Encrypt the data buffer on the host and sent it to the bridge OUT

endpoint.

3. Alter the current URB to request data from the bridge IN end-point.

4. Decrypt received data on the host and place it into the originalURB data buffer.

5. Invoke the URB completion handler originally specified by thedriver.

The bridge handles IN requests accordingly.

1. Decrypt the relay request to obtain the device endpoint and issuean IN request on the specified IN endpoint of the device.

2. Encrypt the data returned by the device and place them in thebuffer of the bridge OUT endpoint.

• OUT token transfers. Sending data to devices involves a simpler stepfor the relay since no data is returned from the device. The relay takesthe following steps.

1. Create a new data buffer which consists of the header information,appended by the size of the data buffer, and then the data to besent to the device.

2. Encrypt the new data buffer and send it to the bridge OUT end-point.

43

7.3. Preliminary Evaluation

(a) Control transfers consisting of a SETUP request

(b) IN request

(c) OUT request

Figure 7.2: Packaged data sent by the relay to the bridge for each type ofURBs intercepted. ep represents the designated endpoint address. In thecase with IN requests, an additional parameter t, representing the type oftransfer (bulk, isochronous, interrupt) is also specified as additional infor-mation for the bridge.

3. After transmission is confirmed from the host controller driver,invoke the URB completion handler originally specified by thedriver.

The bridge proceeds as follows.

1. Decrypt the relay request and send the data to the endpoint spec-ified by the header information.

With each URB request generated/modified, the relay assigns/substitutescustom completion handler functions which perform clean-up and triggerthe original driver completion function. When handling IN request comple-tions, the relay places the decrypted original data from the device into theoriginal buffer allocated by the driver.

To prevent disrupting USB devices which are not connected to the host viathe bridge, the relay module only intercepts URB requests which are sent toa predefined list of devices which are known to be connected through thebridge.

7.3 Preliminary Evaluation

Given the implementation of the prototype bridge and relay, we providea preliminary evaluation of its performance to observe the communicationoverhead it introduces. We ran benchmarks using two devices: a USB bulkdevice which contains a source and a sink for data transmission, and a USBflash drive.

44


Metrics

During communication we measure the time it takes for the software applica-tion to transfer data. In addition, time measurements of data transmissionsare converted to throughput whenever applicable, which is calculated as:

throughput =data size

transfer time

We also measure the time the relay spends in processing usb submit urb

requests, which represents the time spent on cryptographic operations, re-ceiving the response, and necessary data processing. To get an insight intothe communication overhead caused by the bridge, we measure time on thebridge when it processes a request from the relay. This involves host-sideI/O, device-side I/O and cryptographic operations.

Measurement Setup

We measured the performance of our implementation using the above men-tioned metrics in the following four scenarios.

• Original connection without bridge or relay

• Connection through the bridge and relay with no encryption

• Connection through the bridge and relay with SHA1-RC4

• Connection through the bridge and relay with SHA1-AES

In each scenario, we tested our implementation using the bulk device (referto Section 7.3.1) and flash drive (refer to Section 7.3.2). Additionally, weenabled data and instruction cache on the BeagleBone, as well as its DMAfunctionalities when communicating with the device. However, the Beagle-Bone DMA features between itself and the host computer is not enabled dueto unstable DMA implementation in StarterWare [60, 61, 62].

7.3.1 Bulk Device

We implemented a USB bulk device consisting of an interface with two end-points: one OUT endpoint as a sink which receives any data sent from thehost, and one IN endpoint as a source which continuously sends bytes ofzeros to the host upon request. The device is implemented as a user-spaceUSB gadget under the Linux gadget framework [63] and runs on a Freescalei.MX53 Quick Start Board [64].

From the host side, we wrote a simple program which reads or writes datato or from the bulk device using libusb [11] and measures the transfertime. For our experiments, we have conducted 1000 test iterations for eachindividual setting.

45


Figures 7.3 and 7.4 shows the performance of read and write operations forvarious data sizes. In both cases we can observe that throughput saturatesfor data transfer sizes larger than 8KB. For example, when the bridge is justforwarding plaintext and has device-side DMA and cache enabled, the sat-urated throughput for the reading and writing is 3.8MB/s and 2.5MB/s re-spectively. In addition, the throughput decreases with the use of encryptionalgorithms (RC4 and AES), which is consistent with literature [65]. Morespecifically, throughput is highest for direct connection, followed by plain-text message forwarding through the bridge and forwarding with usingSHA1-RC4 and SHA1-AES encryption. For example, in the case with SHA1-RC4 and SHA1-AES encryption, the throughput for read operations is abouthalf and one fourth of that with direct connection, respectively. In the casewith write operations, the drop in performance appears more drastic, dueto the asymmetric performance of the bridge when communicating with thehost computer. Specifically, the bridge does not use DMA to transfer datawith the host, thereby relying on the CPU and its software code to handledata transmissions; however, the code used to transfer and receive data areimplemented differently and therefore produces different performance. Fig-ures 7.5 through 7.7 shows the time measured on the bridge for reading andwriting 16KB of data from and to the bulk device, from which we observethe bridge taking significantly more time in receiving data from the hostcomputer.

During the implementation of the solution, we noticed significant improve-ment of the bridge implementation on the BeagleBone after enabling data/in-struction cache for the microprocessor and DMA for the USB controllerwhen communicating with the device. Comparisons of various cache andDMA configurations are shown in Figures 7.8 and 7.9 for plaintext bridging,Figures 7.10 and 7.11 for SHA1-RC4 encrypted bridging, and finally Figures7.12 and 7.13 for SHA1-AES encrypted bridging. In all benchmark resultsfor write operations, the improvement after enabling BeagleBone USB DMAwith the device can not be clearly observed due to the bottleneck introducedby the bridge when receiving data from the host computer without bridge-to-host DMA.

46


0 2 4 6 8 10 12 14 16 180

1

2

3

4

5

6

7

8

9

Tim

e (

ms)

Data Size (KB)

No Bridge

Bridge Plaintext

Bridge SHA1−RC4

Bridge SHA1−AES

(a) Time

0 2 4 6 8 10 12 14 16 180

2

4

6

8

10

12

14

16

Thro

ughput (M

B/s

)

Data Size (KB)

No Bridge

Bridge Plaintext

Bridge SHA1−RC4

Bridge SHA1−AES

(b) Throughput

Figure 7.3: Comparison of perceived read performance for various bridgesetups on the bulk device. Here we can observe the impact of our solutionimplementation, in which a RC4 and AES encryption schemes reduce theperformance more drastically.

47


0 2 4 6 8 10 12 14 16 180

1

2

3

4

5

6

7

8

9

Tim

e (

ms)

Data Size (KB)

No Bridge

Bridge Plaintext

Bridge SHA1−RC4

Bridge SHA1−AES

(a) Time

0 2 4 6 8 10 12 14 16 180

2

4

6

8

10

12

14

16

Thro

ughput (M

B/s

)

Data Size (KB)

No Bridge

Bridge Plaintext

Bridge SHA1−RC4

Bridge SHA1−AES

(b) Throughput

Figure 7.4: Comparison of perceived write performance for various bridgesetups on the bulk device. Similar to Figure 7.3, the performance is affectedby the encryption scheme chosen for secure communication. We also noticethe overhead of receiving data from the host inherent in the StarterWareimplementation, causing an overall decrease in performance.

48


OFF, OFF OFF, ON ON, OFF ON, ON0

5

10

15

20

25

30

Cache, DMA

Tim

e (

ms)

Bridge −> PC

Device −> Bridge

Processing

(a) Read 16KB


5

10

15

20

25

30

35

Cache, DMA

Tim

e (

ms)

PC −> Bridge

Bridge −> Device

Processing

(b) Write 16KB

Figure 7.5: Comparison of bridge overhead for various settings ofcache/DMA features on the bulk device. The performance is benchmarkedwith reading or writing 16KB of data without encryption. Enabling cachesignificantly reduces cryptographic operations while enabling DMA reducescommunication overhead between the bridge and the device.

49



20

40

60

80

100

120

Cache, DMA

Tim

e (

ms)

Bridge −> PC

Device −> Bridge

Processing

Crypto

(a) Read 16KB


10

20

30

40

50

60

70

80

90

100

Cache, DMA

Tim

e (

ms)

PC −> Bridge

Bridge −> Device

Processing

Crypto

(b) Write 16KB

Figure 7.6: Comparison of bridge overhead for various settings ofcache/DMA features on the bulk device. The performance is benchmarkedwith reading or writing 16KB of data with SHA1-RC4 encryption. Enablingcache significantly reduces cryptographic operations while enabling DMAreduces communication overhead between the bridge and the device.

50



50

100

150

200

250

300

350

Cache, DMA

Tim

e (

ms)

Bridge −> PC

Device −> Bridge

Processing

Crypto

(a) Read 16KB


50

100

150

200

250

300

350

Cache, DMA

Tim

e (

ms)

PC −> Bridge

Bridge −> Device

Processing

Crypto

(b) Write 16KB

Figure 7.7: Comparison of bridge overhead for various settings ofcache/DMA features on the bulk device. The performance is benchmarkedwith reading or writing 16KB of data with SHA1-AES encryption. Enablingcache significantly reduces cryptographic operations while enabling DMAreduces communication overhead between the bridge and the device.

51


0 2 4 6 8 10 12 14 16 180

5

10

15

20

25

30

35

40

Tim

e (

ms)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(a) Time

0 2 4 6 8 10 12 14 16 180

1

2

3

4

5

6

7

Thro

ughput (M

B/s

)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(b) Throughput

Figure 7.8: Comparison of perceived read performance for variouscache/DMA features on the bulk device when the bridge is forwarding datawithout encryption. We can observe that the main factor which impactsperformance is caching.

52


0 2 4 6 8 10 12 14 16 180

5

10

15

20

25

Tim

e (

ms)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(a) Time

0 2 4 6 8 10 12 14 16 180.5

1

1.5

2

2.5

3

3.5

Thro

ughput (M

B/s

)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(b) Throughput

Figure 7.9: Comparison of perceived write performance for variouscache/DMA features on the bulk device when the bridge is forwarding datawithout encryption. We can observe that the main factor which impactsperformance is caching.

53


0 2 4 6 8 10 12 14 16 180

20

40

60

80

100

120

Tim

e (

ms)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(a) Time

0 2 4 6 8 10 12 14 16 180

0.5

1

1.5

2

2.5

3

3.5

4

4.5

Thro

ughput (M

B/s

)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(b) Throughput

Figure 7.10: Comparison of perceived read performance for variouscache/DMA features on the bulk device when the bridge is forwarding datawith SHA1-RC4 encryption. We can observe that the main factor whichimpacts performance is caching.

54


0 2 4 6 8 10 12 14 16 180

5

10

15

20

25

Tim

e (

ms)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(a) Time

0 2 4 6 8 10 12 14 16 180.5

1

1.5

2

2.5

3

Thro

ughput (M

B/s

)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(b) Throughput

Figure 7.11: Comparison of perceived write performance for variouscache/DMA features on the bulk device when the bridge is forwarding datawith SHA1-RC4 encryption. We can observe that the main factor whichimpacts performance is caching.

55


0 2 4 6 8 10 12 14 16 180

50

100

150

200

250

300

350

Tim

e (

ms)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(a) Time

0 2 4 6 8 10 12 14 16 180

0.5

1

1.5

2

2.5

Thro

ughput (M

B/s

)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(b) Throughput

Figure 7.12: Comparison of perceived read performance for variouscache/DMA features on the bulk device when the bridge is forwarding datawith SHA1-AES encryption. We can observe that the main factor whichimpacts performance is caching.

56


0 2 4 6 8 10 12 14 16 180

5

10

15

20

25

Tim

e (

ms)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(a) Time

0 2 4 6 8 10 12 14 16 180.5

1

1.5

2

2.5

3

Thro

ughput (M

B/s

)

Data Size (KB)

CACHE OFF, DMA OFF

CACHE OFF, DMA ON

CACHE ON, DMA OFF

CACHE ON, DMA ON

(b) Throughput

Figure 7.13: Comparison of perceived write performance for variouscache/DMA features on the bulk device when the bridge is forwarding datawith SHA1-AES encryption. We can observe that the main factor whichimpacts performance is caching.

57


7.3.2 Flash Drive

While the bulk device gives us information about the raw data rate, mostUSB devices use additional protocols to transfer data. For example, USBmass storage devices adopt SCSI [66] commands to transfer files. In orderto understand the performance of our solution in the context of these com-modity products. In our evaluation, we have chosen to evaluate our solutionusing a USB flash drive for its widespread usage.

We benchmark our bridge and relay solution by copying files between aUSB flash drive using dd. The following results are obtained with 100 testiterations for each individual setting. To overcome performance variationswhen transferring small files, we copied large files between the host and theflash drive to obtain stable measurements.

We benchmarked reading a 5MB file from the flash drive to the host com-puter. The average performance is shown in Figure 7.14. On average, oursolution reduces the throughput from 24.66MB/s down to 4.32MB/s and2.27MB/s for secured communication using SHA1-RC4 and SHA1-AES re-spectively.

For file writing operations, we performed tests with writing a 15MB file,and the results are shown in Figure 7.15. As observed during the bench-mark with the bulk device, the write performance is affected more by theoverhead of the bridge receiving data from the host than by various encryp-tion algorithms. The average throughput drops from 6.64MB/s using directconnection down to 1.71MB/s and 1.28MB/s for SHA1-RC4 and SHA1-AESrespectively.

The asymmetric performance in data transmission between the bridge andthe host is caused by our implementation of the bridge, and can be con-firmed by profiling the host computer kernel using sysprof [67], obtainedfrom reading and writing 1GB of data while the bridge is forwarding plain-text. Here we focus on the usb stor control thread kernel thread used bythe USB storage driver to transfer data, as shown in Figure 7.16. The kernelfunction spends more time on the function usb sg wait, which loops untilthe host controller driver reports completion of transfer, when writing to thedevice [68].

We also measure the time spent on the bridge for both reading and writ-ing files, as shown in Figure 7.17. Additionally, a best performance poten-tially offered by the BeagleBone hardware is also estimated based on variousbenchmarks of various software efficiently making use of the underlyinghardware features such as DMA and cryptographic acceleration [69, 70] asshown in Table 7.2. Figure 7.18 shows the time spent on kernel module act-ing as the relay. Here we clearly observe that most time is spent on datatransfer. The increased time with SHA1-RC4 and SHA1-AES encryption al-

58


Reading USB device 22.35 MB/sWriting USB device 19.56 MB/sRead from USB host 16.77 MB/sWrite from USB host 15.15 MB/s

AES 25.35 MB/sSHA1 54.54 MB/s

Table 7.2: Highest achievable speeds provided by the BeagleBone when op-timized software libraries make use of hardware features such as DMA andcryptographic accelerations [69, 70].

gorithms is attributed to the time spent waiting for bridge operation. Basedon these observations, the communication efficiency between the bridge andhost could be improved with proper use of DMA on the BeagleBone bare-metal software.

59


0

0.5

1

1.5

2

2.5

Scheme

Tim

e (

s)

DirectBridge Plaintext

Bridge SHA1−RC4Bridge SHA1−AES

(a) Time

0

5

10

15

20

25

Scheme

Th

rou

gh

pu

t (M

B/s

)



(b) Throughput

Figure 7.14: Comparison of perceived read performance for 5MB with vari-ous bridge setups on the flash drive.

60


0

2

4

6

8

10

12

Scheme

Tim

e (

s)



(a) Time

0

1

2

3

4

5

6

7

8

Scheme

Th

rou

gh

pu

t (M

B/s

)



(b) Throughput

Figure 7.15: Comparison of perceived write performance for 15MB withvarious bridge setups on the flash drive.

61


Read Write0

20

40

60

80

100

120

Pe

rce

nta

ge

of

tim

e t

ake

n in

usb

_sto

r_co

ntr

ol_

thre

ad

(%

)

other operations in usb_stor_control_thread

usb_sg_wait

Figure 7.16: Kernel profiling results for the kernel functionusb stor control thread when the host computer reads from andwrites to the USB flash drive through the bridge which forwards datawithout encryption. Waiting for the bridge to respond takes up more timefor the host when it is writing data.

62


Plaintext SHA1−RC4 SHA1−AES Optimal SHA1−AES0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

Tim

e t

o r

ea

d 5

MB

(s)

Bridge −> PC

Device −> Bridge

Processing

Crypto

(a) Read 5MB

Plaintext SHA1−RC4 SHA1−AES Optimal SHA1−AES0

2

4

6

8

10

12

Tim

e t

o w

rite

15

MB

(s)

PC −> Bridge

Device −> Bridge

Bridge −> Device

Crypto

(b) Write 15MB

Figure 7.17: Comparison of bridge overhead for accessing flash storage invarious encryption schemes. We also add an estimated best performancewhich may be obtained on the BeagleBone in the SHA1-AES encryptionscheme.

63


No Bridge Bridge Plaintext Bridge SHA1−RC4 Bridge SHA1−AES0

0.5

1

1.5

2

2.5T

ime to r

ead 5

MB

(s)

Processing

TransferCrypto

(a) Read 5MB

No Bridge Bridge Plaintext Bridge SHA1−RC4 Bridge SHA1−AES0

2

4

6

8

10

12

14

Tim

e to w

rite

15M

B (

s)

Processing

TransferCrypto

(b) Write 15MB

Figure 7.18: Comparison of the kernel module overhead for accessing flashstorage in various encryption schemes. We also provide the original over-head from issuing USB requests via usb submit urb without the bridge so-lution.

64


7.3.3 Summary

The preliminary benchmark result shows a significant performance impactby the secure USB bridge due to the following reasons.

• When the bridge forwards data transfers securely, as designed in Chap-ter 6, it must first receive the data, process it, and sent it to either thedevice or the host computer. The overhead of receiving data and send-ing it without parallelism implies an 50% penalty in terms of perfor-mance.

• Our implementation on the BeagleBone does not make full use of itshardware capabilities such as cryptographic acceleration and DMA.

Our prototype implementation is therefore not suitable for securely encapsu-lating high speed USB communication. However, we notice that prototype isstill useful for device which require low bandwidth, such as USB keyboards,mouse, and even simple healthcare devices which sends or receives datain the size of a few bytes. With specialized hardware design such as fieldprogrammable gate arrays (FPGA), dedicated cryptographic processors andfaster USB communication hardware, the secure USB bridge may be imple-mented to reduce performance penalty.

65

Chapter 8

Conclusion and Outlook

In this thesis, we investigated security threats surrounding USB devices dur-ing their interaction with a host computer running a Linux OS. We focusedon a scenario in which users interact with these devices through softwareapplications either provided by the device manufacturers or built into theOS. We identified various attack vectors and their feasibility based on thethe compromise of various software or hardware components of the USBstack. These attacks allow the adversary to eavesdrop, insert, modify, anddelete data transferred over the USB communication channel; it also allowsthe adversary to impersonate the device or its application. Since device ap-plications often rely on many resources provided by the OS, we focus ondevising a solution that does not require significant modifications of the OS,such as hypervising. We therefore restrict our problem by defining an ad-versary model in which the adversary may compromise a user account insoftware or control malicious hardware in the USB communication channel.

Based on the above chosen adversary model, we provided a solution con-sisting of two parts: the USB device access control module and secure USBbridge. The USB device access control module employs existing DAC, MACand software integrity checking mechanisms to ensure that only authorizedand unaltered device applications may access the USB device. The secureUSB bridge acts as a proxy for the USB device and secures the communica-tion channel by encrypting and verifying the integrity of the original com-munication with a software module in the host OS. With the exception ofdeletion attacks, our secure USB bridge design prevents eavesdropping, in-sertion, and modification attacks between the bridge and the host computer.On the other hand, the solution does not protect against malicious devicesconnected to the host computer through the bridge.

Since software-based solutions are well-known and implemented in mostOSes, we focus on the implementation of the secure USB bridge. We imple-mented a prototype bridge to communicate with a kernel module on a Linux

66

host computer. We have performed a preliminary performance analysis ofour prototype by testing it with a USB bulk device and a flash drive. We ob-served that our secure channel using SHA1-RC4 and SHA1-AES encryptionsignificantly reduces data throughput, and we have identified the cause ofthe performance impact to be the bottleneck on the prototype bridge imple-mentation.

To conclude, our solution has provided a general approach to improvingcommunication security on commodity USB products without requiring themodification of either the device or the device software.

Further research may be pursued in the following directions.

• Device identification. By measuring certain characteristics, such aspower usage profiles, the bridge may be able to individually identifyUSB devices, which is helpful in preventing attacks from maliciousdevices connected directly to the bridge.

• Key exchange protocols. There remains many other pairing mecha-nisms which could be explored to identify a suitable key exchangeprotocol in the use case of USB devices.

• Performance improvement. Our current prototype induces significantperformance overhead, which could be reduced by specialized hard-ware. Additionally, the bridge could be enhanced to prefetch data if itis suitable for the device type, thereby improving overall throughput.For example, if a webcam is detected, the bridge may fetch its datawhile waiting for requests from the host computer.

• Extensive USB device support. To improve the compatibility of our so-lution, more USB device types with different communication protocolsmay be tested.

• USB On-the-go. USB On-the-go (OTG) [71] is a standard which allowsa USB device to communicate with another USB device instead of ahost computer. It would therefore be interesting to investigate this usecase and adapt our security solution accordingly.

• Secure USB standards. Instead of providing a bump-in-the-wire solu-tion like the secure USB bridge, a more robust secure communicationenvironment could be achieved by incorporating security features infuture USB specifications.

67

Bibliography

[1] Mashable: Did You Know 3 Billion USB Products Are Shipped EveryYear? http://mashable.com/2012/10/08/usb-history/.

[2] Omron 790IT Protocol Documentation. http://docs.nonpolynomial.

com/libomron/devel/asciidoc/omron_protocol_notes.html.

[3] Steven Hanna, Rolf Rolles, Andres Molina-Markham, PongsinPoosankam, Kevin Fu, and Dawn Song. Take Two Software Updatesand See Me in the Morning: the Case for Software Security Evalua-tions of Medical Devices. In Proceedings of the 2nd USENIX conference onHealth security and privacy, HealthSec’11, pages 6–6, Berkeley, CA, USA,2011. USENIX Association.

[4] Facedancer USB: Exploiting the Magic School Bus. http://recon.cx/

2012/schedule/events/237.en.html.

[5] B. Dolgunov. Enabling Optimal Security for Removable Storage De-vices. In Security in Storage Workshop, 2007. SISW ’07. Fourth InternationalIEEE, pages 15 –21, sept. 2007.

[6] Fuw-Yi Yang, Tzung-Da Wu, and Su-Hui Chiu. A Secure Control Pro-tocol for USB Mass Storage Devices. Consumer Electronics, IEEE Transac-tions on, 56(4):2239 –2343, november 2010.

[7] USB.org. http://www.usb.org.

[8] Linux Kernel Documentation for USB Request Blocks. http://www.

kernel.org/doc/Documentation/usb/URB.txt.

[9] Linux Kernel Documentation for USB DMA and Scatter/Gather IO.http://www.kernel.org/doc/Documentation/usb/dma.txt.

68

http://mashable.com/2012/10/08/usb-history/

http://docs.nonpolynomial.com/libomron/devel/asciidoc/omron_protocol_notes.html

http://docs.nonpolynomial.com/libomron/devel/asciidoc/omron_protocol_notes.html

http://recon.cx/2012/schedule/events/237.en.html

http://recon.cx/2012/schedule/events/237.en.html

http://www.usb.org

http://www.kernel.org/doc/Documentation/usb/URB.txt

http://www.kernel.org/doc/Documentation/usb/URB.txt

http://www.kernel.org/doc/Documentation/usb/dma.txt

Bibliography

[10] Linux ioctl manpage. http://www.unix.com/man-page/linux/2/

ioctl/.

[11] libusb, version 1.0.0. http://www.libusb.org.

[12] I. Arce. Bad Peripherals. Security Privacy, IEEE, 3(1):70 –73, jan.-feb.2005.

[13] Darrin Barrall and David Dewey. “Plug and Root,” the USBKey to the Kingdom. http://www.blackhat.com/presentations/

bh-usa-05/BH_US_05-Barrall-Dewey.pdf.

[14] Adrian Crenshaw. Plug and Prey: Malicious USB De-vices. http://www.irongeek.com/i.php?page=security/

plug-and-prey-malicious-usb-devices.

[15] John Clark, Sylvain Leblanc, and Scott Knight. Compromise throughUSB-based Hardware Trojan Horse Device. Future Generation ComputerSystems, 27(5):555 – 563, 2011.

[16] A. Tetmeyer and H. Saiedian. Security Threats and Mitigating Risk forUSB Devices. Technology and Society Magazine, IEEE, 29(4):44 –49, winter2010.

[17] Adam Wright and Dean F. Sittig. Technical brief: Encryption character-istics of two usb-based personal health record devices. JAMIA, pages397–399, 2007.

[18] Hanjae Jeong, Younsung Choi, Woongryel Jeon, Fei Yang, Yunho Lee,Seungjoo Kim, and Dongho Won. Vulnerability Analysis of Secure USBFlash Drives. In Memory Technology, Design and Testing, 2007. MTDT2007. IEEE International Workshop on, pages 61 –64, dec. 2007.

[19] Sun-Ho Lee, Kang-Bin Yim, and Im-Yeong Lee. A Secure Solution forUSB Flash Drives Using FAT File System Structure. In Network-BasedInformation Systems (NBiS), 2010 13th International Conference on, pages487 –492, sept. 2010.

[20] Idan AVRAHAM, John C. DUNN, Constantyn KOEMAN, MarkWILLIAMS, and David R. WOOTEN. Accessing a USB Host ControllerSecurity Extension Using a HCD Proxy. Patent, 02 2011. US 7886353.

[21] S.J. Stolfo. Worm and Attack Early Warning: Piercing Stealthy Recon-naissance. Security Privacy, IEEE, 2(3):73 –75, may-june 2004.

69

http://www.unix.com/man-page/linux/2/ioctl/

http://www.unix.com/man-page/linux/2/ioctl/

http://www.libusb.org

http://www.blackhat.com/presentations/bh-usa-05/BH_US_05-Barrall-Dewey.pdf

http://www.blackhat.com/presentations/bh-usa-05/BH_US_05-Barrall-Dewey.pdf

http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices

http://www.irongeek.com/i.php?page=security/plug-and-prey-malicious-usb-devices

Bibliography

[22] Georgios Portokalidis, Asia Slowinska, and Herbert Bos. Argos: An Em-ulator for Fingerprinting Zero-day Attacks for Advertised Honeypotswith Automatic Signature Generation. In Proceedings of the 1st ACMSIGOPS/EuroSys European Conference on Computer Systems 2006, EuroSys’06, pages 15–27, New York, NY, USA, 2006. ACM.

[23] Jonathan Shapiro, Ph. D, Michael Scott Doerrie, Eric Northup, andMark Miller. Towards a Verified, General-Purpose Operating SystemKernel. In In Klein [10, pages 1–19, 2004.

[24] Kevin Elphinstone, Gerwin Klein, Philip Derrin, Timothy Roscoe, andGernot Heiser. Towards a practical, verified kernel. In Proceedings ofthe 11th USENIX workshop on Hot topics in operating systems, HOTOS’07,pages 20:1–20:6, Berkeley, CA, USA, 2007. USENIX Association.

[25] W.A. Arbaugh, D.J. Farber, and J.M. Smith. A Secure and ReliableBootstrap Architecture. In Security and Privacy, 1997. Proceedings., 1997IEEE Symposium on, pages 65 –71, may 1997.

[26] Bill Horne, Lesley Matheson, Casey Sheehan, and Robert E. Tarjan. Dy-namic Self-Checking Techniques for Improved Tamper Resistance. Inin ACM Workshop on Security and Privacy in Digital Rights Management,pages 141–159. Springer-Verlag, 2001.

[27] David Aucsmith. Tamper Resistant Software: An Implementation. InRoss Anderson, editor, Information Hiding, volume 1174 of Lecture Notesin Computer Science, pages 317–333. Springer Berlin / Heidelberg, 1996.

[28] Hoi Chang and Mikhail J. Atallah. Protecting Software Code by Guards.In Revised Papers from the ACM CCS-8 Workshop on Security and Privacy inDigital Rights Management, DRM ’01, pages 160–175, London, UK, UK,2002. Springer-Verlag.

[29] Microsoft Developer Network. http://msdn.microsoft.com.

[30] Ubuntu. http://www.ubuntu.com/.

[31] Security Basics - Fedora Project. http://fedoraproject.org/wiki/

SecurityBasics#Security_Measures_in_Fedora_Systems.

[32] C. Cowan. Software Security for Open-source Systems. Security Privacy,IEEE, 1(1):38 – 45, jan.-feb. 2003.

[33] VirtualBox. https://www.virtualbox.org/.

70

http://msdn.microsoft.com

http://www.ubuntu.com/

http://fedoraproject.org/wiki/SecurityBasics#Security_Measures_in_Fedora_Systems

http://fedoraproject.org/wiki/SecurityBasics#Security_Measures_in_Fedora_Systems

https://www.virtualbox.org/

Bibliography

[34] Paul Barham, Boris Dragovic, Keir Fraser, Steven Hand, Tim Harris,Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield. Xen andthe Art of Virtualization. In Proceedings of the nineteenth ACM symposiumon Operating systems principles, SOSP ’03, pages 164–177, New York, NY,USA, 2003. ACM.

[35] Vladimir Kiriansky, Derek Bruening, and Saman P. Amarasinghe. Se-cure Execution via Program Shepherding. In Proceedings of the 11thUSENIX Security Symposium, pages 191–206, Berkeley, CA, USA, 2002.USENIX Association.

[36] Maxwell Krohn, Alexander Yip, Micah Brodsky, Natan Cliffer, M. FransKaashoek, Eddie Kohler, and Robert Morris. Information Flow Con-trol for Standard OS Abstractions. In Proceedings of twenty-first ACMSIGOPS symposium on Operating systems principles, SOSP ’07, pages 321–334, New York, NY, USA, 2007. ACM.

[37] Andrew C. Myers and Barbara Liskov. Protecting Privacy Using theDecentralized Label Model. ACM Trans. Softw. Eng. Methodol., 9(4):410–442, October 2000.

[38] AppArmor. http://wiki.apparmor.net/.

[39] Security-enhanced Linux. http://www.nsa.gov/research/selinux/

index.shtml.

[40] Silas Boyd-Wickizer and Nickolai Zeldovich. Tolerating Malicious De-vice Drivers in Linux. In Proceedings of the 2010 USENIX conference onUSENIX annual technical conference, USENIXATC’10, pages 9–9, Berke-ley, CA, USA, 2010. USENIX Association.

[41] Jonathan M. McCune, Bryan J. Parno, Adrian Perrig, Michael K. Re-iter, and Hiroshi Isozaki. Flicker: An Execution Infrastructure for TCBMinimization. SIGOPS Oper. Syst. Rev., 42(4):315–328, April 2008.

[42] OSLO: Improving the Security of Trusted Computing. http://static.usenix.org/event/sec07/tech/full_papers/kauer/kauer_html/.

[43] Jonathan M. McCune, Yanlin Li, Ning Qu, Zongwei Zhou, AnupamDatta, Virgil Gligor, and Adrian Perrig. TrustVisor: Efficient TCB Re-duction and Attestation. In Proceedings of the 2010 IEEE Symposium onSecurity and Privacy, SP ’10, pages 143–158, Washington, DC, USA, 2010.IEEE Computer Society.

[44] Amit Vasudevan, Jonathan McCune, James Newsome, Adrian Perrig,and Leendert van Doorn. CARMA: A Hardware Tamper-Resistant Iso-lated Execution Environment on Commodity x86 Platforms, 2012.

71

http://wiki.apparmor.net/

http://www.nsa.gov/research/selinux/index.shtml

http://www.nsa.gov/research/selinux/index.shtml

http://static.usenix.org/event/sec07/tech/full_papers/kauer/kauer_html/

http://static.usenix.org/event/sec07/tech/full_papers/kauer/kauer_html/

Bibliography

[45] Tilo Muller, Felix C. Freiling, and Andreas Dewald. TRESOR RunsEncryption Securely Outside RAM. In Proceedings of the 20th USENIXconference on Security, SEC’11, pages 17–17, Berkeley, CA, USA, 2011.USENIX Association.

[46] G. Edward Suh, Charles W. O’Donnell, and Srinivas Devadas. AEGIS:A Single-chip Secure Processor. Information Security Technical Report,10(2):63 – 73, 2005.

[47] Liang Gu, Xuhua Ding, Robert Huijie Deng, Bing Xie, and Hong Mei.Remote Attestation on Program Execution. In Proceedings of the 3rdACM workshop on Scalable trusted computing, STC ’08, pages 11–20, NewYork, NY, USA, 2008. ACM.

[48] Andrew C. Yao. Protocols for Secure Computations. In Proceedings ofthe 23rd Annual Symposium on Foundations of Computer Science, SFCS ’82,pages 160–164, Washington, DC, USA, 1982. IEEE Computer Society.

[49] TOMOYO Linux. http://tomoyo.sourceforge.jp/.

[50] The Smack Project. http://schaufler-ca.com/.

[51] Chris Wright, Crispin Cowan, and James Morris. Linux Security Mod-ules: General Security Support for the Linux Kernel. In In Proceedingsof the 11th USENIX Security Symposium, pages 17–31, 2002.

[52] W. Diffie and M. Hellman. New Directions in Cryptography. Informa-tion Theory, IEEE Transactions on, 22(6):644 – 654, nov 1976.

[53] BeagleBoard.org - BeagleBone Rev A6. http://beagleboard.org/

bone.

[54] ARM Cortext-A8 Processor Product Page. http://www.arm.com/

products/processors/cortex-a/cortex-a8.php.

[55] Texas Instruments AM3359 ARM Cortex-A8 Microprocessor. http://

www.ti.com/product/am3359.

[56] StarterWare for ARM based TI microprocessors, version 2.00.00.07.http://www.ti.com/tool/starterware-sitara.

[57] Light-weight, modular cryptographic and SSL/TLS library in C - Po-larSSL, version 1.1.4. http://polarssl.org/.

[58] The Transport Layer Security (TLS) Protocol Version 1.2. http://

tools.ietf.org/html/rfc5246.

72

http://tomoyo.sourceforge.jp/

http://schaufler-ca.com/

http://beagleboard.org/bone

http://beagleboard.org/bone

http://www.arm.com/products/processors/cortex-a/cortex-a8.php

http://www.arm.com/products/processors/cortex-a/cortex-a8.php

http://www.ti.com/product/am3359

http://www.ti.com/product/am3359

http://www.ti.com/tool/starterware-sitara

http://polarssl.org/

http://tools.ietf.org/html/rfc5246

http://tools.ietf.org/html/rfc5246

Bibliography

[59] Linux Kernel Documentation for Kernel Probes. http://www.kernel.

org/doc/Documentation/kprobes.txt.

[60] StarterWare Forums - BeagleBone High-speed bulk USB trans-fer. http://e2e.ti.com/support/embedded/starterware/f/790/t/

184201.aspx.

[61] StarterWare Forums - AM335x USB Host CppiDmaModeSet() functionfor setting Per EndPoint RNDIS mode does not match TRM. http://

e2e.ti.com/support/embedded/starterware/f/790/t/207941.aspx.

[62] StarterWare Forums - USB DMA RNDIS question. http://e2e.ti.

com/support/embedded/starterware/f/790/t/211686.aspx.

[63] Linux USB Gadget API Framework. http://www.linux-usb.org/

gadget/.

[64] Freescale i.MX53 Quick Start Board Product Summary Page. http:

//freescale.com/iMXQuickStart.

[65] A. Nadeem and M.Y. Javed. A Performance Comparison of Data En-cryption Algorithms. In Information and Communication Technologies,2005. ICICT 2005. First International Conference on, pages 84 – 89, aug.2005.

[66] Peter M. Ridge and David Deming. The Book of SCSI. No Starch Press,San Francisco, CA, USA, 1995.

[67] Sysprof, System-wide Performance Profiler for Linux. http://

sysprof.com/.

[68] The Linux Kernel Archives. http://kernel.org/.

[69] AM335x-PSP 04.06.00.06 Features and Performance Guide.http://processors.wiki.ti.com/index.php/AM335x-PSP_04.06.

00.06_Features_and_Performance_Guide.

[70] AM335x Crypto Performance. http://processors.wiki.ti.com/

index.php/AM335x_Crypto_Performance.

[71] USB.org - USB On-the-go. http://www.usb.org/developers/onthego.

Internet references were accessed on Tuesday 23rd October, 2012.

73

http://www.kernel.org/doc/Documentation/kprobes.txt

http://www.kernel.org/doc/Documentation/kprobes.txt

http://e2e.ti.com/support/embedded/starterware/f/790/t/184201.aspx






http://www.linux-usb.org/gadget/

http://www.linux-usb.org/gadget/

http://freescale.com/iMXQuickStart

http://freescale.com/iMXQuickStart

http://sysprof.com/

http://sysprof.com/

http://kernel.org/

http://processors.wiki.ti.com/index.php/AM335x-PSP_04.06.00.06_Features_and_Performance_Guide

http://processors.wiki.ti.com/index.php/AM335x-PSP_04.06.00.06_Features_and_Performance_Guide

http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance

http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance

http://www.usb.org/developers/onthego

Documents

In Copyright - Non-Commercial Use Permitted Rights / License: … · 2020-02-15 · should also provide security guarantees. Additionally, securing software applications on the computer