Framework for Design Validation of Security Architectures Page: 5
The following text was automatically extracted from the image on this page using optical character recognition software:
hardware event. In Figure 2, we show this module split
within the VMM into two separate components for each
VM to accommodate the split-VMM structure present
in some virtualization software.
Hardware Emulation Module This component,
added to the VMM, emulates the behavior of the new
security architecture to be tested. It enhances the
base micro-architecture with new instructions, func-
tional units, registers, interrupts/fault behaviors and
memory access behavior. New instructions are exported
to the software layers through hypercalls, which allow
application or OS layers to directly invoke the VMM.
Testing Application The Testing Application is the
actual implementation of the application software that
would be run on the secure architecture. It should
demonstrate the features of the architecture and pos-
sibly interact with a local user to provide access to se-
crets and data which the architecture is protecting. The
testing framework has hooks that allow the application
to report any internal events such as function calls or
decision points. The usage of these hooks are optional
and is required only if the application level events need
to be monitored for the attack script.
Attack Scripts The Attack Scripts reside on the TS
and specify how particular attacks are executed on the
SUT. They provide step-by-step instructions for mon-
itoring events and dynamically responding to them in
order to successfully launch attacks, or detect that an
attack was prevented by the security architecture. The
scripts act like a state-machine, acting on hardware and
software events which are aggregated by the TS. Scripts
can be written to form a library of generic attacks, that
can be used to attack any application. Alternatively
they can be specific to the behavior of the testing ap-
plication, written by the user of the testing framework.
The TS Controller reads and executes these scripts and
implements the communication mechanisms and control
of the SUT as needed.
In addition to these components, the TS hosts and emu-
lates any other trusted third parties required by the sys-
tem, possibly intercepting and modifying their network
traffic as an additional source of events and attacks.
By using two separate virtual machines to host the com-
ponents of our testing framework, we are able to keep
the SUT as close as possible to the real security archi-
tecture being tested, including all of its software com-
ponents, both trusted and untrusted. We do not need
to trust the SUT's guest OS for the sake of correctness
of the emulation of new hardware security features. In
fact, the SUT's guest OS can launch real attacks on the
system (as controlled by the TS).
We also have the ability to use the separate VM to
launch hardware attacks asynchronously from the TS;
the TS can pause the execution of the entire SUT VM
and continue running the attack scripts to inject attacks
at any instruction boundary.
3.3 Events and Attacks
The testing framework is designed to expose events from
the three layers of the SUT (application software, OS,
and hardware) to the TS, and to allow the TS access
to the state of the SUT to launch attacks. Table 1 lists
various events and attacks for each layer of the system.
The hardware layer is further classified into events and
attacks from the base hardware (x86 architecture in our
work) and the new emulated security architecture.
The hardware layer is accessed by the TS Controller
through the event and attack module in the VMM,
which communicates events across an inter-VM channel
inside the VMM to relay events and attacks between
the SUT and TS. This channel is used to communicate
with the TS during execution of a single instruction or
HW operation in the SUT, possibly changing the result
of that operation.
The software layers are accessed through the TS Proxy,
which hooks into the OS kernel through its kernel mod-
ule, and to the testing application using its user-mode
component. The TSP can function as a debugger tool
reading the application's memory and accessing its sym-
bol table to map variable and function names to vir-
tual addresses. The application can also optionally be
instrumented to access its state and events. The TS
Proxy suspends scheduling of the application's process
while it is communicating an event or attack to the TS
The SUT modules in both the hardware and software
layers capture their relevant events and signal the TS
Controller. The controller, following its attack scripts,
can then attack the SUT based on those events. Table 2
lists the API which the TS Controller exports to the
attack scripts for event handling and the basic attack
The attack mechanisms we provide are designed around
the impact that attacks have on the state of the SUT.
The security properties and attacks considered in the
threat model of a given security architecture may in-
stead focus on the method of penetration used to ac-
cess that state. For our testing framework, we enable
a powerful attacker without regard to how penetration
occurs. This is preferred since (1) new attack penetra-
tion methods are frequently discovered after a system
is deployed and often are not foreseen by the designer,
(2) most real attacks result in or can be modeled by the
impact of attacks which we provide in Table 1, and (3)
the attack scripts themselves can be restricted to model
specific penetration methods when testing for a more
limited attacker. Thus an architecture can be tested
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/5/: accessed April 24, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.