2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN)

DeviceVeil: Robust Authentication for Individual

USB Devices Using Physical Unclonable Functions
Kuniyasu Suzaki∗ , Yohei Hori∗ , Kazukuni Kobara∗ , Mohammad Mannan†
∗ National Institute of Advanced Industrial Science and Technology, Japan
† Concordia University, Canada

Abstract—The Universal Serial Bus (USB) supports a diverse a Japanese education company, which announced the leak
and wide-ranging set of device types. To enable ease of use, USB of 29 million customer records by a company engineer in
devices are automatically detected and classified by common op- 2014 [25]. Benesse apparently had a prevention mechanism
erating systems, without any authentication. This trust-by-default
design principle can be easily exploited, and led to numerous enforced by Windows ActiveDirectory against illegal use of
attacks in the past (e.g., Stuxnet, BadUSB, BadAndroid), specif- Mass Storage Class USB devices. However, the engineer
ically targeting high-value organizations. Administrators’ efforts allegedly used MTP/PTP of his smartphone to bypass the
to prevent these attacks may also be threatened by unscrupulous protection, highlighting the difficulty of designing protection
users who may insert any USB device, or malicious users (inside mechanisms that can withstand malicious insiders. In addition,
attackers) who may try to circumvent OS/kernel-enforced pro-
tection mechanisms (e.g., via OS replacement). The root causes an insider can replace a hardened OS/kernel enforcing the
of USB attacks appear to be the lack of robust authentication of protection with a backup tool, and then restore the system
individual USB devices and inadequate tamper-proofing of the after connecting an illegal USB device (e.g., to copy sensitive
solution mechanism itself. We propose DeviceVeil to address files). The insider can also load an unauthorized kernel with
these limitations. To authenticate individual USB devices, we the Linux kexec syscall [46], and thus can bypass OS-bound
utilize the tamper-proof feature of Physical Unclonable Functions
(PUFs); PUFs extract unique features from physical character- defenses including secure boot. However, complete blocking
istics of an integrated circuit (IC) at a reasonable cost (less of USB devices (e.g., by physical means) is a non-solution, as
than 1 USD). To make our authentication mechanism robust, many machines routinely connect peripheral devices by USB
we implement it as a small hypervisor, and protect it by a novel alone, e.g., a USB keyboard and mouse, although these devices
combination of security technologies available in commodity PCs, can be easily exploited, as evident from BadUSB [43].
e.g., Trusted Platform Module (TPM), customized secure boot,
and virtualization support. The OS disk image with all user data Despite these high-profile attacks, security awareness re-
is encrypted by a key sealed in TPM and can be decrypted by garding USB devices is still low. CompTIA [10] reported
the hypervisor only. Customized secure boot allows the loading that 17% of the dropped unknown USB storage devices were
of the legitimate hypervisor and OS kernel only. The hypervisor plugged into PCs in several US business districts. Tischer et
enables pre-OS authentication to protect the trust-by-default OS al. [70] dropped 297 USB storage devices in a university
from USB attacks. The chain of trust continues from power-on to
the insertion of a USB device and disallows all illegitimate USB campus (UIUC), and found that HTML files in 45% of the
devices. DeviceVeil’s PUF authentication takes about 1.7 seconds devices were opened. These careless and accidental insertions
during device insertion. also must be addressed, especially, in an enterprise solution.
To counter these attacks, the USB 3.0 Type-C specification
Index Terms—Individual Device Authentication, Hypervisor, includes PKI-based authentication with tamper-proof hard-
Physical Unclonable Function, Secure Boot, Trusted Computing ware [72]; each product would hold a certificate issued by the
USB Implementers Forum or an intermediate CA to protect
I. I NTRODUCTION counterfeit. The specification states that “Products should
Current USB standards (2.0 or 3.0) support several so- provide protected tamper-resistant operation and storage for
phisticated mechanisms but follow the trust-by-default [69] the private keys to prevent them from being read.” Nev-
design principle, connecting many types of devices with ertheless, tamper-resistant mechanisms remain unspecified.
heterogeneous protocols, including, Human Interface Devices Another drawback of the specification is that the proposed
(HID), Mass Storage Class (MSC), Media Transfer Protocol authentication is effective only for each product type, but
(MTP) and Picture Transfer Protocol (PTP). The ubiquity and not for individual devices. Most access control mechanisms
diversity of USB have enabled many high-profile attacks. For also support product-level only (e.g., ActiveDirectory and
example, Stuxnet [9], [32] relied on a USB storage device, SELinux). Solutions that support individual device authentica-
and went beyond network air-gap to compromise Iranian tion, mostly rely on USB serial numbers (e.g., USBSec [78]
SCADA/nuclear systems. BadUSB [43] camouflaged USB and GoodUSB [66]). However, USB serial numbers can be
storage as a USB keyboard and inserted malicious commands. easily modified to defeat such weak authentication; e.g., see
USB attacks are also perpetrated by insiders. The most the attack [44] on USB Raptor [74], which uses USB serial
famous insider attack that uses USB is possibly the Edward numbers to lock/unlock Windows. Therefore, it is clearly
Snowden incident in 2013 [80]. Another example is, Benesse, evident that a tamper-proof hardware mechanism is required

978-1-7281-0057-9/19/$31.00 ©2019 IEEE 302

DOI 10.1109/DSN.2019.00041
Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 to implement any robust device authentication. which can be easily duplicated, or the use of per-device
Such robust device authentication technologies have been unique secret keys, which can be extracted. In addition,
available for smart cards for more than a decade now [1], PUF derives different IDs from different sampling points,
[37]. For example, Subscriber Identity Module (SIM) cards and the setting of PUF authentication is controlled by the
for mobile phones use Secure Element [52] as a tamper- administrators in an enterprise environment (i.e., the USB
proof technology for individual device authentication. The device manufacturers are not involved in the authentica-
specification of Secure Element is openly defined by Glob- tion process). One challenge for PUF implementation is
alPlatform [19], and the chip is available from several secure the cost of an individual device. We estimate the hardware
semiconductor vendors (e.g., Gemalto, NXP). Unfortunately, cost of our PUF design is less than 1 USD (apparently
these device authentication mechanisms based on hardware reasonable even for low-cost USB devices).
tamper-proof technologies are relatively costly and accessible 2) Tamper-proofing against inside attackers: DeviceVeil in-
to some vendors for specific devices (e.g., mobile phones), and troduces tamper-proofing into both the USB device and
IT administrators cannot modify SE to use in commodity PCs. the software components on a client PC. We utilize a
Software tamper-proof technologies can also be used to novel combination of TPM, secure boot, and virtualiza-
protect a device authentication solution. For example, Intel tion technology—compensating each other’s shortcom-
SGX (Software Guard Extensions) offers software tamper- ings. DeviceVeil encrypts the entire OS including user
proofing; however, SGX cannot handle intermediate device data, and the encryption key is sealed in the TPM chip,
recognition between a USB device and the OS because SGX i.e., can be extracted from the TPM when the Platform
offers Ring-3 isolated execution environment named ”enclave” Configuration Register (PCR) values are extended with
and does not have direct access to devices. Virtualization the correct hash of the hypervisor only. Our customized
can also be used to implement tamper-proof hypervisors, secure boot allows loading of the hypervisor and the OS
e.g., HyperSentry [4], HyperSafe [79], TrustVisor [38] and kernel only. The hypervisor includes a pre-OS authen-
SecVisor [53]. Unfortunately, they are not designed to protect tication mechanism and protects the existing OS. Thus,
OS replacement attacks, such as the Linux kexec syscall [46] malicious users cannot reinstall another OS, remove the
from the userland by insiders. DeviceVeil hypervisor, or access content from the OS
We propose DeviceVeil to authenticate individual USB through unauthenticated USB devices.
devices using Physical Unclonable Functions (PUFs) with 3) Vendor/OS independence: DeviceVeil uses the vendor-
a hardened thin hypervisor. PUFs do not require additional independent tamper-proof technology, PUFs, allowing
tamper-proofing, and extract uniqueness from physical char- enterprise administrators to configure challenge-response
acteristics of integrated circuits. The setting of PUFs can pairs. In addition, DeviceVeil hypervisor runs only one
be managed by enterprise administrators and a challenge- commodity OS and protects it from unauthenticated USB
response authentication pair can be reset even if the pair devices. Authentication is enforced within the hypervisor
is lost/compromised. The thin hypervisor is strengthened by before the OS can interact with the actual USB device.
security technologies in commodity PCs, including Trusted DeviceVeil also utilizes readily-available security tech-
Platform Module (TPM), secure boot, and virtualization. Our nologies in commodity PCs, aiding deployability.
novel combination of these techniques compensates short- 4) Implementation: We have implemented a prototype of
comings of individual components. The disk image of the DeviceVeil by reusing and modifying the code from
OS is encrypted by a key sealed in the TPM chip, and the several projects, including BitVisor [56] (for the thin
key is extracted by the hypervisor depending only on the hypervisor), DeviceDisEnabler [62] (parts of TPM man-
trusted boot technology. However, trusted boot cannot prevent agement), and Zuiho [87] (USB-PUF authentication).
the re-installation attack, which can be mitigated by secure The overhead comes from PUF authentication during
boot by allowing the legitimate kernel only. The hypervisor device insertion, an average of 1.7 seconds, and zero
enables pre-OS authentication in an isolated environment and performance penalty during the device use.
protects the existing OS that follows the trust-by-default [69] II. ATTACK T YPES AND T HREAT M ODEL
design principle of USB authentication. DeviceVeil is pri-
marily targeted for enterprise environments, where a trusted In this section, we summarize common attack types against
administrator can configure employee machines and initialize USB and provide our threat model.
all allowed USB devices. A. Attack types
Contributions and Challenges: When a USB device is inserted, the OS recognizes the USB
1) Individual USB device authentication: DeviceVeil is the device based on its descriptor (e.g., vendor ID, class ID, serial
first solution that authenticates individual USB devices number), and loads a suitable device driver automatically. This
by PUF, and thus connecting USB device authentica- trust-by-default [69] design principle facilitates most attack
tion to physical characteristics of the USB IC. The use types exploiting USB.
of PUF provides robust hardware-based identification BadUSB [43] utilizes a vulnerability in USB firmware and
against tampering, e.g., unlike device serial number, customizes it to camouflage as a USB keyboard, i.e., identify-

303

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 ing the device class as a Human Interface Device (HID). The tected by secure boot (only signed updates issued by the
camouflaged keyboard inputs malicious commands. Another administrator are allowed).
similar attack is USBProxy [59] that uses the USB On-The- 3) The adversary can have physical control of USB devices,
Go specification [73] to mimic another (allowed) device type. including legitimate USB devices with PUF. He can
USB On-The-Go enables a USB device to switch the roles of exploit the USB controller and modify the USB device
a host and device (for the case of a one-to-one connection). descriptor (i.e., device class and serial number) as in
USBProxy exploits this functionality to enable MITM attacks. BadUSB. However, we assume PUF is unmodified and
The diverse set of protocols as allowed in USB standards, cannot be moved to another USB device (i.e., PUF is
are also leveraged in some attacks. As mentioned in Section I, integrated into the USB’s IC).
MTP/PTP has allegedly been used to bypass the protection for 4) DeviceVeil does not control the content in USB devices,
MSC at Benesse [25]. Furthermore, some smartphones offer and as such cannot protect the host OS against USB
“USB Debug Mode”, not protected by ActiveDirectory [77]. malware in legitimate USB devices. Also, DeviceVeil
BadAndroid [5] spoofs a USB-Ethernet adapter from an An- cannot prevent information leakage through an authorized
droid phone to capture the traffic from a connected computer. USB device. Confidentiality and integrity of contents
All USB devices typically include a device descriptor to must be protected by other means (e.g., encryption or
advertise their features; the descriptor offers information such access control).
as the vendor ID, product ID, class ID, serial number, etc. The 5) The adversary can change TPM configuration (e.g., re-
USB specifications do not require a mandatory, hard-coded set ownership via jumper settings), but cannot launch
serial number, and thus some products use the same serial attacks that require significant lab efforts (chip imag-
number, or no serial number at all, e.g., USB keyboard/mouse. ing/decapping). Note that TPM reset will not leak the
Most USB access control tools like ActiveDirectory usually TPM-sealed disk encryption key (unsealed only with
do not consider the USB serial number because their purpose specific PCR values). We also assume the TPM firmware
is to allow/disallow certain product types (based on device is also kept up-to-date (cf. [23]).
descriptor); note that ActiveDirectory can be configured to use
serial numbers. III. C URRENT C OUNTERMEASURES
Several countermeasures for USB attacks have been pro-
B. Threat model and assumptions
posed and implemented in academic literature and commercial
DeviceVeil has two primary goals: disallow any unautho- solutions. We categorize them as USB access control, USB au-
rized USB device, and protect the OS kernel and DeviceVeil thentication, and tamper-proofing, and discuss a few examples
itself from being tampered. We protect DeviceVeil against closely related to our work. For a comprehensive analysis of
different types of inside attackers, including the following. (a) all major defensive solutions, see Tian et al. [69].
Attackers with admin privileges of the OS (not the system
administrator who sets up DeviceVeil), may use the kexec A. USB access control
command to load a separate Linux kernel without restrictions ActiveDirectory and SELinux are the most popular access
(e.g., no active defense against USB attacks). Kexec is a kernel control mechanisms on Windows and Linux, respectively.
function to load another kernel from the running kernel with- ActiveDirectory has a group policy for USB devices and
out the help of BIOS/UEFI and bootloader, which can also be allows access control for each product or device class, but
used as a jailbreak mechanism [47]. From kernel version 3.17, cannot distinguish individual devices. SELinux also offers
kexec has an option for allowing only kernels with verifiable similar access control in Linux. Solutions that support in-
digital signatures. (b) Insiders may also reinstall the OS on dividual device authentication, mostly rely on USB serial
the target PC. They can recover the previous/legitimate OS if numbers (e.g., USBSec [78] and GoodUSB [66]). However,
they keep the disk image (to avoid detection). Backup tools can USB serial numbers can be easily modified, and thus such
also help such attacks by allowing the seamless/instant restore weak authentication can be defeated (see e.g., [44]).
feature. (c) Attackers may also try to install a hypervisor that USBFILTER [68] and Cinch [2] introduce packet filtering
allows direct access to USB devices through I/O virtualization based security mechanisms for USB communication. Packet
(e.g., Intel VT-d) to a guest OS. The host OS/hypervisor does filtering can allow fine-grain access control and prevent at-
not interfere with such direct access. tacks. USBFILTER is implemented as a reference monitor
Security assumptions for DeviceVeil include the following. and is statically compiled and linked into the Linux kernel
1) The adversary can have physical control of the machine to avoid being unloaded; it uses a database of rules for
after the secure setup of DeviceVeil. We assume that USB packets for each application, and filters the applications
administrators deploy PCs with secure BIOS, keep the accordingly. Cinch also utilizes packet filtering, but it uses two
BIOS firmware updated, and protect the BIOS using KVM virtual machines, where the first VM is sacrificial while
strong passwords that are not shared with a regular user the other one runs a guest OS. The sacrificial VM uses I/O
(see also Section VIII). virtualization and connects to USB devices directly. There is
2) The adversary has root/admin privileges of the OS, but an enforcer between the sacrificial VM and the guest OS, and
he cannot replace the hypervisor/kernel as they are pro- packets are filtered and encrypted. However, as packet filtering

304

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 involves checking all communications to/from a USB device, tamper-proofing and OS independence are required. These
significant overhead is incurred; e.g., USBFILTER suffered requirements are fulfilled by PUF and a novel combination
17.6% overhead when 100MB data was transferred, and Cinch of security technologies in commodity PCs, i.e., TPM, secure
reduced the I/O throughput from 3.4Gbps (direct) to 2.1Gbps boot, and virtualization.
for USB-SSD.
SandUSB [34] and USBWall [27] use a small computer A. PUF: Physical Unclonable Function
between a USB device and a host PC, which monitors the PUFs use the delay of the electric signal or the initial state
USB’s behaviors. SandUSB uses a Raspberry Pi2 with a of memory, which differs on each chip due to small variations
module to relay USB packets from a USB device to the resulting from the manufacturing process. These features allow
PC. SandUSB scans and analyzes USB packets using USB- deriving unique secrets from individual physical characteristics
Mon [83]. USBWall uses a BeagleBone Black (BBB) and runs of ICs. When the sampling points are changed, PUFs create a
USBProxy [59] to act as middleware to enumerate the devices different ID from the device. PUFs utilize hardware intrinsic
on behalf of the PC. USBWall has no mechanism to filter USB features and do not require any special mechanism for hiding
protocols, and simply works as an isolated environment. secret keys in tamper-proof hardware. PUFs are used for DRM,
key generation, and device authentication (see e.g., [16], [30],
B. USB authentication [33], [36], [49], [61], [63]).
Most USB device authentication targets device class identi- 1) Fuzzy extractor: PUFs use fragile physical characteris-
fication, instead of individual devices (as in USB 3.0 Type-C tics of ICs and have an intrinsic limitation. Since PUFs are
specifications). Some solutions use the serial number of a USB sensitive to noise and always produce bit errors in response,
device but the serial number is easily modified. Kanguru’s a correction technique is required. In 2004, Dodis et al. [13]
FlashTrust [28] introduces a digitally signed firmware to proposed circuits, known as a fuzzy extractor, to correct bit
protect against BadUSB, but it is not designed for individual errors by extracting uniform random bits. The fuzzy extractor
authentication. GoodUSB [66] offers device authentication is implemented in PUF authentication and creates error correc-
mediated by a human user. The user makes “the final decision” tion data known as helper data [6]. The helper data is passed
from the physical form of the USB device, i.e., GoodUSB to the circuits when the key is used for authentication. While
implicitly trusts its users, and thus cannot prevent inside the redundant information calculated during verification may
attackers or unscrupulous users. include noise, the original redundant information (calculated
Kells [7] and ProvUSB [67] offer host authentication based at the initialization, and used at the verification phase as helper
on a TPM to limit USB devices to connect only to legitimate data) is noiseless. The noise in redundant information in the
host computers. They require a special USB device with verification phase is corrected with the helper data.
computation capability (e.g., an ARM CPU). The device also 2) PUF device authentication: The key created by PUF
includes public key issued by the TPM on the host machine. and fuzzy extractor can be used for authentication [16],
If the authentication (i.e., the public key verification) fails, [61]. Note that, pure PUF circuits are passive and lack
the device exposes dummy flash storage. The deployment cost memory, and some PUF authentication circuits include an
may be non-negligible due to the need for an on-board CPU additional cipher mechanism [30], [36], [49]. Some current
per USB device. PUF authentication mechanisms are based on arbitrary string
encryption/decryption and include the circuits implementing
C. Tamper-proofing the ciphers (see later sections for DeviceVeil).
Robust and tamper-proof authentication is essential to pre-
vent insider attacks, but most countermeasures are installed B. TPM and Trusted Boot
only in a kernel or hypervisor, which can be bypassed by Trusted Platform Module (TPM) is a secure chip avail-
several attack vectors such as kernel replacement via kexec, able on many commodity PCs. DeviceVeil utilizes platform
or installation of an unprotected hypervisor/OS. On the other integrity and sealing/unsealing of TPM.
hand, many current PCs are equipped with UEFI secure 1) Platform integrity: The measurement of platform in-
boot [81] that prevents the loading of unsigned/unauthorized tegrity is the core concept of trusted boot consisting of multiple
bootloaders or kernels. For example, Microsoft Windows Pro- phases: measuring and extending cryptographic hash values
duction CA allows booting only signed Windows bootloader of hardware and software components. When the system is
and kernel. DeviceVeil utilizes the secure boot mechanism powered on, the immutable bootstrap code (CRTM: Core Root
and TPM sealing to enable tamper-proofing, which resembles of Trust for Measurement) measures the hash value (e.g.,
Windows BitLocker to some extent. through SHA-1 in TPM 1.2) of the BIOS and extends it in
the PCR (Platform Configuration Register) of TPM before
IV. BACKGROUND transferring control. The TCG-BIOS also measures the hash
As discussed in Section I in the explanation of USB 3.0 values of peripheral devices, option ROMs, and the bootloader,
Type-C specification and Secure Element of SIM card, a and extends them in the same manner. The same method is
hardware-based tamper-proof mechanism is needed to im- implemented in the bootloader and kernel, and thus enables a
plement robust individual device authentication. In addition, chain of trust.

305

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 2) Sealing/Unsealing: Sealing/unsealing of TPM is W 'ƵĞƐƚK^
limited by the measured PCR values to load a key in a
TPM. Windows BitLocker uses this mechanism to limit ĞǀŝĐĞsĞŝů
;,LJƉĞƌǀŝƐŽƌͿ Wh& ƵƚŚĞŶƚŝĐĂƚŝŽŶ
access to the key when PCRs show the values which are
extended at a legitimate booting (i.e., the boot procedures ŶĐƌLJƉƚĞĚ 
WĂƌƚŝƚŝŽŶĨŽƌ ůŝď&d/
and devices remain original). In order to offer a FDE (Full 'ƵĞƐƚK^ 9HQGRU,'
3URGXFW,'
&ODVV,'
WĂƌƚŝƚŝŽŶĨŽƌ h^ ĞƚĞĐƚŝŽŶ
Disk Encryption) to Windows, BitLocker separates the ĞǀŝĐĞsĞŝů
6XE&ODVV ,'
6HULDO1R
&KDOOHQJH
storage into the non-encrypted and encrypted partitions, as sĞƌŝĨŝĞĚďLJ +HOSHU
ůŝďh^
<ĞLJŝŶdWD ^ĞĐƵƌĞŽŽƚ &LSKHUWH[W

the non-encrypted partition is used by the bootloader before <ĞLJŝƐĞdžƚƌĂĐƚĞĚďLJ

SODLQWH[W

h^WŽƌƚ
the secret key is unsealed from the TPM. Sealing/unsealing dƌƵƐƚĞĚŽŽƚ ;ZŽŽƚ,ƵďͿ
of TPM is also used for other applications to confirm the
&d/
correctness of the machine, boot sequence and BIOS/UEFI. h^ͲWh& W>ͲWh&ƵƚŚ ŝƌĐƵŝƚ
ĞǀŝĐĞ W>ͲWh&
C. Secure Boot
Although trusted boot can measure platform integrity, it
Fig. 1. DeviceVeil design overview.
cannot prevent kexec and reinstallation attacks (even if the
disk remains encrypted). UEFI secure boot [81] can be used DeviceVeil authenticates a legitimate USB device with PUF,
to prevent booting unauthorized kernels (e.g., not signed and then exposes it to the OS, as pre-OS authentication. The
by a trusted authority). Secure boot requires two keys and pre-OS authentication can be implemented in two options.
two databases. The Platform Key (PK), typically set by the 1) Hosting the cryptographic key: the key created by PUF
manufacturer, is the encryption key for the Key Exchange is stored in a verifier on a host PC that is used to create
Key (KEK). KEK is the encryption key for Authorized DB ciphertext from plaintext on demand. The drawback is
(db) and Unauthorized DB (dbx), which are databases for that the key is disclosed if the verifier is compromised.
public-keys issued by a CA, and include hashes for authorized 2) Database for plaintext and ciphertext: The verifier does
and unauthorized modules (e.g., bootloaders, hypervisors or not have the cryptographic key created by PUF, but it
kernels). Unfortunately, most PCs do not allow customizing has a database of plaintext and ciphertext pairs created
the keys and databases of secure boot. As a workaround, many by the key. This prevents key disclosure but requires the
Linux distributions use a pre-bootloader signed by Microsoft database to be created in advance.
(e.g., Fedora’s shim.elf [55]).
We use option (2) to avoid storing a long term key, and
D. Virtualization Technology (Hypervisor) to restrict the misuse of a challenge-repose pair exposed
via e.g., USB bus sniffing (each pair is used once). Also,
Most secure hypervisors function as the trusted computing if the challenge-repose pairs are different on each PC, the
base (TCB) to protect a guest OS. Some solutions leverage compromise of a PC with its database has limited impact on
trusted computing, and guarantee the chain of trust starting the device’s authentication (e.g., the device can be safely used
from power-on. For example, HyperSentry [4] and Hyper- in other PCs). If the hypervisor selects option (1) hosting
Safe [79] protect the hypervisor itself, and TrustVisor [38] cryptographic/PUF key, it must select a different encryption
and SecVisor [53] protect the hypervisor, guest kernel and ap- key, generated by PUF circuits of a device. The different
plications. However, they are not secure against reinstallation encryption key generates different ciphertext at each time on
and kexec attacks. Unauthorized loading kexec kernels can be each PC and can limit USB bus sniffing attacks. However, keys
avoided by disallowing the kexec syscall in the allowed/signed generated by PUFs for all PCs need to be tested for correctness
kernel, and reinstallation attacks can be prevented by secure because PUFs are sensitive to noise.
boot. However, secure boot is not used by common hypervi-
sors, possibly because most PCs do not allow changing the A. Pseudo-LFSR PUF (PL-PUF)
keys and databases in the UEFI. Fortunately, a few PCs (e.g.,
DeviceVeil customizes Pseudo-LFSR PUF (PL-PUF [24]) to
Lenovo ThinkPad T460s) allow customizing secure boot, and
avoid shortcomings of current PUF technologies. PL-PUF is a
DeviceVeil’s prototype takes advantage of such flexibility.
delay-based PUF but outputs multiple and variable responses.
V. D ESIGN OF D EVICE V EIL The structure is based on the Linear Feedback Shift Register
(LFSR). PL-PUF composes larger combinational logic than
DeviceVeil authenticates individual USB devices using normal delay-based PUFs, and it efficiently outputs multiple
PUFs and offers robustness against inside attackers. Figure 1 bits in parallel used for variable ID. However, the size of the
shows DeviceVeil’s components. DeviceVeil unseals a key PL-PUF authentication circuit is reasonably small compared
from the TPM and decrypts the encrypted disk to boot the OS. to memory-based PUFs. Furthermore, the challenge-response
The DB for USB device detection and PUF authentication is mapping of PL-PUF is variable, depending on the active
also decrypted by the key in the TPM. The hypervisor and OS duration of the circuit, i.e., a single PL-PUF behaves as if
kernel are authenticated by the secure boot. it has multiple PUF cores.

306

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 C. Hypervisor with TPM and Secure Boot
128 127 126 102 101 100 99 1
        To avoid bypassing DeviceVeil’s protection, we encrypt
Dout Dout Dout Dout Dout Dout Dout
the partition of the OS and seal the encryption key in
[128] [127] [126] [102] [101] [99] [1] TPM NVRAM, accessible only to DeviceVeil (loaded via
Dinit SEL trusted boot). Thus, the OS cannot boot without loading
)HHGEDFNSRO\QRPLDO
Dout
the unmodified DeviceVeil binary. Note that although the
x128 + x126 + x101 + x 99 + 1 Din
encryption key stays in RAM, only the hypervisor has access
LFSR_core to it (i.e., making it unavailable to the OS, or OS-resident
memory extraction tools).
Fig. 2. The structure of PL-PUF authentication circuit (128 bits). It consists
of 128 inverters and 3 XOR gates and creates a feedback polynomial.
Even if trusted boot measures platform integrity and the disk
is encrypted by a TPM-protected key, a reinstallation attack
Figure 2 shows the structure of our 128-bit PL-PUF with is still possible (i.e., kexec). DeviceVeil compensates this
the primitive feedback polynomial. The core logic is not a problem with UEFI secure boot, by disallowing unauthorized
register but an inverter, and thus our PL-PUF is composed of kernels. An administrator can customize a secure boot to spec-
a single combinational circuit. The output will oscillate since ify legitimate kernels with no kexec support (allowing updates
the output of the last core (Dout(1)) is fed back to the top-most for properly signed kernels). However, the hypervisor must
core. The output value depends on the speed of the feedback be updated with the active participation of the administrator
signal, which is significantly affected by the device variation. (to set up the trusted boot to extract/reseal the encryption
As a result, the output is device-dependent. PL-PUF realizes a key in TPM). We assume our thin hypervisor will require
challenge-response pair as shown in Figure 2. The challenge updates very infrequently (unlike an OS kernel). Note that,
is a 128-bit initial value given to the core logic (Dinit), and the possibility of an I/O virtualization attack is restricted by
the response is a 128-bit output from the core logic (Dout) the fact that DeviceVeil is loaded first, and it occupies CPU
after a certain time of feedback. virtualization, and thus other kernels cannot override it.
PL-PUF creates a multiple bit response that is prone to
D. Deployability
burst errors. DeviceVeil uses the Reed-Solomon (RS) error
correction for the fuzzy extractor to deal with burst errors. DeviceVeil mostly uses security mechanisms included in
For authentication, DeviceVeil uses a temporal database of many commodity PCs (e.g., TPM, secure boot, and virtual-
plaintext and ciphertext pairs generated by using AES (the ization) to help deployability. Although not all consumer PCs
AES key is created by PL-PUF to avoid the leakage of the come with these components, but enterprise IT admins can buy
key). The plaintext and ciphertext pairs are created with the PCs with appropriate support. In addition, DeviceVeil requires
AES key in advance by the administrator for each individual new hardware “PUF” (similar to several other smart USB
device. Also, each challenge-response pair should be used only solutions such as [7], [67]). For the novel PUF-authentication
once to prevent USB bus sniffing attacks. mechanism, we limit the PUF cost to be reasonable (approx.
under 1 USD), to include a broad set of USB devices.
The cost of maintenance depends on the usage model. To
B. Hypervisor with USB-PUF authentication allow administrators to remotely manage the allowed list of
DeviceVeil is designed on top of BitVisor [56], a type- devices (i.e., DeviceVeil’s protected database) on a client PC,
1 thin hypervisor. BitVisor is based on a para-pass-through DeviceVeil must mandate strong authentication of admin ma-
architecture and does not prevent hardware interrupts from chines/accounts (e.g., via remote attestation). This extra effort
the USB ports to the OS. Therefore, DeviceVeil disguises a is necessary for scalability if devices are added/removed fre-
dummy device to the OS until the USB-PUF authentication quently. If the authorized devices are changed infrequently, the
is completed in the isolated hypervisor environment. The simple per-PC/device deployment may also be reasonable. Our
isolated environment also hosts a database with device records prototype implementation follows this usage scenario. Note
used for USB device detection and challenge-response pairs that current DeviceVeil allows users to update the kernel with
(i.e., ciphertext and plaintext pairs) used for PUF authen- a proper signature, and thus makes updates easy to deploy.
tication. The database is also encrypted by a TPM-sealed
VI. I MPLEMENTATION
key, and an inside attacker (e.g., the user of the machine)
cannot access this key; the key and the plaintext (decrypted) DeviceVeil’s hypervisor is implemented on BitVisor [56]
database are available only to DeviceVeil’s hypervisor, and with DeviceDisEnabler [62] (parts of TPM management),
inaccessible from the OS. and USB-PUF authentication is implemented on Zuiho [87]
We enforce PUF authentication by default. To support non- which is a platform for PUF security evaluation. Newly added
PUF USB devices as an exception, an administrator can con- and deleted code for DeviceVeil are about 6,000 and 500
figure DeviceVeil to use only vendor ID, product ID, class ID, LOC respectively. The main part of the added code is PL-
and serial number. This weak authentication can co-exist dur- PUF authentication. Note that, DeviceVeil’s TCB also contain
ing the transition, but we strongly advise against relying on it. libFTDI (unmodified: 55,000 LOC).

307

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 TABLE I Input to 3/38)$XWKHQWLFDWLRQ&LUFXLWV Output from
R ESOURCES USED BY PL-PUF CIRCUITS . R ESOURCES ARE S LICE OF RS232C ⋈ 8SSHUELWV RI38)5HVSRQVH ⋉ 7KH NH\ LV HQFRGHGE\ RS232C
over USB 5HHG6RORPRQFRUGLQJ over USB
FPGA, L OOK U P TABLE (LUT), F LIP F LOP (FF), B LOCK RAM (BRAM) %HFRPHVDNH\
56
challenge 128 128
AND OPERATION TIME (μ SEC ). ⋇ 6HQGFKDOOHQJH 3/38)
&RGLQJ
⋌ 6DYHKHOSHU
SODLQWH[W DQG DQGFLSKHUWH[WWR
128 128
HQFU\SWLRQVLJQDOZLWK '%
Slice LUT FF BRAM μsec 56&RYHU86% response helper

6HWXS7RRO 6HWXS7RRO
PL-PUF 130 260 256 0 0.33 128
⋊ /RZHU  ELWV
56
RS Enc 181 333 236 2 1.37 &KDOOHQJH
128
'HFRGLQJ RI38)UHVSRQVHDUH
H[FOXVLYH25HG E\
&KDOOHQJH
+HOSHU
RS Dec 7,990 15,086 2,323 1 23.17 UHGXQGDQW V\PEROV
RI56FRUGLQJ 7KH
&LSKHUWH[W
SODLQWH[W SODLQWH[W
AES 2,774 5,405 812 0 0.58(Enc)/1.08(Dec) YDOXHEHFRPHV
‫ ڬ‬1 +HOSHU
Total 12,774 21,459 6,282 7 25.44(Enc)/25.94(Dec) :LQGRZV :LQGRZV
enc/dec key
$(6
plaintext (1&嵣'(& ciphertext
⋋ 3ODLQWH[WLVHQFU\SWHGE\WKHNH\
A. Zuiho PL-PUF Authentication Circuits
Fig. 3. Setup Tool (Enrollment) and PL-PUF authentication circuits. Light
The Zuiho board comes with an FPGA chip, Spartan-3A gray circuits are not used by enrollment.
DPS3400A, and our PL-PUF authentication circuits are im-
plemented on it. The circuits consist of PL-PUF, RS encoding, Input to
3/38)$XWKHQWLFDWLRQ&LUFXLWV
Output from
RS232C RS232C
RS decoding, AES encryption/decryption, etc. The circuits over USB
⋎ ELWVRI38)UHVSRQVH over USB
56
for PL-PUF are based on [24], and the RS encoding and challenge
3/38)
128
&RGLQJ
128

*XHVW 26 *XHVW 26
decoding utilize MATLAB Communication Toolbox and HDL 128 128

+\SHUYLVRU response +\SHUYLVRU

Coder. For AES encryption/decryption, we utilize the open 'HYLFH9HLO
128
'HYLFH9HLO
56
source Verilog code offered by the Cryptographic Hardware &KDOOHQJH
helper 'HFRGLQJ ⋐ 56GHFRGLQJ
128
&KDOOHQJH
H[WUDFWVWKH NH\
+HOSHU +HOSHU
Project [3]. In Table I, we list the hardware resources used &LSKHUWH[W
SODLQWH[W
⋏ /RZHU  ELWVDUH
H[FOXVLYH25HG E\KHOSHU
&LSKHUWH[W
SODLQWH[W
‫ ڬ‬1
by PL-PUF authentication circuits; Logic Block resources DQGWKHYDOXHEHFRPHV
UHGXQGDQW V\PEROVRI56
key Verify
FRUGLQJ $(6
include: Slice, Look Up Table (LUT), Flip Flop (FF), and enc/dec
ciphertext
(1&嵣'(& plaintext

Block RAM (BRAM). ⋍ 6HQGFKDOOHQJH ⋑ &LSKHUWH[W LV GHFU\SWHGE\WKHNH\ ⋒ WKHRXWSXW

KHOSHUFLSKHUWH[W DQG SODLQWH[W LV
1) Cost of PUF: To evaluate the cost, the size of PL-PUF HQFU\SWLRQVLJQDOZLWK
56&RYHU86%
FRPSDUHG E\ WKH
SODLQWH[WLQWKH'%

authentication circuits is compared to the TPM implementation

on FPGA [14], [15]. Eisenbarth et al. [15] assume 3,000 Fig. 4. DeviceVeil authentication (verification of the hypervisor) and PL-PUF
authentication circuits. Light gray circuits are not used in authentication.
Logic Elements (each element consists of a single 4-input
LUT connected to a single-bit flip-flop) and 75k RAM. Eguro
and Venkatesan [14] assume 27,237 LUTs, 27,076 FFs, and database generation procedure using the setup tool. It runs on
49 BRAMs. These circuit sizes of TPM implementations are Windows and communicates with the PL-PUF authentication
significantly larger than the current implementation of PL- circuits using RS232C protocol over FTDI-USB serial. As
PUF authentication; see Table I. Furthermore, the current prerequisite data, the setup tool has challenge data for PL-PUF
implementation of RS encoding/decoding uses the MATLAB and plaintext for encryption/decryption by the key created by
Communication Toolbox and HDL Coder, which are not the PL-PUF. The steps are as follows.
optimized. We can reduce these parts with custom code. We 1) The setup tool sends a challenge (256 bits), plaintext, and
estimate the price of PL-PUF based on the size of the circuit encryption signal to the PL-PUF authentication circuits
is less than 1 US dollar because the price of TPM is estimated with RS232C protocol over USB.
to be 1 US dollar [31] (from 2006). Furthermore, PL-PUF will 2) The challenge goes to PL-PUF and becomes a 256-bit
be integrated into the circuits in a USB IC and does not require response. The upper half (128 bits) of the response is
additional tamper-proof mechanism as a TPM chip; i.e., the used as the encryption key.
cost will be even lower. Thus, price-wise, PL-PUF should not 3) The key is encoded by Reed-Solomon error correction
be an issue for most USB devices. Especially, DeviceVeil is code, and 128 redundant bits are generated (16 symbols).
assumed to be used in enterprise environments, which can 4) The redundant RS symbols are masked (XORed) with
absorb the extra cost for security gain. the lower half (128 bits) of the PUF response so that the
2) Setup and Authentication: PL-PUF authentication cir- redundant symbols do not leak any secret. The masked
cuits are set up by a tool we call PUF-Acquisition, which value is used as helper data, which is outputted to the
works as a database enrollment tool on Windows. The database setup tool.
is used by PUF authentication in the hypervisor. The setup tool 5) Inputted plaintext is encrypted by the encryption key. The
and hypervisor use USB-UART interface to communicate with ciphertext is outputted to the setup tool.
the PUF. The procedures of the Setup Tool (Enrollment) and 6) The setup tool saves the helper and ciphertext values to
DeviceVeil authentication (hypervisor’s verifier) are explained the DB for PUF authentication.
below. Note that we assume that suitable challenge data is
selected to generate a robust key. DeviceVeil Authentication (Verification of the Hypervisor):
Figure 4 outlines the PL-PUF authentication procedure. The
Setup Tool (Enrollment): Figure 3 outlines the PL-PUF DeviceVeil hypervisor sends a challenge, helper, and ciphertext

308

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 TABLE II 'ƵĞƐƚ K^ ĞǀŝĐĞsĞŝů ŚLJƉĞƌǀŝƐŽƌ h^ͲWh&ĞǀŝĐĞ
T HE INPUT DATA STRUCTURE FOR D EVICE V EIL’ S DB, USED FOR USB ƚƚĂĐŚ
DEVICE DETECTION AND PUF AUTHENTICATION . C ATEGORIES OF
VERIFICATION , FLAGS , AND OPTIONS ARE SHOWN . ZĞƐĞƚ WĂƐƐdŚƌŽƵŐŚ
^ĞƚĚĚƌĞƐƐ ,ŽŽŬ
Category Flag (1 byte) Options when the flag is on. ^ĞƚĚĚƌĞƐƐ
'ĞƚͺĚĞƐĐƌŝƉƚŽƌ;ĚĞǀŝĐĞͿ
ZĞƚƵƌŶ
Vendor ID 1=on,0=off Vendor ID 2 bytes ĞǀŝĐĞŝƐ ĞǀŝĐĞĞƐĐƌŝƉƚŽƌ
tŚĞŶƚŚĞĚĞǀŝĐĞŝƐĂ
Product ID 1=on,0=off Product ID 2 bytes ƌĞŐŝƐƚĞƌĞĚŽƌŶŽƚ
ƌĞŐŝƐƚĞƌĞĚh^ͲWh&
Class ID 1=on,0=off Class ID 2 bytes 'ĞƚͺĚĞƐĐƌŝƉƚŽƌ;ĐŽŶĨŝŐƵƌĂƚŝŽŶͿ
ZĞƚƵƌŶ
ĚĞǀŝĐĞ
Sub-Class ID 1=on,0=off Sub-Class ID 2 bytes ^ĞƚŽŶĨŝŐƵƌĂƚŝŽŶ ŽŶĨŝŐƵƌĂƚŝŽŶĞƐĐƌŝƉƚŽƌ

Serial Number 1=on,0=off Serial Number (Unicode) 18 bytes ĞǀŝĐĞsĞŝů ƐĞƚƐƵƉĂh^ĞǀŝĐĞ

PUF Info 1=on,0=off Challenge 32 bytes
Challenge #2 16 bytes 'ĞƚͺĚĞƐĐƌŝƉƚŽƌ;ĚĞǀŝĐĞͿ
Helper 16 bytes ZĞƚƵƌŶ
'ĞƚͺĚĞƐĐƌŝƉƚŽƌ;ĐŽŶĨŝŐƵƌĂƚŝŽŶͿ ƵŵŵLJ ĞǀŝĐĞĞƐĐƌŝƉƚŽƌ
Ciphertext 16 bytes ZĞƚƵƌŶ
Plaintext 16 bytes ^ĞƚŽŶĨŝŐƵƌĂƚŝŽŶ
ŽŶĨŝŐƵƌĂƚŝŽŶĞƐĐƌŝƉƚŽƌ

'ƵĞƐƚK^ƐĞƚƐ ƵƉƵŵŵLJh^ŬĞLJďŽĂƌĚ
Wh&ƵƚŚĞŶƚŝĐĂƚŝŽŶ
to the Zuiho board, and verifies the received plaintext. The
ŝƐĐŽŶŶĞĐƚ
steps are as follows. ZĞƐĞƚ ZŽŽƚ ,Ƶď
ƵŵŵLJh^
<ĞLJďŽĂƌĚ ŝƐĐŽŶŶĞĐƚ
7) DeviceVeil sends challenge, helper, and ciphertext to the
ƚƚĂĐŚ
PL-PUF authentication circuits in the USB device.
ZĞƐĞƚ
8) The challenge goes to PL-PUF and becomes a 256-bit ^ĞƚĚĚƌĞƐƐ
response. 'ĞƚͺĚĞƐĐƌŝƉƚŽƌ;ĚĞǀŝĐĞͿ ZĞƚƵƌŶ
ĞǀŝĐĞĞƐĐƌŝƉƚŽƌ
9) The helper data is XORed with the lower 128 bits of WĂƐƐdŚƌŽƵŐŚ
'ĞƚͺĚĞƐĐƌŝƉƚŽƌ;ĐŽŶĨŝŐƵƌĂƚŝŽŶͿ
the PUF response, resulting in the unmasked redundant ZĞƚƵƌŶ
ŽŶĨŝŐƵƌĂƚŝŽŶĞƐĐƌŝƉƚŽƌ
^ĞƚŽŶĨŝŐƵƌĂƚŝŽŶ
symbols (with several errors) of the RS code.
10) The upper 128 bits of the response and redundant symbols 'ƵĞƐƚK^ƐĞƚƐƵƉh^ͲWh&ĞǀŝĐĞ
go through RS decoding and generate the encryption key.
11) The ciphertext is decrypted by the encryption key. Fig. 5. Pre-OS USB device detection on DeviceVeil (between the Guest OS
12) The output plaintext is compared to the plaintext in and a USB-PUF device)
the DB for PUF authentication. When the comparison 2) Procedure of Pre-OS USB Detection: Figure 5 shows
succeeds, DeviceVeil exposes the actual USB device to the procedure for pre-OS USB device detection by DeviceVeil
the OS; when failed, the USB device remains hidden. hypervisor. When a USB device is inserted, the “Attach”
hardware interrupt occurs. Due to BitVisor’s para-pass-through
3) Creating DB for USB Device Detection and PUF architecture, the OS is informed about the insertion, and
Authentication: We summarize the input data structure used DeviceVeil disguises a dummy device until PUF authentication
by our pre-OS USB device detection and PUF Authentication is completed. After the “Attach” interrupt, the OS follows
in Table II. Device meta-data is stored in the DB during setup the normal procedure to detect a USB device. The OS waits
(Enrollment), encrypted by a TPM-stored key accessible only a certain period (about 100 msec) and issues the “Reset”
by the hypervisor (see Figure 1). We use the stored device command. Then the USB device comes to the “default”
information (e.g., vendor ID, product ID, class ID, and seal state and can accept control commands. After that, the “Set
number, provided by the Get descriptor() function) in the Address” command is issued from the OS to the USB device;
DB for pre-OS device detection. We get the PUF challenge- however, this request is overtaken by DeviceVeil, which issues
response pairs from the Setup Tool (Enrollment) described in its own “Set Address” command to the USB device. The USB
Section VI-A and store them in the DB for PUF authentication. device then comes into the “address” state.
DeviceVeil sends Get descriptor(device) to the device to
B. Device Detection by Hypervisor
get device descriptor (e.g., vendor ID, product ID, class ID,
DeviceVeil is based on the para-pass-through architecture serial number). If the device is a registered USB-PUF device,
of BitVisor and does not prevent hardware interrupts to the DeviceVeil offers a dummy harmless USB keyboard to the
OS when a USB device is inserted, but DeviceVeil responds OS and attempts the PUF authentication process. If the device
with a dummy USB device during USB-PUF authentication. is a registered non USB-PUF device (if explicitly allowed
1) Communication Structure: We add a USB device detec- by administrators during the transition), DeviceVeil allows
tion process to BitVisor’s libUSB compatible interface and para-pass-through access from the OS immediately. Otherwise,
use libFTDI as the FTDI driver. When a USB device is DeviceVeil just offers a dummy device to the OS.
detected, DeviceVeil plays the role of a USB host, and the For legitimate PUF-enabled devices, DeviceVeil al-
PUF authentication process communicates with the PL-PUF lows the OS to continue the USB device recognition
circuits with the RS232C protocol on USB-FTDI. procedure. The OS sends Get descriptor(device) and

309

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 TABLE III
C OMPARISON BETWEEN D EVICE V EIL AND RELATED PROPOSALS

USB 3.0 Active GoodUSB Cinch USBFILTER Kells ProvUSB DeviceVeil

Type-C [72] Directory [66] [2] [68] [7] [67]
Individual No No Serial No No No No PUF
Device Auth. Number
Additional Tamper-proof No No No No ARM ARM PUF
Hardware storage in USB in USB in USB in USB
(Spec-only)
Granularity Device Device Device Packet Packet Device Device Device
Overhead Insert Insert Insert Comm. Comm. Insert Insert Insert
time time time time time time time time
Isolation No No No Yes No No No Yes
QEMU/KVM BitVisor
OS dependence No Yes Yes No Yes Yes Yes No
Tamper-proof (Good (Partial (Partial (Partial (Good (Good (Good (Good on
and hardening on USB) on host) on host) on host) on host) on host) on host) host&USB)
(Spec-only) Privilege In In Trusted Boot TPM TPM Trusted Boot
Tamper-proof mode Kernel Hypervisor SELinux Auth. Auth. Secure Boot
Storage PUF

Get descriptor(conf iguration), but DeviceVeil hooks them To customize secure boot for DeviceVeil and the OS, the
and responds with a dummy USB device. After the OS recog- Platform Key, Key Exchange Key, Authorized DB, and Unau-
nizes a dummy USB device, DeviceVeil initiates the PL-PUF thorized DB must be replaceable. We use ThinkPad T460s
authentication process (Section VI-A). If authentication fails, (Intel i5-6300U 2.4GHz) as ThinkPad T400 does not offer
no other action is taken (the OS only sees the dummy USB secure boot. On the other hand, ThinkPad T460s does not have
keyboard that processes no input). If authentication succeeds, TPM 1.2. We thus have to use both these machines for testing
DeviceVeil issues the “Reset” command to the USB root hub our prototype (which of course can be integrated into a single,
of the PC. The root hub raises the “Disconnected” interrupt, compatible PC). The UEFI of T460s allows customizing the
which goes to the OS. The OS recognizes that the dummy Platform Key, Key Exchange Key, Authorized DB, and Unau-
USB device is removed and takes action for disconnection. thorized DB. In order to boot Linux, we used shim.elf [55],
Afterward, the USB device issues the “Attach” interrupt a pre-bootloader for GRUB bootloader, hypervisor, and the
automatically, which is sent to the OS to establish a USB Linux kernel.
connection normally. From this time, DeviceVeil forwards all
requests as para-pass-through. VII. E VALUATION
If authentication fails, DeviceVeil does not take any further We compare DeviceVeil with existing solutions, evaluate
action. The OS keeps the dummy USB keyboard, which it against two types of attacks, and measure the performance
processes no input. When the real USB device is disconnected, overhead.
the dummy USB keyboard is also removed in the manner of
USB disconnection. A. Comparison
Table III summarizes the comparison of related proposals
C. Customizing Trusted/Secure Boot
with DeviceVeil. Individual USB authentication is achieved
The OS disk partition is separated from the disk partition by GoodUSB and DeviceVeil. However, GoodUSB depends
for booting DeviceVeil. The OS partition is encrypted by on serial numbers, which can be easily modified. DeviceVeil
DeviceVeil using the encryption key sealed in the TPM (i.e., uses PUF for individual USB authentication, which ties the
unsealed only when the PCR values indicate that unmodified authentication process with physical IC characteristics of the
trusted boot and DeviceVeil have been loaded). The current USB device. Kells and ProvUSB do not offer individual USB
implementation is designed for TPM 1.2 on a ThinkPad authentication, but they offer individual host authentication
T400 (Intel Core2 P8400 2.26GHz) and uses TCG-BIOS and and can be combined with individual USB authentication
TrouSerS [71]. We use the TPM NV DefineSpace command (i.e., DeviceVeil) to achieve mutual authentication. Additional
to allocate the NVRAM space for the encryption key, bounded hardware requirement is imposed by USB 3.0 Type-C, and
by PCR[0-7] (TCG-BIOS) and PCR[12-14] (Trusted GRUB) Kells, ProvUSB, and DeviceVeil. Although the cost is cheap
values. The TPM NN WriteValue command is used to write on Type-C and DeviceVeil; Kells and ProvUSB require a
the encryption key to NVRAM with these PCR values during processor for TPM authentication. Granularity is divided into
the setup stage. The TPM NV ReadValue command is used to device level (authenticates a USB device at insert time, causing
read the encryption key. The read operation is successful only one-time, low overhead), and packet level (verifies all com-
when the bounded PCR values are the same as the registered munication traffic, causing significant runtime overhead). De-
values. After that, DeviceVeil decrypts the OS disk partition viceVeil imposes overhead only at insert-time similar to other
and boots the OS. implementations except for Cinch and USBFILTER; however,

310

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 only DeviceVeil offers individual device authentication. Cinch Note that the OS kernel and hypervisor can be made
and USBFILTER incur overhead for each packet transferred independent of BIOS/UEFI using DRTM (Dynamic Root of
between a USB device and the host (38% for Cinch and 17.6% Trust Measurement, such as Intel TXT; cf. [85]). The DRTM
for USBFILTER). Cinch and DeviceVeil both use hypervisor of GraceWipe utilizes tboot [65] which depends on Intel TXT
for stronger isolation. Type-C, Cinch, and DeviceVeil are OS- (Trusted eXecution Technology) and resets the trust chain.
independent: Type-C is a standard, and Cinch and DeviceVeil GraceWipe uses the secret key stored in the TPM, which is
use a hypervisor to run an independent OS. Tamper-proofing sealed/unsealed by the PCR[17] that is measured by tboot only.
is achieved by USBFILTER and DeviceVeil: USBFILTER The method allows being independent of the measurement
protects the host with trusted boot and SELinux; DeviceVeil from the BIOS/UEFI. However, DeviceVeil cannot depend on
protects the hypervisor and the host with trusted boot, and the DRTM alone, because secure boot and I/O virtualization can
USB device with PUF. Overall, DeviceVeil offers comprehen- be reset if the BIOS/UEFI is compromised. If secure boot is
sive security at low cost. turned off in BIOS, re-installation attacks become possible. If
the I/O virtualization is on, a virtual machine may access it
B. Attack resistance through IOMMU.
We have tested DeviceVeil against two real-world attacks:
BadUSB and MTP attack. For BadUSB, we used the code B. Attacks on Hypervisor
from Caudill [8]. The target USB controller is Phison Electron- Hypervisors also suffer from vulnerabilities [45], [64]. Since
ics Phison 2251-03 (2303), included in Toshiba TransMemory- DeviceVeil is a type-I hypervisor and runs only one OS,
MX USB 3.0 16GB. BadUSB customizes the firmware on the the attack surface for DeviceVeil is significantly smaller than
USB controller and disguises it as a keyboard (HID). How- normal hypervisors with multiple OSes (e.g., Xen). Similarly,
ever, this malicious BadUSB keyboard is not recognized by cross-VM side-channel attacks [84] are also not a concern.
DeviceVeil, and the attack fails. For the MTP attack, we used DeviceVeil is based on the para-pass-through architecture and
ASUS XenPad 3. Without DeviceVeil, XenPad 3 is detected as thus, does not suffer from attacks through virtual devices, e.g.,
an MTP device, and the file system for MTP jmtpfs is opened. VENOM [76] (a vulnerability of floppy emulator in QEMU).
However, with DeviceVeil, the device is not recognized. However, DeviceVeil also depends on CPU virtualization
technologies (i.e., Intel VT-x) as other hypervisors, and may
C. Performance
be vulnerable if there are vulnerabilities in such technologies.
We measured the performance of USB-PUF authentication
100 times on ThinkPad T400. The average time for USB-PUF C. Attacks on TPM
authentication was 1.705sec (min 1.683sec, max 1.729sec, In contrast to BIOS attacks, DeviceVeil does not care for
and std. deviation 0.110sec). For regular use, this delay for TPM attacks because they disable booting causing a disadvan-
authentication appears to be acceptable, considering USB tage for the attacker, especially for the insider. Even if a side-
insertion is a manual process. channel attack is possible, the creation of certain PCR values is
The target machine is old (Intel Core2 Duo P8400 2.26 difficult. In a TPM reset attack [29], [58], a TPM’s LRRESET
GHz) and low performance (Average CPU Mark 1455 [12]). pin is grounded and initializes PCR values. However, it is still
If we can use current relevant machine (ThinkPad T580 difficult to guess the PCR values to extract the key.
with Intel Core i5-8350U 1.70GHz, Average CPU Mark
8189 [11]), we can get better performance because CPU D. Attacks on Secure Boot
performance is improved by more than 5 times. We know that As mentioned in Section II, kexec can bypass the se-
the CPU improvement does not affect the latency directly, cure boot as kexec can load unauthorized kernels bypassing
but the latency can be estimated less than 1 seconds from 1.7 BIOS/UEFI and bootloader [47]. DeviceVeil prevents this
seconds (2 times). After authentication, the USB device is attack by using a non-kexec kernel, certified by secure boot.
accessed as para-pass-through, and thus, incurs no overhead. Note that, secure boot could be bypassed by exploiting vul-
VIII. S ECURITY A NALYSIS nerabilities in UEFI implementation [17]. The administrator
must use an up-to-date, secure UEFI BIOS.
A. Attacks on BIOS/UEFI
DeviceVeil relies on virtualization, TPM, and secure boot, E. Attacks on Memory
all of which are set up through BIOS/UEFI. Thus the se- The encryption key from the main memory may be extracted
curity of BIOS/UEFI is critical, but some old BIOSes come by DMA Attacks [54], [60] or cold-boot attacks [22]. These at-
with default/well-known passwords, which also can be reset tacks take the memory dump image and search for secret keys
by jumper settings when physical access is possible. With (e.g., loaded from a TPM). However, they can be addressed by
improved BIOS/UEFI security in recent times, attacks also relocation of secret keys from RAM to other (relatively) safer
became more sophisticated. For example, the System Manage- places, such as SSE registers (AESSE [40]), debug registers
ment Mode (SMM) and sleep mode S3 have been exploited (TRESOR [39]), MSR registers (Amnesia [57]), and AVX
in several attacks (e.g., [17], [26], [82]). Fortunately, these registers (PRIME [18]), GPU registers (PixelVault [75]). Keys
vulnerabilities are also often promptly patched by vendors. and secrets in RAM can also be protected by other hardware

311

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 security features in CPUs, such as Intel TSX (Mimosa [21]), G. Attacks on USB BUS
and and Intel TXT/AMD SVM (Hypnoguard [86] during ACPI USB bus has no encryption and is easily sniffed by a USB
S3 suspension). Note that Intel SGX (Software Guard Exten- protocol analyzer. The lost information (e.g., a key) can be
sions) is inapplicable to DeviceVeil although SGX offers en- used for replay attack or forged authentication [42]. These
crypted memory and isolated execution, as we require device- attacks are not prevented by hardware tamper-proof on a USB
level access (ring-0) from the trusted environment (i.e., our device for secret-hiding protection. One solution is encryption
hypervisor), but SGX allows only ring-3 (user level) privilege. of communication, but managing keys for such encryption
Memory attacks can also be launched via software side- will be non-trivial and possibly subject to compromise. Even
channels (e.g., cross-VM side-channel attacks). A disk encryp- if an encryption key is shared to authenticate a device by
tion key is managed by DeviceVeil and stored in the memory some PCs, all PCs must renew the key when a PC loses it.
allocated to DeviceVeil. DeviceVeil is a type-I hypervisor However, PUF allows creating different keys from a device for
and runs one OS only, and therefore cross-VM side-channel each authentication [41]. The administrators can set a different
attacks (e.g., [84]) from the host OS and memory leaks are key on each PC. Current DeviceVeil uses the database for
not applicable to DeviceVeil. However, DeviceVeil’s threat challenge-response, but it can replace the key created by PUF.
model also includes a malicious insider. Such an attacker DeviceVeil (hypervisor) issues a “Reset” command to a
can use hypervisor forensics tools (e.g., Actaeon [20]) to USB device after the PUF authentication phase and the USB
detect hypervisor from the use of VMCS (Virtual Machine device is visible to the Guest OS via para-pass-through. After
Control Structure) of Intel VT-x. Actaeon requires a memory PUF authentication, an attacker may attempt to replace the
dump image, but a pure software approach cannot capture authenticated USB with an illegitimate USB device (i.e., a kind
the memory properly, according to Graziano et al. [20], who of time-of-check to time-of-use, TOCTOU race condition).
suggested using SMM based memory scanners (e.g., [48]). However, the USB host controller on the PC detects the physi-
However, SMM is protected by the security of BIOS/UEFI, cal disconnection of a USB device. DeviceVeil is also aware of
which is assumed to be secure by DeviceVeil. the physical disconnection and the PUF authentication starts
from the beginning for the newly inserted device.

F. Attacks on PUF
H. Legacy Devices
General PUF circuits are passive devices and do not keep a For backward compatibility, some users may want to use
state. They are vulnerable to replay attacks. If the DB in the legacy devices. DeviceVeil offers authentication for legacy
hypervisor of DeviceVeil is disclosed, the data can be exploited devices, but it depends on vulnerable serial numbers. Adminis-
to allow unauthorized devices. The current implementation of trators must evaluate risks from such devices before allowing
the DB is protected by encryption (with a TPM-stored key) them, although we strongly recommend using PUF-enabled
and we assume that the TPM and DeviceVeil’s hypervisor are devices only.
free of vulnerabilities. To enable replay protections (against
any disclosed ciphertext-plaintext pairs), we need to use the I. Other concerns
one-time challenge-response [36], a common random seed in DeviceVeil offers strong, one-way device authentication, but
the PUF authentication circuits and verifier [49], or circuits mutual authentication is desirable when the host is untrusted.
hosting a key that is decrypted by a PUF created key [30]. We make the host tamper-proof against unauthorized USB
A more sophisticated impersonation is modeling at- devices and malicious insiders; but it can also integrate host
tacks [50], [51] that emulate PUF software. Modeling attacks authentication technology (e.g., Kells [7]), depending on the
use machine learning to create an algorithm to impersonate the cost and usage scenario.
original PUF. However, this type of attack has two drawbacks.
The first drawback is that the modeling attacks assume that the IX. C ONCLUSIONS
challenge and response pairs of target PUF grow only linearly. DeviceVeil is the first solution that authenticates individual
PL-PUF is based on LFSR that works as a pseudo-random USB devices with hardware-based identification circuit,
number generator, and thus makes it difficult to model the PUF PL-PUF, and hypervisor with a pre-OS authentication
authentication circuits. The second drawback is that modeling mechanism, hardened by TPM and secure boot. It allows
attacks assume that challenge and response pairs are exposed connecting only authenticated USB devices and protects the
directly to attackers. The PL-PUF authentication circuits do trust-by-default OS and user data against camouflage attacks
not offer challenge and response pairs directly. A ciphertext is (e.g., BadUSB), protocol abuses, and unknown USB device
sent with the challenge, and the key in PL-PUF authentication attacks. DeviceVeil requires hardware modification, but the
circuits decrypts it to generate the response. The modeling estimated cost appears to be reasonable (less than 1 US
attacks are improved with side-channel attacks [35], but PL- dollar), and it does not require any on-board processor on the
PUF still has the advantage as it uses complex LFSR circuits USB device. We believe, DeviceVeil offers a low-cost device
and only decrypts the AES ciphertext, which difficulty is the authentication technique, mitigating an important security gap
same level of AES attacks. in existing USB defense solutions.

312

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 R EFERENCES [27] M. Kang and H. Saiedian, “USBWall: A novel security mechanism to
protect against maliciously reprogrammed USB devices,” Information
[1] R. Anderson, M. Bond, J. Clulow, and S. Skorobogatov, “Cryptographic Security Journal: A Global Perspective, vol. 26, no. 4, pp. 166–185,
Processors-A Survey,” Proceedings of the IEEE, vol. 94, no. 2, 2006. 2017.
[2] S. Angel, R. S. Wahby, M. Howald, J. B. Leners, M. Spilo, Z. Sun, A. J. [28] Kanguru’s FlashTrust, “https://www.kanguru.com/storage-
Blumberg, and M. Walfish, “Defending against malicious peripherals accessories/kanguru-flashtrust-secure-firmware.shtml,” 2014.
with Cinch,” in USENIX Security Symposium, 2016. [29] B. Kauer, “OSLO: Improving the Security of Trusted Computing,” in
[3] Aoki Laboratory’s Cryptographic Hardware Project, USENIX Security Symposium, 2007.
“http://www.aoki.ecei.tohoku.ac.jp/crypto/,” 2014. [30] T. Kubota, M. Shiozaki, and T. Fujino, “Robust authentication using
[4] A. M. Azab, P. Ning, Z. Wang, X. Jiang, X. Zhang, and N. C. Skalsky, physically unclonable functions,” in Embedded Security in Cars, ser.
“HyperSentry: Enabling stealthy in-context measurement of hypervisor ESCAR’16, 2016.
integrity,” in Conference on Computer and Communications Security, [31] K. Kursawe, “Trusted Computing and its Applications: An Overview,”
ser. CCS’10, 2010. in Information Security Solutions Europe, ser. ISSE’06, 2004.
[5] BadAndroid, “https://github.com/tst-zdouglas/badandroid,” 2014. [32] D. Kushner, “The real story of stuxnet,” ieee Spectrum, vol. 50, no. 3,
[6] C. Bösch, J. Guajardo, A.-R. Sadeghi, J. Shokrollahi, and P. Tuyls, pp. 48–53, 2013.
“Efficient helper data key extractor on FPGAs,” in Cryptographic [33] J. W. Lee, D. Lim, B. Gassend, G. E. S. andMarten van Dijk, and
Hardware and Embedded Systems, ser. CHES’08, 2008. S. Devadas, “A technique to build a secret key in integrated circuits for
[7] K. R. B. Butler, S. E. McLaughlin, and P. D. McDaniel, “Kells: A identification and authentication applications,” in 2004 Symposium on
Protection Framework for Portable Data,” in Annual Computer Security VLSI Circuits. Digest of Technical Papers (IEEE Cat. No.04CH37525),
Applications Conference, ser. ACSAC’10, 2010. 2004.
[8] Caudill’s-badUSB, “https://github.com/adamcaudill/psychson,” 2014. [34] E. L. Loe, H.-C. Hsiao, T. H.-J. Kim, S.-C. Lee, and S.-M. Cheng,
[9] T. M. Chen and S. Abu-Nimeh, “Lessons from Stuxnet,” Computer, “SandUSB: An installation-free sandbox for USB peripherals,” in 2016
vol. 44, pp. 91–93, 2011. IEEE 3rd World Forum on Internet of Things (WF-IoT), Dec 2016, pp.
[10] CompTIA, “Cyber secure: A look at employee cybersecurity 621–626.
habits in the workplace,” compTIA Whitepaper (2015). [35] A. N. Mahmoud, U. Rührmair, M. Majzoobi, and F. Koushanfar,
https://www.comptia.org/resources/cyber-secure-a-look-at-employee- “Combined modeling and side channel attacks on strong pufs,” IACR
cybersecurity-habits-in-the-workplace. Cryptology ePrint Archive, 2013.
[11] CPU Benchmark Intel Core i5-8350U 1.70GHz. (2017) [36] M. Majzoobi, F. Koushanfar, and M. Potkonjak, “Techniques for design
https://www.cpubenchmark.net/cpu.php?cpu=intel+core+i5-8350u+ and implementation of secure reconfigurable PUFs,” ACM Transactions
%40+1.70ghz&id=3150. on Reconfigurable Technology and Systems, vol. Vol 2, no. 1, 2009.
[12] CPU Benchmark Intel Core2 Duo P8400 2.26 GHz. (2008) [37] K. Mayes and K. Markantonakis, Smart Cards Tokens Security and
https://www.cpubenchmark.net/cpu.php?cpu=intel+core2+duo+p8400+ Applications. Springer, 2008.
%40+2.26ghz&id=973. [38] J. M. McCune, Y. Li, N. Qu, Z. Zhou, A. Datta, V. Gligor, and
[13] Y. Dodis, L. Reyzin, and A. Smith, “Fuzzy extractors: How to generate A. Perrig, “TrustVisor: Efficient TCB reduction and attestation,” in IEEE
strong keys from biometrics and other noisy data,” in International Con- Symposium on Security and Privacy, ser. SP’10, 2010.
ference on the Theory and Applications of Cryptographic Techniques, [39] T. Müller, F. Freiling, and A. Dewald, “Tresor runs encryption securely
ser. EUROCRYPT’04, 2004. outside ram,” in 20th USENIX Security Symposium (USENIX Security
[14] K. Eguro and R. Venkatesan, “FPGAs for trusted cloud computing,” in 11), 2011.
International Conference on Field Programmable Logic and Applica- [40] T. Müller, A. Dewald, and F. C. Freiling, “AESSE: a cold-boot resistant
tions, ser. FPL’12, 2012. implementation of AES,” in the 3rd European Workshop on System
[15] T. Eisenbarth, T. Güneysu, C. Paar, A.-R. Sadeghi, D. Schellekens, Security, 2010.
and M. Wolf, “Reconfigurable Trusted Computing in Hardware,” in [41] M. Nabeel, S. Kerr, X. Ding, and E. Bertino, “Authentication and key
Workshop on Scalable Trusted Computing, ser. STC’07, 2007. management for advanced metering infrastructures utilizing physically
[16] K. B. Frikken, M. Blanton, and M. J. Atallah, “Robust authentication unclonable functions,” in Smart Grid Communications, ser. SmartGrid-
using physically unclonable functions,” in International Conference on Comm’12, 2012.
Information Security, ser. ISC’09, 2009. [42] M. Neugschwandtner, A. Beitler, and A. Kurmus, “A transparent defense
[17] A. Furtak, Y. Bulygin, O. Bazhaniuk, J. Loucaides, A. Matrosov, and against usb eavesdropping attacks,” in European Workshop on System
M. Gorobets, “BIOS and Secure Boot Attacks Uncovered,” (ekoparty), Security, ser. EuroSec’16, 2016.
2014. [43] K. Nohl, S. Krissler, and J. Lell, “BadUSB-On accessories that turn
[18] B. Garmany and T. Müller, “Prime: Private rsa infrastructure for evil,” blackHat USA 2014.
memory-less encryption,” in The Annual Computer Security Applications [44] G. Ose, “Exploiting USB Devices with Arduino,” blackHat USA 2011.
Conference, ser. ACSAC ’13, 2013. [45] D. Perez-Botero, J. Szefer, and R. B. Lee, “Characterizing Hypervisor
[19] GlobalPlatform. https://globalplatform.org/. Vulnerabilities in Cloud Computing Servers,” in Workshop on Security
[20] M. Graziano, A. Lanzi, and D. Balzarotti, “Hypervisor memory foren- in Cloud Computing, 2013.
sics,” in International Symposium on Research in Attacks, Intrusions, [46] A. Pfiffer, “Reducing System Reboot Time With kexec,” OSDL Whitepa-
and Defenses, ser. RAID’13, 2013. per, 2003.
[21] L. Guan, J. Lin, B. Luo, J. Jing, and J. Wang, “Protecting private [47] Phoronix.com, “Secure boot breaks kexec, hibernate
keys against memory disclosure attacks using hardware transactional support on Linux,” news article (Jan. 28, 2013).
memory,” in IEEE Symposium on Security and Privacy, ser. SP’15, 2015. https://www.phoronix.com/scan.php?page=news item&px=MTI4NjE.
[22] J. A. Halderman, S. D. Schoen, N. Heninger, W. Clarkson, W. Paul, J. A. [48] A. Reina, A. Fattori, F. Pagani, L. Cavallaro, and D. Bruschi, “When
Cal, A. J. Feldman, and E. W. Felten, “Least we remember: Cold boot Hardware Meets Software: A Bulletproof Solution to Forensic Memory
attacks on encryption keys,” in USENIX Security Symposium, 2008. Acquisition,” in Annual Computer Security Applications Conference, ser.
[23] S. Han, W. Shin, J.-H. Park, and H. Kim, “A bad dream: Subverting ACSAC’12, 2012.
trusted platform module while you are sleeping,” in USENIX Security [49] M. Rostami, M. Majzoobi, F. Koushanfar, D. S. Wallach, and S. Devadas,
Symposium, Baltimore, MD, USA, Aug. 2018. “Robust and reverse-engineering resilient PUF authentication and key-
[24] Y. Hori, H. Kang, T. Katashita, and A. Satoh, “Pseudo-LFSR PUF: exchange by substring matching,” IEEE Transactions on Emerging
A compact, efficient and reliable physical unclonable function,” in Topics in Computing, vol. 2, no. 1, 2014.
International Conference on Reconfigurable Computing and FPGAs, [50] U. Rührmair, F. Sehnke, J. Sölter, G. Dror, S. Devadas, and J. Schmid-
2011. huber, “Modeling Attacks on Physical Unclonable Functions,” in Con-
[25] K. Ishii and T. Komukai, “A Comparative Legal Study on Data Breaches ference on Computer and Communications Security, ser. CCS’10, 2010.
in Japan, the U.S., and the U.K.” in IFIP TC International Conference [51] U. Rührmair, J. Solter, F. Sehnke, X. Xu, A. Mahmoud, V. Stoyanova,
on Human Choice and Computers (HCC’16), 2016. G. Dror, J. Schmidhuber, W. Burleson, and S. Devadas, “PUF Modeling
[26] C. Kallenberg, J. Butterworth, X. Kovah, and S. Cornwell, “Defeating Attacks on Simulated and Silicon Data,” IEEE Trans. Info. For. Sec.,
signed bios enforcement,” MITRE White Paper, 2014. 2013.

313

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.
 [52] Secure Element (SE) Committee. (2007) [68] D. J. Tian, N. Scaife, A. Bates, K. Butler, and P. Traynor, “Making USB
https://globalplatform.org/technical-committees/secure-element-se- great again with USBFILTER,” in USENIX Security Symposium, 2016.
committee/. [69] D. J. Tian, N. Scaife, D. Kumar, M. Bailey, A. Bates, and K. R. Butler,
[53] A. Seshadri, M. Luk, N. Qu, and A. Perrig, “SecVisor: A tiny hypervisor “SoK: “Plug & Pray” Today – Understanding USB Insecurity in Versions
to provide lifetime kernel code integrity for commodity OSes,” in 1 through C,” in IEEE Symposium on Security and Privacy, ser. SP’18,
Symposium on Operating Systems Principles, ser. SOSP’07, 2007. 2018.
[54] R. Sevinsky, “Funderbolt: Adventures in thunderbolt DMA attacks,” [70] M. Tischer, Z. Durumeric, S. Foster, S. Duan, A. Mori, E. Bursztein,
Black Hat USA, 2013. and M. Bailey, “Users really do plug in USB drives they find,” in IEEE
[55] Shim, “https://github.com/rhinstaller/shim,” 2015. Symposium on Security and Privacy, ser. SP’16, 2016.
[56] T. Shinagawa, H. Eiraku, K. Tanimoto, K. Omote, S. Hasegawa, [71] TrouSerS. (2005) https://sourceforge.net/projects/trousers/.
T. Horie, M. Hirano, K. Kourai, Y. Oyama, E. Kawai, K. Kono, S. Chiba, [72] USB-3.0-Promoter-Group, “Universal serial bus Type-C authentication
Y. Shinjo, and K. Kato, “BitVisor: A thin hypervisor for enforcing I/O specification release 1.0 with ECN and Errata,” 2017.
device security,” in Conference on Virtual Execution Environments, ser. [73] USB-On-The-Go, “http://www.usb.org/developers/onthego,” 2001.
VEE’09, 2009. [74] USB-Raptor. (2014) https://sourceforge.net/projects/usbraptor/.
[57] P. Simmons, “Security through amnesia: A software-based solution to [75] G. Vasiliadis, E. Athanasopoulos, M. Polychronakis, and S. Ioannidis,
the cold boot attack on disk encryption,” in The Annual Computer “Pixelvault: Using gpus for securing cryptographic operations,” in Con-
Security Applications Conference, ser. ACSAC ’11, 2011. ference on Computer and Communications Security, ser. CCS’14, 2014.
[58] E. R. Sparks, “A security assessment of trusted platform modules,” [76] VENOM, “http://venom.crowdstrike.com/,” 2016.
Dartmouth College Technical Report, 2007. [77] T. Vidas, D. Votipka, and N. Christin, “All your droid are belong to us:
[59] D. Spill, “USBProxy: An open and affordable USB man in the middle A survey of current Android attacks,” in USENIX Workshop on Offensive
device.” Technologies, ser. WOOT’11, 2011.
[60] P. Stewin, Detecting peripheral-based attacks on the host memory. PhD [78] Z. Wang and A. Stavrou, “Attestation & authentication for USB com-
thesis, Technischen Universität Berlin, 2014. munications,” in International Conference on Software Security and
[61] G. E. Suh and S. Devadas, “Physical unclonable functions for device Reliability Companion, ser. SERE’12, 2012.
authentication and secret key generation,” in Design Automation Con- [79] Z. Wang and X. Jiang, “HyperSafe: A lightweight approach to provide
ference, ser. DAC’07, 2007. lifetime hypervisor control-flow integrity,” in IEEE Symposium on
[62] K. Suzaki, “DeviceDisEnabler: A lightweight hypervisor which hides Security and Privacy, ser. SP’10, 2010.
devices to protect cyber espionage and tampering,” blackHat Sao Paulo [80] A. Washburn, “Snowden smuggled documents from NSA on a thumb
2014. drive. https://www.wired.com/2013/06/snowden-thumb-drive/.”
[63] D. Suzuki and K. Shimizu, “The glitch PUF: A new delay-PUF [81] R. Wilkins and B. Richardson, “UEFI secure boot in modern computer
architecture exploiting glitch shapes,” in Cryptographic Hardware and security solutions,” UEFI Forum, 2013.
Embedded Systems, ser. CHES’10, 2010. [82] R. Wojtczuk and C. Kallenberg, “Attacks on uefi security,” CanSecWest,
[64] J. Szefer, E. Keller, R. B. Lee, and J. Rexford, “Eliminating the 2015.
Hypervisor Attack Surface for a More Secure Cloud,” in Conference [83] P. Zaitcev, “The usbmon: USB monitoring framework,” in Linux Sym-
on Computer and Communications Security, ser. CCS’11, 2011. posium, 2005.
[65] tboot. (2008) http://tboot.sourceforge.net/. [Online]. Available: [84] Y. Zhang, A. Juels, M. K. Reiter, and T. Ristenpart, “Cross-vm side
http://tboot.sourceforge.net/ channels and their use to extract private keys,” in Conference on
[66] D. J. Tian, A. Bates, and K. Butler, “Defending against malicious USB Computer and Communications Security, ser. CCS’12, 2012.
firmware with GoodUSB,” in Annual Computer Security Applications [85] L. Zhao and M. Mannan, “Gracewipe: Secure and Verifiable Deletion
Conference, ser. ACSAC’15, 2015. under Coercion.” in Network and Distributed System Security Sympo-
[67] D. J. Tian, A. Bates, K. R. Butler, and R. Rangaswami, “ProvUSB: sium, ser. NDSS’15, 2015.
Block-level Provenance-Based Data Protection for USB Storage De- [86] ——, “Hypnoguard: Protecting secrets across sleep-wake cycles,” in
vices,” in Conference on Computer and Communications Security, ser. Conference on Computer and Communications Security, ser. CCS’16,
CCS’16, 2016. 2016.
[87] Zuiho. (2013) http://www.toptdc.com/en/product/sasebo/.

314

Authorized licensed use limited to: MANIPAL INSTITUTE OF TECHNOLOGY. Downloaded on July 25,2025 at 14:13:32 UTC from IEEE Xplore. Restrictions apply.