HyperWallet: cryptocurrency wallet as a secure hypervisor-based application

Abstract

We present VirtSecIO, a hypervisor-based platform for executing secure modules. VirtSecIO provides the modules with secure paths to peripheral devices, which can be shared between the modules and the operating system. Moreover, VirtSecIO is a thin hypervisor with a negligible performance overhead and a minimal attack surface. We demonstrate VirtSecIO’s abilities by developing HyperWallet, a secure module that acts as a hardware crypto-wallet, without requiring any dedicated hardware.

1 Introduction

Modern computers and mobile devices are convenient; almost anyone uses one. Unfortunately, modern computers run complex operating systems with large attack surface areas. Researchers believe that the security of a system decreases with its size due to the statistical evidence that suggests that the number of program errors, including vulnerabilities, is proportional to the number of software lines of code (SLOCs) [1]. Therefore, widely used general-purpose operating systems, like Windows and Linux, must be improved to provide sufficient security guarantees. In contrast, microkernel operating systems, such as seL4 [2], provide improved security guarantees at the cost of being less convenient.

Recently, CPU vendors have equipped their CPUs with various technologies for creating Trusted Execution Environments (TEE). Such TEEs include ARM’s TrustZone, Intel’s SGX and TME, and AMD’s SEV. The rationale behind these technologies is to create an isolated environment for executing sensitive code and manipulating sensitive information. Unfortunately, adapting these technologies in regular applications is either time-consuming or even impossible for average users, as in the case of ARM TrustZone.

A popular alternative to the dedicated and limited secure containers presented above is hardware-assisted virtualization, an instruction-set architecture (ISA) extension introduced by Intel, AMD, and ARM. Typically, virtualization executes multiple operation systems, forming the backbone of cloud architectures. However, virtualization can also improve the security of a single operating system in commodity computers. In particular, virtualization can construct Trusted Execution Environments (TEEs) [3].

The software that governs the execution under virtualization is called the hypervisor. Hypervisors capable of executing multiple operating systems are large in SLoCs and comparable to general-purpose operating systems. In contrast, a hypervisor capable only of creating a TEE can be tiny (in terms of SLoCs) [4].

Fig. 1

VirtSecIO’s architecture

This article presents VirtSecIO, a tiny hypervisor that creates a TEE. Moreover, VirtSecIO provides secure input from the keyboard, secure output to the screen, and secure communication via the network adapter without including the large drivers for these devices. Figure 1 presents the architecture of VirtSecIO. We demonstrate the usefulness of VirtSecIO by developing a secure cryptocurrency wallet that executes in its TEE. The module, which we call HyperWallet, acts as a hardware wallet for digital currency. HyperWallet stores the user’s private key in the Trusted Platform Module (TPM) [5] and fetches it into a secure memory region during VirtSecIO’s initialization. HyperWallet then uses the private key to sign the transactions. We used a 3rd party application (Metamask) for the generation and transmission of transactions to the digital currency network. This 3rd party application acts as a mediator between HyperWallet and the network and minimizes the attack surface on HyperWallet.

VirtSecIO is a general framework for developing secure applications. However, in its current implementation, VirtSecIO does not support executing more than one application simultaneously. More precisely, while in principle such execution is possible, VirtSecIO will fail to provide the necessary isolation between the applications.

The main contributions of this article are as follows:

• We present VirtSecIO, a tiny hypervisor that can create TEEs with Secure I/O. VirtSecIO is presented in Sect. 4.

• We present HyperWallet, a TEE application that acts as a hardware crypto-wallet and demonstrates the usefulness of VirtSecIO. HyperWallet is presented in Sect. 5.

• We evaluate the security and the performance of VirtSecIO and Hyperwallet. The evaluation is done in Sect. 6. We also compare it to alternatives in Sect. 7.

Section 2 provides background about virtualization technology, Trusted platform modules, and Cryptocurrency wallets. Section 3 provides our security assumptions for VirtSecIO and HyperWallet. Section 4 discusses the design of the VirtSecIO hypervisor. Section 5 discusses HyperWallet system design as a virtsecIO sample security module. HyperWallet is helpful in its own right to store cryptocurrency and also serves as a demonstrator for VirtSecIO capabilities. Section 6 performs security and performance evaluations of HyperWallet and VirtSecIO. Section 7 describes related works. Section 9 describes some unsolved problems in virtSecIO in modern hardware. Section 10 concludes the work.

2 Background

2.1 Virtualization

Intel and AMD introduced hardware-assisted virtualization two decades ago by extending the instruction-set architecture (ISA). The extensions are similar but not compatible. In this article, we will discuss Intel’s implementation of hardware-assisted virtualization. The ISA extension defines a new execution mode, called root mode, with higher privileges than the kernel mode. The software that executes in root mode is called the hypervisor. The software in non-root mode, including the operating system and the user applications, is called the guest. The hypervisor can configure the execution environment of the guest, such as defining the control registers that affect the memory address translation. In addition, the hypervisor can define a set of events that must be intercepted, such as the execution of IO instructions or assignment to privileged registers. When an interception occurs, the processor switches to root mode and jumps to the hypervisor’s function. This transition is called a vm-exit. When the event handling completes, the hypervisor performs a vm-entry, a transition back to the guest.

Since a hypervisor generally controls several guests, it must manage memory sharing. The ISA extension assists with this in the form of an additional memory address translation layer, called secondary-level address translation (SLAT). When SLAT is active, the hypervisor defines a page table for each guest, the SLAT table. When the guest accesses some logical address X, this address is translated by the guest’s regular page table to a guest’s physical address Y. When virtualization is disabled, Y is the actual physical address. However, when virtualization and SLAT are enabled, Y is translated to Z, the actual physical address, using the SLAT table. This table, similar to the regular page table, defines each page’s translation and access rights. A VM exit occurs when the guest accesses a memory location that violates the SLAT table. This mechanism allows the hypervisor to protect its data structures and intercept access to memory-mapped IO.

The hypervisor can protect its memory from the software running in the guest and malicious activity in the device controllers. For example, the operating system can request the network adapter to transmit a memory page containing the hypervisor’s data structures. Since SLAT does not protect memory accessed by device controllers, another security mechanism, the Input/Output Memory Management Unit (IOMMU), was introduced. Similarly to the MMU, the IOMMU maps the logical addresses to physical addresses. However, unlike the MMU, the logical addresses are accessed not by software but by the device controllers connected to IOMMU. The hypervisor can configure the IOMMU to prevent access to its data structures from the device controllers.

2.2 TPM

The Trusted Platform Module (TPM) provides secure, tamper-resistant storage and cryptographic functions that can operate on this storage. In addition to key storage functionality, symmetric and asymmetric cryptography, and hashing, TPM can seal a key to its internal state. Later, the key can be fetched only when the TPM is in this exact state. The state of the TPM is defined by its Platform Configuration Registers (PCRs). The PCRs can be read but not directly written. Instead, PCRs are extended by hashing their current value with some new value: $\text {PCR}_n=\text {hash}(\text {PCR}_n,\text {Value})$.

Each time an EFI application [6] is loaded, the EFI firmware extends the PCRs with the hash value of the application’s image. When an EFI application seals a key, it guarantees that only the current and previously loaded applications can retrieve the key in the future. VirtSecIO, embedded in an EFI application, uses the TPM to store cryptographic keys that the operating system cannot access.

VirtSecIO, being the first executed software, uses the TPM to store and retrieve cryptographic keys. The keys are bound to the current values of the PCR values, thus allowing only VirtSecIO to fetch the stored keys. These keys can be used by the various application of VirtSecIO not only for encryption of storage or transmission sensitive information, but also for proving the application’s authenticity to a remote party.

2.3 Digital currency

Digital currency is based on a distributed network storing a database that records the assets belonging to each account. Depending on the currency, a transaction is a simple asset transfer request or an operation on a smart contract. The transaction includes the network’s current state (in the form of a hash), the transaction details, and the issuer’s cryptographic signature.

Each transaction must be signed individually using the issuer’s private key. For example, in Ethereum [7], the signing process involves two steps: hashing, which is performed using the Keccak algorithm [8], and signing, which is performed using the ECDSA algorithm. The private key used by the ECDSA algorithm [9] should always be kept secret since possessing the assets is equivalent to knowing the private key.

The blockchain [10]-based cryptocurrencies such as Bitcoin [11], Ethereum [12], and Cardano [13] are gaining popularity as means of trade and investment [14].

2.4 Cryptocurrency wallets

As the cryptocurrency industry grows, the need for specialized crypto wallets grows. Providing blockchain users with adequate means for storing their assets conveniently and securely is challenging. There are two categories of current solutions: hardware wallets, based on specialized hardware that provides high-security guarantees, and software wallets, i.e., software running on a standard PC or mobile phone. Software wallets do not require specialized hardware that is prone to get lost or stolen and, therefore, are very convenient. Hardware wallets are usually “cold” wallets, i.e., these wallets are not online. Software wallets are frequently “hot” wallets, i.e., available online. The main benefit of a cold wallet is security. Since the wallet is unavailable online, hackers cannot attack it directly through software-only means. If cryptocurrency residing in a cold wallet is stolen, it follows that the attack consisted of other means (social engineering, physical attacks or threats, etc.) [15].

In contrast, hot wallets provide ease of use. The user can buy and pay for stuff from his computer online. However, hot wallets sacrifice some of the security. Therefore, many users use both hot and cold wallets. (Store most of their assets protected in a cold wallet while storing small amounts in a warm wallet for convenient usage.)

2.5 Metamask

Metamask is an open-source browser extension [16] used to interact with the Ethereum network. It is one of the most popular platforms in use today. In addition, Metamask provides a convenient user interface for viewing the user’s balances and performing transactions. Metamask can store the user’s private keys in the browser’s data store or outsource the storage and the signing to an external hardware wallet, e.g., Ledger, Trezor, and Keystone. The communication with the hardware wallet is implemented via a dedicated protocol implemented by a Metamask module or via a standardized air-gapped protocol that relies on QR codes. With QR codes, when the user requests to make a transaction, Metamask displays a QR code representing the transaction (Fig. 2 left). An air-gapped device, i.e., a smartphone, scans the QR code using its camera and displays a QR code representing the transaction’s signature on its screen. Metamask then uses the camera of the primary device, i.e., the laptop, to scan the signature (Fig. 2 right).

3 VirtSecIO security model

This section describes the assumptions and the guarantees of VirtSecIO. We make the following assumptions about the abilities of the attacker:

• The attacker has full access to and can execute arbitrary code kernel mode.

• There are no vulnerabilities in VirtSecIO and in its secure module.

• The hardware components (CPU, TPM, IOMMU, etc.) operate as described in their documentation.

• The firmware operates according to the EFI documentation and does not contain vulnerabilities.

Under the assumptions above, we guarantee the following regarding VirtSecIO and its secure module:

• They have full control over the security indicator.

• They can observe and modify the input from the keyboard and the network adapter before the operating system.

• They can display information on the screen so that the operating system cannot access this information.

• They are the only applications with access to the secret stored in the TPM.

We note that VirtSecIO does not attempt to prevent DoS attacks. For example, the operating system may shut down the computer anytime. In addition, as described in Sect. 4.3, VirtSecIO’s input depends on the operating system’s input; if the operating system does not attempt to read the keyboard strokes, VirtSecIO will not receive them either. We impose the following limitations on the implementation of VirtSecIO:

• The implementation must not use special external devices.

• The implementation must not require firmware modifications since, in most cases, it is impossible for the end user.

As will be described in Sect. 4.1, VirtSecIO does depend on a special external device, namely the TPM. However, we consider the dependency to be acceptable, as TPMs are widely available nowadays on commodity computers.

4 VirtSecIO system design

VirtSecIO is a thin hypervisor capable of executing secure modules. The main objective of VirtSecIO is to provide a programmer with an isolated execution environment inaccessible by the operating system and any malware it hosts. Although such an environment can be helpful in various applications that aim at improving the security of the underlying operating system [17, 18], we further extend its capabilities by equipping VirtSecIO with secure input and output channels. This section discusses VirtSecIO’s capabilities and its internal design. A secure sample module that utilizes some of these capabilities is described in Sect. 5.

We pursued two main goals while designing VirtSecIO

• Reducing its performance overhead, thus making it applicable in a wide range of production systems

• Minimizing its attack surface by incorporating only the essential fraction of each device driver.

While these goals restrict the functionality of VirtSecIO, we attempted to find the right balance. While other solutions provide richer functionality, we believe that certain application require high security guarantees that cannot be achieved without sacrificing some flexibility. Therefore, during the design of VirtSecIO, we deliberately reduced as much as possible its attack surface. The rest of this section describes the functionality of VirtSecIO, while Sect. 6 evaluates the performance and the attack surface of VirtSecIO.

4.1 Initialization

EFI firmware [6], or Extensible Firmware Interface firmware, is a type of software that acts as an interface between a computer’s hardware and its operating system. It is a modern successor to the traditional BIOS (Basic Input/Output System) that has been used in personal computers for decades. EFI firmware can be extended using EFI applications, software programs designed to run in the EFI environment. EFI applications are distinct from traditional software applications that run under an operating system. Instead, they execute before the operating system starts, in a pre-boot environment.

VirtSecIO is embedded in an EFI application. The EFI application boots before the operating system and initializes the hypervisor, VirtSecIO’s core. The hypervisor creates a single virtual machine (guest) and continues the execution of the EFI application inside this virtual machine. In essence, the EFI application calls some function F, which initializes the hypervisor, and then this function returns. The caller runs inside the newly created VM. When the EFI application is complete, the EFI firmware loads the next EFI application, usually the operating system bootloader. The bootloader and the operating system itself execute under the supervision of VirtSecIO.

The installation of VirtSecIO consists of three steps. The EFI application is copied to a FAT partition in the first step. On EFI systems, the partition that stores the operating system’s bootloader is an EFI partition, and usually, it is sufficiently large to store the tiny EFI application of VirtSecIO. After copying the EFI application, the boot order must be changed to boot the VirtSecIO’s EFI application first. Finally, the cryptographic hash of the EFI application is added to the signature database.

VirtSecIO, being the first executed software (except the firmware itself, as described in Section 3), exposes the TPM’s [5] integrity and secure storage services. In particular, VirtSecIO allows the programmer to store or retrieve a previously stored cryptographic key. Moreover, the key is bound to the specific cryptographic signature of VirtSecIO, thus allowing only VirtSecIO to fetch it in the future. The binding serves two purposes. First, the operating system, or any other software, cannot fetch the cryptographic key from the TPM. Second, the cryptographic key can be used to prove the authenticity of VirtSecIO to a remote (or local) entity [19].

The aforementioned mechanism, complicates potential updates to the VirtSecIO, since the new version, having a different signature, will not be able to access the cryptographic keys. There are several possible solutions to this problem. A simple solution is providing means for export and import of cryptographic keys during VirtSecIO’s initialization. Another possible solution is splitting VirtSecIO into two modules. A tiny bootloader module, which is unlikely to change and the main, larger module. The cryptographic keys can then be bound to the signature of the bootloader. The bootloader will load the main module after verifying its certificate, similarly to the way Windows verifies its drivers. In any case, while the problem of software updates is important, it is out of scope of this article.

4.2 Memory isolation

During its initialization, VirtSecIO uses the EFI standard protocol for memory allocation. In the allocated memory region, VirtSecIO stores the data structures of the hypervisor and the security modules. A special flag (EFI_RUNTIME_SERVICES_DATA) passed to the EFI memory allocation function makes the allocated memory region inaccessible to the operating system. A benign operating system will never attempt to access this memory region. Unfortunately, this mark does not forbid access but rather discourages it. Therefore, we need more robust security guarantees against a malicious operating system. VirtSecIO configures the SLAT table to make the allocated memory region inaccessible by the operating system. In addition, VirtSecIO configures the IOMMU table accordingly to prevent indirect access to the allocated memory region via a hardware device [20]. The SLAT and the MMIO tables are configured to represent an identity mapping of the actual physical memory to the physical memory as perceived by the operating system and the hardware devices; VirtSecIO only clears the access flags of the entries that describe the allocated memory region.

4.3 Keyboard input

In its current implementation, VirtSecIO supports secure input only from PS/2 keyboards. Two aspects dictated this choice. First, the internal keyboard of our HP laptop is identified as a PS/2 keyboard (which is also the case for our Lenovo laptop). Second, the PS/2 protocol is much simpler than USB.

The PS/2 keyboard is connected via the “8042” PS/2 controller. The PS/2 controller uses two IO ports: 0x60 and 0x64. Port 0x64, when read, retrieves the controller’s status, which includes a bit that determines whether a device has a byte to send. The byte itself can then be read from port 0x60. In the case of a keyboard, the byte it sends is the scancode of the pressed or released key.

VirtSecIO, during its initialization, configures the interception of reads from port 0x60. Whenever a key is pressed or released, the PS/2 controller generates an interrupt delivered to the operating system. In response, the operating system reads from port 0x60. Unlike the interrupt, this read is intercepted by VirtSecIO before the read request is actually sent to the controller. In response, VirtSecIO sends an actual request to the controller and stores the received scancode in its internal data structures. Depending on its current state, VirtSecIO may transfer the actual scancode or some dummy scancode to the operating system. This mechanism allows the currently executing secure module to switch between a non-secure input mode, in which the operating system receives all the scancodes, and a secure input mode, in which the pressed keys are hidden from the operating system but are visible to the secure module.

Secure input from a PS/2 mouse can be implemented similarly by intercepting the 0x60 port of the “8042” controller. Unfortunately, the laptop computers’ touchpad and trackpoint devices are connected via USB, thus requiring VirtSecIO to implement the more complex USB protocol. Since such an implementation will increase VirtSecIO’s attack surface, contradicting one of the main goals, we decided to exclude USB protocol implementation from the current version of VirtSecIO. We note that the exclusion of the USB protocol also limits the applicability of VirtSecIO to desktop computers, where most keyboards are connected via USB.

4.4 Video output

Video adapters provide multiple modes of operation: text modes, video modes, and more advanced modes used in video games. While the initial mode of a video adapter is one of its text modes, the EFI firmware switches to a video mode before loading the first EFI application. In addition, EFI provides an API for switching modes and drawing on the screen. In particular, the QueryMode function can be used to determine the address of the video adapter’s frame buffer. The frame buffer is a long array of pixels displayed on the screen. While the different EFI functions can only be used before the operating system’s initialization completes, the frame buffer’s address does not change. During its initialization, VirtSecIO determines the address of the frame buffer and stores it in its internal storage. This address can then be used to draw on the screen by modifying the appropriate pixels.

VirtSecIO allows a secure module to take ownership of the screen. The operating system’s requests to update the screen are postponed while a secure module owns the screen; they are applied when the control returns to the operating system. VirtSecIO implements the ownership metaphor using the SLAT tables. When a secure module locks the screen, VirtSecIO configures the pages containing the frame buffer as inaccessible and makes a copy of the frame buffer’s current state. Any attempt to update those pages is intercepted by VirtSecIO, which emulates a single write instruction of the operating system and applies it to the frame buffer’s copy. When the secure module releases the lock, the frame buffer is updated from its possible modified copy.

When the screen is owned by the secure application, VirtSecIO constantly updates the frame buffer’s copy in response to operating system’s requests. While no information is lost during this operation, the user cannot observe other widows that might display important information. A possible solution to this limitation is locking of a particular area, a window, in the frame buffer. Unfortunately, such advanced locking mechanism was not implemented in the current version of VirtSecIO.

VirtSecIO provides a minimal set of video output functions, which was helpful during the implementation of HyperWallet (Sect. 5). In particular, VirtSecIO allows a secure module to render icons, draw simple geometric shapes, and display text labels.

4.5 Secure network communication

Network adapters vary significantly in their complexity and their programming model. In its current implementation, VirtSecIO supports the Intel i217 family of adapters, but supporting additional adapters should be easy ([21]). The i217 network adapter communicates with the operating system through configuration registers mapped to a memory region whose base address can be retrieved from the PCI configuration space. In particular, these registers define two memory-based circular queues: transmission and reception. The entries of the transmission queue point to memory buffers containing the packets to be sent, while the entries of the reception queue point to memory buffers to be filled with the incoming packets.

The network adapter can be configured to generate interrupts in response to various events: packet arrival, queue underflow, transmission error, etc. In any case, to retrieve a received packet, the operating system consults the queue-defining registers to find the location of the newly filled memory buffer. Then, the operating system reads the contents of the packets from these memory buffers. Similarly, when the operating system sends a packet, it stores the location of the packet in the transmission queue and updates the queue-defining registers accordingly.

VirtSecIO configures the SLAT tables to make the pages containing the configuration registers inaccessible, thus allowing it to intercept all the reception and transmission activity. In particular, on the operating system’s attempt to read from the reception queue-defining registers, VirtSecIO scans the reception queue and allows the secure module to observe and modify the received packets. Packets for the secure module can have a special structure or signature bytes. The secure module can change the packets’ length to zero, thus hiding them from the operating system. Similarly, on the operating system’s attempt to transmit packets, VirtSecIO allows the secure module to insert additional packets into the transmission queue. Since the operating system expects the queue-defining registers to remain unchanged, the number of packets inserted by VirtSecIO into the queue always equals the queue size. This behavior brings the queue-defining registers to their original state.

Being dependant on a specific network adapter, limits the applicability of VirtSecIO, as every network adapter would require implementing a new module to handle it. However, as was shown by Kiperberg [21], network adapters produced by the same manufacturer share common design principles and therefore can be handled by similar or even identical modules.

4.6 Security indicators

A security indicator allows the user to distinguish between two system states: a safe state, where the user communicates with the secure module, and an unsafe state, where the user communicates with a possibly infected operating system. Unlike other input and output devices, the security indicator must always be fully controlled by VirtSecIO. This aspect poses some restrictions on devices that can be used as security indicators since these devices cannot provide their regular functionality.

All the devices discussed above, a keyboard, a screen, and a network adapter, can serve as security indicators. A regular keyboard is equipped with three LEDs: (1) num lock, (2) caps lock, and (3) scroll lock. Any of these can be used as a security indicator. For example, a group of screen pixels (several rows) can be used as security indicators. Finally, a network adapter’s status LEDs can also be used as security indicators. When VirtSecIO takes control of one of these security indicators, the related regular functionality is impaired but not fully disabled. For example, if the caps lock LED is used as a security indicator, the user can still use the caps lock key to select the input mode, but the LED itself will not reflect this mode.

The operating system configures the keyboard LEDs in response to pressing the respective keys. In PS/2 keyboards, this is done by sending a sequence of two bytes to port 0x60. The first byte represents the LED configuration command. The second byte represents the requested setting of the LEDs. To use the x-th keyboard LEDs as a security indicator, VirtSecIO configures the interception of writes to port 0x60. VirtSecIO modifies the x-th bit in the second byte to correspond to the security indicator’s state if the first byte represents the LED configuration command.

To use the screen pixels as a security indicator, VirtSecIO configures the SLAT tables to intercept all accesses to the required group of pixels. Upon access to those pixels, VirtSecIO skips the screen update instruction issued by the operating system. This simple mechanism is suitable for pixel groups occupying total memory pages. For example, when the screen resolution is 1024 × 768, a memory page contains exactly one row of pixels. In that case, VirtSecIO configures the SLAT tables such that the appropriate pages are non-writable. Any attempt to write to those pages is intercepted by VirtSecIO, which in turn skips the write instruction issued by the operating system. VirtSecIO must intercept write accesses to all the pages containing at least one selected pixel if the selected pixel group is not a union of total pages. Upon access to one of these pages, VirtSecIO inspects the access address and decides whether to skip the instruction or emulate it by performing the write.

In general, reserving some screen pixels to serve as a security indicator can degrade the user experience, since those pixels can never be used for the regular display. In our implementation, however, the user experience degradation is negligible, since the reserved pixels occupy the bottom rows of the screen where Windows displays the taskbar.

The operating system configures the network adapter LEDs using the configuration registers. In particular, the “LED Control Register 2” of the Intel i217 network adapter configures the LED to blink in response to a networking event (link establishment, transmission, reception, etc.) or to be constantly on or off. By intercepting the configuration registers, VirtSecIO can set the LED in a particular state and prevent the operating system from changing its state.

5 HyperWallet system design

HyperWallet uses a hypervisor to combine the benefits of both warm and cold wallets. HyperWallet provides a highly convenient software wallet in a hardware-isolated and secure environment. HyperWallet constructs a secure input and output path enabling secure interactions with the wallet even in the presence of keyloggers [22] and other advanced threats. In addition, HyperWallet uses trust indicators to ensure that the input and output are secure, as in Hyperpass [23].

HyperWallet is a security module for VirtSecIO, acting as a back-end for digital currency wallets. While being interesting on its own, the primary purpose of HyperWallet is to demonstrate the applicability of VirtSecIO’s design for solving real-world problems.

Fig. 2

Metamask requests to sign the transaction encoded using a QR code (left); then Metamask uses a webcam to scan the transaction signature encoded using a QR code (right)

HyperWallet is an alternative to the expensive hardware wallets for the Ethereum network. HyperWallet is implemented as a security module for VirtSecIO. Metamask (described in Sect. 2.5) carries out the transaction generation and communication with the network, while HyperWallet is responsible for storing the key and signing the transactions.

Metamask provides several communication channels with hardware wallets. We have chosen the so-called air-gapped communication channel based on QR codes. This is the simplest and the most portable solution. Other options require either modifying the code of Metamask or implementing a non-trivial communication protocol.

“Air-gapped communication” refers to communication that is carried out by scanning QR codes. This method of communication is considered secure as it cannot be intercepted or tampered with by malicious users. Any attempts to tamper with the QR code will be detected. A malicious website cannot create a malicious QR code unless it is approved by Metamask. Additionally, any changes made to the Metamask QR code will also be detected by Hyperwallet, providing an extra layer of security.

The “air-gapped” communication channel has two requirements from our system: (a) it must be able to read from the screen the QR code that encodes the transaction, and (b) it must be able to create a virtual camera that “captures” the QR code that encodes the signature. Our system is implemented as a user-level application that acts as a mediator between Metamask and HyperWallet. Our application makes periodic screenshots for the first requirement and searches them for a QR code. If an appropriate QR code is found, the application transfers the transaction to HyperWallet. In response, the application receives a signature. For the second requirement, we have installed the “VCam” software¹, which creates a new camera device and allows the streaming of an image file. After receiving the signature, the application encodes it as a QR code and updates the image file accordingly.

We assume that an adversary can replace the real QR code or spoof new QR codes. In response, HyperWallet will lock the screen and display the transaction details. The user may authorize or decline the presented transaction.

Fig. 3

HyperWallet displays the public part of the newly generated key. The TPM stores the private part

HyperWallet stores the user’s private key in the TPM. During VirtSecIO’s initialization, HyperWallet attempts to load the private key from the TPM. If this is the first run and the key does not exist, HyperWallet requests the user to generate a new key or enter a key to be stored. Then, the key is stored and sealed in the TPM (Fig. 3). Since the key is sealed, the operating system cannot fetch it from the TPM. After loading the key, HyperWallet stores it in VirtSecIO’s secure memory region. We note that the initial input of the private key from the user happens before the initialization of the operating system, i.e., in a safe environment. Similarly, HyperWallet inputs, stores, and handles the user’s secret password.

HyperWallet implements two hypercalls: PutTransaction, which informs HyperWallet that a new transaction needs to be signed, and GetSignature, which requests HyperWallet to return the signature. Both hypercalls are implemented using the CPUID instruction in which the code of the required operation is stored in the EAX register.

Fig. 4

HyperWallet displays red pixels at the bottom of the screen at all times to indicate that the user should not enter her password

Fig. 5

HyperWallet displays the transaction details and green pixels at the bottom of the screen. The user should enter her password to authorize the transaction

HyperWallet uses the bottom few rows of screen pixels as a security indicator (Fig. 4). VirtSecIO guarantees that the operating system cannot modify these pixels. During the execution, HyperWallet is idle, and the screen pixels are red. In response to the PutTransaction hypercall, HyperWallet takes several actions. First, it turns the pixels green and instructs VirtSecIO to take control of the keyboard and the screen. Then, HyperWallet displays the transaction details on the screen and requests the user to enter her secret password (Fig. 5). The keystrokes are sent to VirtSecIO and HyperWallet, while the operating system receives some predefined key. The input continues until the user presses the “Enter” key. Then, HyperWallet releases the keyboard and the screen and changes the pixels at the bottom to red. After completing the password input, the GetSignature hypercall is generated. HyperWallet responds to this hypercall by verifying the correctness of the entered password, signing the transaction, and returning the signature.

6 Evaluation

6.1 Security

VirtSecIO’s root of trust begins with the firmware, which we assume to be secure. The firmware is guaranteed to load the applications in a specific order. In particular, the first application loaded by the firmware is VirtSecIO. Moreover, the firmware verifies the integrity of the loaded application using the Secure Boot technology [24]. In our current implementation, the secure module is linked to VirtSecIO, and therefore, Secure Boot verifies its integrity, too.

Assuming that VirtSecIO and its security module are bug-free and that the hardware operates as intended, we can conclude that the memory regions allocated by VirtSecIO are protected from the hardware devices and the software that runs in non-root mode. In addition, since the hypervisor can intercept the relevant IO instructions and access the memory-mapped registers, VirtSecIO can control the keyboard, the network adapter, and the display. In particular, VirtSecIO and its secure module can be the first to see and hide the keyboard strokes and the network packets; they can use the screen, the keyboard LEDs, and the network adapter LEDs as security indicators.

The private key required by HyperWallet is stored in the TPM, a hardware component we assume to be secure even against physical attacks. Since the private key is sealed with the current TPM’s state during the execution of VirtSecIO, we can conclude that only VirtSecIO itself can fetch the key. After fetching the key, VirtSecIO stores it in its preallocated memory region, inaccessible by software executing in non-root mode; the key never leaves this memory.

6.2 Attack surface

We evaluate the attack surface of VirtSecIO by comparing it to other solutions. Fidelius [25], Protection [26], Bumpy [27], and BitE [28] have a tiny attack surface, but they are implemented using external devices, violating our implementation limitations. SwitchMan [29], Aurora [30], and TrustLogin [31] operating in the system management mode (SMM), requiring them to alter the firmware, again violating our implementation limitations. T-PIM and Qubes OS are based on a full hypervisor. The size of a full hypervisor like Xen is $\approx$600,000 SLOC [32], much larger than VirtSecIO, which has $\approx$17,000 SLOC (see Table 1).

Table 1 VirtSecIO and HyperWallet attack surface

SGXIO [33] is a thin hypervisor with a small TCB similar to VirtSecIO. However, unlike VirtSecIO, SGXIO includes a full implementation of drivers for devices that act as sources or sinks of sensitive information. The drivers of display adapters are known for their large size. For example, the driver of a simple driver for the VMware SVGA II has $\approx$33,000 SLOC [34]. Furthermore, SGXIO requires SGX support, which is available only in a narrow range of CPUs produced by Intel.

6.3 Performance

We assessed the impact of Hyperwallet on the performance of the system in use. The transaction speed of Hyperwallet is primarily constrained by the time it takes to receive a QR code (by network), to scan a QR code (by camera) and the associated costs of executing transactions (i.e., “gas-fees”). The CPU and IO speeds are not significant limiting factors for the Hyperwallet.

Fig. 6

Comparison of performance degradation of VirtSecIO and VirtualBox measured using the PCMark benchmarking tool. The performance is measured in different categories. On average, VirtualBox is $\approx 23$ times slower than VirtSecIO

This section evaluates the performance of the VirtSecIO. Table 2 presents the testbed configuration. All the tests were performed in a virtualized environment produced by VMware Workstation running atop Windows 10.

Table 2 Testbed configuration

To demonstrate the performance impact of VirtSecIO on the operating system, we use the PCMark 10 Basic Edition benchmarking tool. The tool performs several tests and displays a score for each test. We invoked the tool twice: with and without VirtSecIO. The blue bars in Fig. 6 represent the score reduction in the invocation with VirtSecIO compared to the invocation without VirtSecIO. Then, we ran a VirtualBox virtual machine and invoked PCMark again. The red bars represent the score reduction in the VirtualBox invocation compared to the invocation without VirtualBox. We can see that the performance penalty of VirtSecIO is approximately $5 \%$ on average, while the performance penalty of VirtualBox, a full hypervisor, is $\approx 23$ times higher.

These results can be explained by VirtSecIO’s design. VirtSecIO is a thin hypervisor that intercepts only a tiny amount of events. Unlike full hypervisor (Xen, ESXi, VirtualBox, etc.), VirtSecIO does not intercept interrupts, significantly improving its performance.

7 Related work

7.1 Comparable to Hyperwallet

Hardware crypto wallets provide a comparable level of security by hosting secure storage and a computation unit on a dedicated device. Some devices, like Ledger and Trezor, connect to the computer via USB or Bluetooth to transmit the signed transactions to the network. Other so-called air-gapped devices, like Keystone and ELLIPAL, communicate with the network by reading and displaying QR codes representing transactions and their signatures. The main drawbacks of such devices are their cost and convenience due to the limited resources available in such tiny devices. HyperWallet provides a comparable degree of security at zero cost. In addition, HyperWallet, being realized almost as a regular user application, provides a much better user experience.

The security guarantees provided by VirtSecIO can be partially achieved by leveraging an external device or a processor’s security technology, like System Management Mode (SMM), virtualization [35], and Software Guard Extensions (SGX) [36].

The main advantage of Hyperwallet compared to hardware wallets is that no extra hardware is required.

There are also multiple software-only wallets (usually hot wallets) which are not nearly as secure as Hyperwallet.

7.2 Comparable to VirtSecIO

Aurora [30] leverages SMM to provide secure channels between enclaves and devices. Unlike VirtSecIO, which the end-user can install, Aurora must be part of the computer’s firmware, which the computer’s manufacturer deploys. On the other hand, Aurora does not degrade the system’s performance at all. Similarly to Aurora, TrustLogin [31] uses SMM as an isolated environment. The main goal of TrustLogin is securing the input of usernames and passwords. TrustLogin uses only keyboard LEDs as security indicators, while VirtSecIO can also use the screen and the network adapter. But more importantly, TrustLogin does not provide a means for secure output, which is essential in applications like HyperWallet.

T-PIM [37] uses a full hypervisor to run two virtual machines. One is used as a secure execution environment and as an input platform for sensitive information. T-PIM automatically switches between the two virtual machines when required. Qubes OS [38] uses a full hypervisor (Xen [32]) to run multiple virtual machines whose output is multiplexed to a single screen. Unlike VirtSecIO, T-PIM and Qubes OS have large TCBs and non-negligible performance overhead.

SGXIO [33] is a secure input extension for the Intel secure enclave technology called SGX. SGXIO implements the secure inputs using a hypervisor that includes drivers for devices whose input or output needs to be protected. Also, the hypervisor emulates two virtual devices for each such device: secure and non-secure. The operating system can access the non-secure device, whereas an SGX enclave can only access the secure device. SGXIO is a generic solution for the trusted I/O path problem. However, the device emulation harms both the simplicity and the performance of systems based on SGXIO. The design of VirtSecIO is much simpler, thus allowing it to have a small TCB and achieve a minor performance penalty.

Zhou et al. [39] describe a generic method for constructing trusted IO paths between devices and user applications. Their method uses a thin hypervisor to secure the input. The authors discuss the applicability of their design to USB devices, which can be helpful for VirtSecIO, too.

HyperPass [23] is an isolated and secure environment for entering and encrypting users’ confidential information. HyperPass is based on a thin hypervisor. Unlike HyperPass, VirtSecIO provides not only secure input but also secure output.

8 Limitations

This section summarizes the main limitations of VirtSecIO in its current implementation. Probably the most severe limitation of VirtSecIO is the limited hardware support. In particular, VirtSecIO does not include USB drivers, which are required to support almost all desktop keyboards. A similar issue with the network adapters, limits VirtSecIO to only a specific adapter model.

Less limiting factors include full screen locking. When an application locks the screen, nothing is displayed but the application’s information. A more complete implementation could provide means for locking only specific pixels of the screen, thus allowing the application to display its information securely, while displaying widows of other, not secure applications.

Another problem is the inability of VirtSecIO to provide isolation between several secure applications, thus practically allowing only a single application to execute simultaneously. Finally, the current design of VirtSecIO does not provide acceptable means for software updates. Possible solutions to this problem were outlined in Sect. 4.1.

9 Future work

The main limitation of VirtSecIO is its lack of support for the USB protocol. This limitation makes using HyperWallet on desktop computers equipped with standard USB keyboards impossible. Since one of VirtSecIO’s goals is minimizing the attack surface, it is still being determined whether it can support the USB protocol and to what extent.

Other vendors of computer systems do not equip their devices with TPMs, which is essential to HyperWallet and VirtSecIO. However, Apple’s Secure Enclave technology [40] and Samsung’s Knox technology [41] can be used as alternatives to TPM.

10 Conclusions

We have presented VirtSecIO, a hypervisor-based secure environment that provides a highly secure means for input and output with a minimal attack surface. Our primary objective while designing VirtSecIO was to minimize the performance overhead and the attack surface. We have demonstrated the practical application of VirtSecIO by introducing HyperWallet, an alternative to hardware wallets. The minimal performance overhead of VirtSecIO makes it suitable for deployment in a wide range of scenarios. In summary, we have successfully developed a system that offers superior security with negligible impact on system performance.