Framework for Design Validation of Security Architectures Page: 4
The following text was automatically extracted from the image on this page using optical character recognition software:
Table 1: Example Events and Attacks
Layer Events Monitored Impact of Attack
Protected Application API function entry/exit, Library calls, Read/write application data structures,
User authentication, Network messages, Trigger application API calls, Inter-
Other application-specific events. cept/modify network messages, Other
OS Memory access watchpoints, Virtual Read/write virtual memory, Read/write
memory paging, File system access, Sys- kernel data structures, Read/write file
tem calls, Process scheduling, Instruction system, Intercept/modify syscall pa-
breakpoints, Device driver access, Net- rameters or return values, Read/write
work socket access, Interrupt handler in- suspended process state, Modify pro-
vocation, etc. cess scheduling, Intercept/modify net-
work data, Modify virtual memory trans-
Base Hardware (x86) Privileged instruction execution, Trig- Read/write general registers, Read/write
gering of page faults and other in- physical memory, Trigger interrupts, In-
terrupts, Execution of an Instruction tercept device I/O (e.g. raw network &
pointer. disk accesses).
Secure Architecture Execution of new instructions, Trigger- Read/write new registers & state,
Hardware ing of new faults, Accesses to new regis- Read/write protected memory plaintext.
module, the Hardware Emulation Module, the Testing
Application, and the Attack Scripts. The TSC and TSP
are each divided into a user-level application and a com-
ponent in the OS kernel.
A System Under Test is comprised of three layers,
namely: Application, Operating System, and underly-
ing Hardware. The Testing System should be able to
both monitor the events and modify the state in all
three of these layers. The modified VMM monitors and
controls the hardware, while the the TSP monitors and
controls the applications and OS.
The TS and SUT components communicate to exchange
information about events occurring in the SUT and to
implement attacks from the TS by modifying system
state in the SUT. The user level components communi-
cate with the kernel components through system calls,
and the kernel components use signals to communicate
asynchronously with the user level components. The
VMM communicates with the guest OS kernel asyn-
chronously through a new virtual hardware interrupt
which we have defined.
Testing System Controller The TS Controller,
running on the TS, is the aggregation point that re-
ceives events from all three layers in the SUT. It re-
ceives OS and Application level (software) events from
the TS Proxy via a network channel and receives hard-
ware events from the VMM through a channel from its
kernel-level component. It provides APIs to the Attack
Scripts which can monitor or wait for specific events and
adaptively mount a coordinated attack on the SUT.
Testing System Proxy This module acts as a proxy
for the TSC running on the SUT itself. It controls
the application to be tested, and uses its corresponding
kernel-level component to control and monitor OS be-
havior and the OS-level abstractions used by the testing
application, including system calls, virtual memory, file
systems, sockets, etc. The TSC communicates with the
TSP over TCP/IP on the virtual network which con-
nects the VMs. Note that the TSP is used to simulate
the impact of a compromised OS in the SUT, whereas
in the framework the OS itself is not actually compro-
Event and Attack Module This module provides
hooks to both observe and control the internal machine
state of the SUT from inside the VMM. The TS Con-
troller registers with this module for the set of events
to be monitored, and uses the APIs provided by this
module to observe or modify (i.e., attack) the state.
Events that can be watched include: interrupts/faults
specific to the secure architecture, execution of new in-
structions, execution of new behaviors (e.g. modified
hardware interrupt handling), regular x86 interrupts,
etc. Machine state that is exposed includes CPU reg-
isters, physical memory, and the new registers for the
secure architecture. Note that unlike a normal attacker,
this model is very powerful and can stop the machine
precisely for observation or modification before or af-
ter any specific instruction execution or other detected
Here’s what’s next.
This report can be searched. Note: Results may vary based on the legibility of text within the document.
Tools / Downloads
Get a copy of this page or view the extracted text.
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/4/: accessed August 18, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.