Security Evaluation

In the following section, we evaluate and analyze whether the security mechanisms described in Section 7.7 solve the security challenges described in Section 7.2. We assume that the secure transaction client, which we introduced in Section 7.2, is running in a TVM and that its integrity is ensured using attestation techniques. Based on the attacker model introduced in Section 7.2.2, we consider an attacker who tries to access sensitive transaction data.

Software Manipulation Attacks

Each protection layer is measured before execution by the layer below. This results in a chain of trust with the property that all software manipulation attacks that modify a software component before it has been measured are reliably detected. However, to prevent the detection of a compromised system configuration, an attacker can use the following attack patterns:

(1) he manipulates the software integrity after it has been measured using a runtime attack,

(2) he alters the software integrity measurements so that they reflect a trusted software configuration, and

(3) he manipulates the measurement process so that a specific subversive applica-tion is not measured or the chain of trust is not complete.

In the following, we will study different underlying attack vectors that an adversary may use in order to successfully perform an attack of types (1), (2) and (3). Figure

7.7. EVALUATION OF THE ARCHITECTURE 129 7.9 shows these possible attack vectors. The arrows 1-4 indicate a starting point of a possible attack vector and the arrows that additionally possess an alphabetic character mark the further proceeding of an adversary.

Application Application Application

Tiny Operating System

TPM Device Driver

Management VM

Hardware TVMM Trusted Virtual Machine

Application

TPM Attestation

Service

Arbitrary Operating System

Open Virtual Machine

Application

Measurement Agent

Secure Storage TPM Manager

TPM Device Driver VM Manager

2 3

1

4 Device

Drivers

1a 1b

1c

2a

2c

2b 3a

3b

3c

Figure 7.9: Attack vectors on our security architecture

Attacks on the TVM (Arrow 1) The attacker may be able to exploit a vulnera-bility of one software component in order to perform an attack of type (1). The risk of these runtime attacks on the TVM’s operating system is reduced, because the operating system of the TVM is directly adapted to only host one user application and has a small code complexity. This reduced complexity enables the use of a very simple operating system with only a small set of services. Since simplicity was found to be the source of greatest protection against system penetrations [9], this approach is more resistant to runtime attacks than using a more complex operating system. Moreover, we choose a strict system configuration to minimize possible attack methods, e.g., network connec-tions are restricted, the hard disk of the TVM is read-only and swapping is disabled.

Since the TVM’s operating system is either realized as a microkernel, such as MINIX [79] or L4 [101], or it has the characteristics of a microkernel, it is basically possible to formally verify its correctness w.r.t. certain precisely stated security predicates. Thus, formal methods [95] could be used to ensure that no exploitable vulnerability exists, thereby resulting in verified security [124]. Additionally, the OS is configured in such a way that it is not possible to execute additional software components with the privi-leges of the operating system. For example, a static security kernel is used that not only

prohibits the dynamic reloading of modules, but also all other possibilities to access the whole memory allocated to the VM (e.g., file systems such as /proc/kcorehas to be disabled). Attacks of types (2) and (3) cannot be performed since the processes needed to be manipulated in order to perform a successful attack are located on the layers below.

Attacks on the Open VM (Arrow 2) The Open VM is allowed to run arbitrary software components and provides the semantics of today’s open machines. As a result, the environment consists of multiple different applications with a wide spectrum of security vulnerabilities. As a consequence, it is very likely that an attacker is able to perform an attack of type (1) by exploiting a vulnerability to gain control and install subversive applications. In contrast to the TVM, the Open VM is not equipped with a means of measuring software components. Therefore, it is not possible to detect that the software environment has been maliciously modified. However, since the underlying protection layer provides isolation of software environments, it is not possible to access sensitive data, since security breaches by compromised applications are contained inside the Open VM. Thus, it is not feasible for an attacker to access sensitive data stored inside the TVM or inside the secure storage. However, since it seems likely that the attacker is able to gain full control of the Open VM, he may be able to perform a hardware attack and break out of the compartment, thereby undermining the isolation characteristic of the hypervisor. These attacks are visualised by arrows 2b and 2c of Figure 7.9.

Assume that an attacker has completely taken control of the Open VM. He might then try to perform a malicious DMA access to a memory area allocated by the Hypervi-sor, Management VM or Trusted VM. For example, the very widespread Xen hypervisor [14], which we also use in our approach, allocates the top 64MB of each address space.

Under normal conditions, this address space is protected by the CPU and the operating system of the Open VM cannot directly access this area. However, since DMA bypasses any protection managed by the CPU, an attacker can use the physical address of the hypervisor’s allocated address space to access the address space and then overwrite key-data structures. [187] and [53] recently showed that the Xen hypervisor is vulnerable to such attacks and that an attacker can circumvent the isolation characteristic of a hypervisor. Using this approach an adversary can access the hypervisor, thereby giving him access to the memory of all VMs since the hypervisor is privileged against all VMs.

We will further analyze this attack in Section 7.7.2 and also present a mechanism to cope with this threat.

Attacks of type (2) and (3) can be performed if the attacker has taken full control of the system and, thus, successfully broken out of the Open VM. Since the attacker then has the same potential as if he had successfully overtaken the Management VM directly, we will discuss this issue in the next paragraph.

Attacks on the Management VM (Arrow 3) The Management VM runs a tiny operating system or microkernel with only a small set of services. These services are

7.7. EVALUATION OF THE ARCHITECTURE 131 mainly the security services explained in Section 7.5.1, namely theVM Manager,TPM Manager,TPM Device Driver,Secure Storage and a Measurement Agent. In addition, the Management VM provides split-device drivers [62] for all devices that cannot be virtualized with hardware measures [37]. A split-device driver is necessary for devices such as the TPM since currently available TPMs cannot be virtualized with hardware measures, as we will explain in Chapter 8.

To successfully perform an attack of type (1), an adversary has to exploit a vulner-ability in either the operating system of the Management VM, or in any of the security services offered by the Management VM. Since the memory of the management VM is also isolated from the memory of the TVM, a hardware attack, as explained in the preceding paragraph, can be used to access the memory of a TVM. This is visualised as arrow 3c in Figure 7.9. The risk of such runtime attacks on the Management VM are reduced, because the code complexity of the Management VM is very low and soft-ware with lower complexity is expected to have less errors than softsoft-ware with higher complexity. To additionally enhance the security, formal methods should be used to prevent the emergence of software vulnerabilities that could be exploited by an adver-sary. However, another disadvantage is that our software TPM extends the code base of the management VM, thus violating R.3 of a virtual TPM.

Additionally, the Management VM is responsible for providing a Secure Storage and the Measurement Agents. If an attacker gained access to the Management VM and is not able to perform a malicious DMA to access the memory of a TVM, he might perform an attack of types (2) and (3). He could achieve a type 3 attack, for example, by substituting the virtual appliance of the Trusted VM with a malicious virtual appliance and altering the measurement agent so that the agent provides malicious measurements (attack (3)). Alternatively, he could achieve an attack of type 2, for example, by altering measurements stored inside the virtual TPM’s storage or accessing cryptographic keys stored inside the vTPM. However, to successfully perform these attack types, he needs to modify the security services during runtime, i.e., after they have been measured. This is necessary since during the attestation, not only the measurements of the vTPM are validated, but also the measurements of the underlying hardware TPM. If an adversary only modifies the measurements of the vTPM, the measurements would differ from the measurements stored inside the hardware TPM (compare Section 7.5.3). However, it is much easier for an adversary to access data which are stored in a virtual TPM than if they were stored in the hardware TPM. For example, it is possible for an adversary to extract keying material from a software TPM by accessing the memory during runtime.

Although this may result in a malicious software configuration which can be detected, an adversary might have gained access to sensitive keying material. As a result, our software TPM does not completely achieve the security requirement for a virtual TPM (R.4) as presented in Section 7.5.3.

Attacks on the Hypervisor (Arrow 4) The hypervisor consists of a very low code complexity (e.g., Secvisor comprises of only 1112 lines of code [148]), particularly when compared to operating systems, and does not expose interfaces that could be used for

an attack; therefore, attacks of type (1) are difficult. If an attacker were to gain access to the hypervisor, he could perform attacks of types (1) and (2) as already discussed in the preceding paragraph.

Manipulate Input

Input manipulation attacks try to access confidential data by capturing keystrokes. In our security architecture, these attacks can be situated on the TVM, the Management VM or the hypervisor.

Manipulating the input at the TVM is rather difficult since the TVM’s code com-plexity is very low and the only possibility would be to perform a runtime attack and then install some sort of key-logger. Since the integrity of the TVM is measured each time it spawns, the time window to perform such an attack is very small. In addition, each attack needs to be performed from scratch since it is not possible to persistently modify the program code of the TVM. Another possibility for spying on a user’s en-tered confidential data is to modify the hypervisor or the management VM. This would lead to a successful attack if the keyboard device-driver were virtualized using software techniques [62]. If software techniques have been used to virtualize the keyboard device driver, a backend device driver resides in the Management VM and can be altered to spy on a user’s entered data. In that case, a successful runtime attack on the Management VM or the hypervisor must be performed.

However, if the keyboard device-driver are virtualized using hardware techniques [37], only a successful runtime attack in the TVM enables an attacker to capture keystrokes. Gaining access to the hypervisor or Management VM would in the lat-ter case not be sufficient to capture keystrokes.

Manipulate Output

Output manipulation attacks manipulate the information output of a software system.

These attacks are prevented by ensuring that the software integrity of the devices for information output are trusted. Here, as in the preceding sections, runtime attacks are still possible and the only threat.

Output attacks that exploit human characteristics, such as phishing [44], can be easily prevented by binding transaction data directly to a specific transaction session using cryptographic keys; because this solution is implementation specific and depends on the application scenario, we will present the security mechanisms in Section 9, where we present an application scenario and the corresponding security mechanisms.

Hardware Attacks

We have already discussed that hardware attacks can be used to perform software manipulation attacks. One such critical hardware attack is a DMA attack, currently the only method to circumvent the isolation characteristic provided by the hypervisor.

DMA attacks can either be handled entirely in software by emulating all I/O devices, thereby causing a high performance degradation, or by providing a hardware I/O MMU

7.8. IMPLEMENTATION 133