Our testing framework can model real attack mecha-
nisms using known penetration mechanisms. It can also
model unknown future attacks by more powerful adver-
saries by enabling direct attacks on software and hard-
ware components that may go beyond known penetra-
tion methods. We do this by mapping attacks to their
impacts on the SUT. Hence, a key advantage of our sys-
tem is that it allows design-time testing assuming a very
powerful attacker to test the limits of the SUT, without
the need to find a specific penetration path through the
system.
The primary contributions of this work are:
* a new flexible framework for design-time testing
of new hardware-software architectures for security
properties, leveraging VMM technology;
* a realistic environment using commodity operating
systems for testing different applications using the
new security mechanisms;
* a flexible, fast, and low-cost method for emulating
HW features in the VMM for the purpose of design
validation- without the need for costly and time-
consuming fabrication of HW prototypes;
* the ability to simulate the impact of very powerful
attackers for "future" attacks; and
* the application of our framework towards the val-
idation of the security properties of the SP archi-
tecture [1, 5].
The rest of our paper is organized as follows: Sec-
tion 2 discusses hardware-software architectures and
their threat models. Section 3 describes the architec-
ture and implementation of our new testing framework.
Section 4 describes the SP architecture, its emulation in
the testing framework, and methodologies for its test-
ing. Section 5 offers results and sample security attacks.
We discuss related work in Section 6 and conclude in
Section 7.
2 Hardware-Software
Architectures
Security
New security architectures can take many forms. For
this work, we focus on hardware-software architectures
where new hardware security mechanisms are added
to a general-purpose computing platform to protect
security-critical software and its critical data. The hard-
ware provides strong security protection which cannot
be bypassed, and the software provides flexibility to im-
plement different applications and usage scenarios, with
different security policies.
Figure 1 shows a typical system with the addition of a
trusted software application and new trusted hardware
_- Network
Protected App Normal App
CPU
General
Registers
pProc
Core
Cache
New Display, Nt
Hardware i10 Network
_ _ _
HW
probe
I
/
Trusted Component Untrusted Component Attack Source
Figure 1: Threats and Attacks on Security Architec-
tures
security mechanisms added to the CPU (e.g. new in-
structions, faults, registers, and hardware mechanisms).
Sometimes, as shown in the figure, the OS cannot be
trusted, especially if it is a large monolithic OS like
Windows or Linux. Other times, an architecture might
trust parts of the operating system kernel (e.g. a mi-
crokernel [6]), but not the entire operating system.
The figure also shows the sources of attacks that we
consider in our testing framework. First, malware or ex-
ploitable software vulnerabilities can allow adversaries
to take full control over the operating system to perform
software attacks. They can access and modify all OS-
level abstractions such as processes, virtual memory and
virtual memory translations, file systems, system calls,
kernel data structures, interrupt behavior, general reg-
isters, and I/O.
Second, if adversaries get physical possession of a device,
they can perform hardware attacks, such as directly ac-
cessing data on the hard disk, probing physical memory,
intercepting data on the display and I/O buses. Very
powerful attackers may even be able to probe parts of
the processor chip.
Third, network attacks can be performed with either
software or hardware access to the device, or with ac-
cess to other parts of the network. Some network attack
mechanisms act like software attacks (e.g. remote ex-
ploits on software), while others attack the network it-
self (e.g. eavesdropping attacks) or application-specific
network protocols (e.g. modification attacks and man-
in-the-middle attacks).
In order to adequately test a new security architecture,
all of these attack mechanisms must be considered and
tested. Our testing framework provides hooks into each
relevant system component, and additionally allows in-
formation and events at each level to be correlated to
