Framework for Design Validation of Security Architectures Page: 3
The following text was automatically extracted from the image on this page using optical character recognition software:
emulate the most knowledgable attacker.
3 Testing Framework
The design goals of our testing framework are to create a
generic platform that can emulate and test a wide range
of security architectures in a realistic environment. It
must test the architecture-specific application software
running on top of full commodity operating systems.
The testing framework should also allow easy monitor-
ing of software and hardware events, and allow modifi-
cation of software and hardware state to launch attacks
on the system.
A virtual machine monitor (VMM) is the software which
creates Virtual Machines (VMs), efficiently providing
an execution environment in each VM which is almost
identical to the original machine . By modifying an
existing VMM, we can augment the virtual machine to
have the additional hardware features of our new secu-
rity architecture in addition to those of the base ma-
chine. Since we are still using efficient virtualization
software, we can run commodity operating systems and
applications in our modified virtual machines.
Our Testing Framework is divided into two systems, as
shown in Figure 2, the System Under Test (SUT) and
the Testing System (TS), each running as a virtual ma-
chine on our modified VMM. The SUT machine simu-
lates the system being designed and tested for the new
security architecture, as if it were actually built and
programmed. The TS machine simulates the attacker,
who is trying to violate the security properties of the
SUT. Through a variety of hooks in our modified VMM
and guest OS, the TS has full access to the internal
operations and state of the SUT.
System Under Test
I) Software (TS})
TS Proxy ,/ Controller Attack
App \ App Scripts
, , A
TSP ' \ TSC
Event & Event &
Security HW - attack attack
Emulator module module VMM (hooks added)
Figure 2: Testing Framework Design
In isolation, the SUT is meant to behave as closely as
possible to a real system which has the new security
architecture. It must behave as if it has all of the new
security primitives available in hardware, along with the
corresponding protected software for that architecture.
In our current system, the SUT runs a full commod-
ity operating system (Linux) as its guest OS, which is
vulnerable to attack and is untrusted. However, for the
purposes of the testing framework, we add a software
component, the TS Proxy (TSP), to the SUT to sim-
ulate the effect of a compromised operating system for
launching software attacks, allowing the OS to be fully
controllable by the TS- as if it has been compromised.
It is still necessary to keep the TS as a separate virtual
machine so that the TS Proxy in the SUT need not be
invoked to launch a virtual hardware attack.
For the purposes of fully exploring the design space of
new security architectures, the TS has the additional ca-
pability to be a super-attacker. The testing framework
itself is ignorant of the threat model of the system be-
ing designed, and instead enables full controllability and
observation of the SUT in both hardware and software.
This makes it suitable for many purposes during the de-
sign phase of a new architecture. For initial design and
implementation of the system, the TS can act as a de-
bugger, able to see the lowest-level micro-architectural
behaviors of the hardware features and all code behav-
ior and data in the software stack. When testing the
supposedly correct system, the TS is the attacker, con-
strained by a threat model to certain attack vectors.
A particular point of elegance of our framework is that
the threat model can be easily changed, and the set
of attack tools given to the attacker adjusted for each
test. The framework can be used for any combination of
mechanisms: access to internal CPU state of the virtual
processor, "physical" attacks on the virtual machine
hardware (e.g. hardware probes on the buses, mem-
ory, or disk), software attacks on the operating system
(e.g. a rootkit installed in the OS kernel), and network
attacks (e.g. interception and modification of network
packets and abuse of network protocols and application
data). For example, in some cases, it might be desir-
able to perform black-box testing of a new design using
only the network to gain access to the SUT, while in
other cases, white-box testing will allow the attacker
knowledge about the system's activities, such as precise
timing of attacks with hardware interrupts or break-
points into the application code or observation of data
structures in memory.
3.2 Testing Framework Modules
The main components of our Testing Framework shown
in Figure 2 are: the Testing System Controller (TSC),
the Testing System Proxy (TSP), the Events and Attack
Here’s what’s next.
This report can be searched. Note: Results may vary based on the legibility of text within the document.
Citing and Sharing
Basic information for referencing this web page. We also provide extended guidance on usage rights, references, copying or embedding.
Reference the current page of this Report.
Dwoskin, Jeffrey Scott, 1980-; Gomathisankaran, Mahadevan & Lee, Ruby Bei-Loh. Framework for Design Validation of Security Architectures, report, November 17, 2008; [Princeton, New Jersey]. (digital.library.unt.edu/ark:/67531/metadc130192/m1/3/: accessed March 23, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.