Table 2: TS Controller API for Attack Scripts
Description
h -- INIT()
FREE (h)
EXECUTE (h, app, params)
EVENTADD (h, eventType)
EVENTDEL(h,eventType)
event <- WAIT(h)
event <- WAITFOR(h,eventType)
CONT(h)
ACCESSREG(h,type,r/w,buf)
ACCESSMEM(h,v/p,r/w,addr,sz,buf)
INTERRUPT (h, num)
Initializes the TSC and returns a handle h to access the resources.
Free the resources for the handle h.
Execute the application app on SUT with the given parameters params.
Add the event Type to watch-list.
Delete the eventType from the watch-list.
Blocking call that waits for any event in the watch-list to occur in
the SUT. Once an event is triggered, the SUT is paused and the TS
continues running the attack script. An application exit in the SUT
always causes a return from WAIT().
Similar to WAIT() but waits for the specified event (or application
exit), regardless of the watch-list.
Execution of the SUT is resumed.
Reads/writes (r/w) the general registers or SP registers (type) of the
SUT to/from buf.
Reads/writes (r/w) sz bytes from virtual or physical memory (v/p) of
the SUT at address addr to/from the buffer buf.
Trigger a virtual hardware interrupt number num on the SUT.
against unknown attacks as well as known methods of
penetration by considering the most powerful attacker.
3.4 Implementation
We implemented our testing framework on VMware's
virtualization platform [8], including all of the mod-
ules in Section 3.2 and events and attacks at each sys-
tem layer. The Hardware Emulation Module and VMM
Event & Attack Module required modifying the source
code of the VMware VMM. The kernel components of
the TSP and TSC are implemented as Linux kernel
modules. The TSP application is implemented as a
Linux user process and controls the execution of the
Testing Application. The TSC application is imple-
mented as a static library which is called by the Attack
Scripts. Upon initialization, the TSC connects with the
TSP over the virtual network, and the TSP registers
with the Event and Attack Module via a hypercall to
the VMM.
As a sample security architecture, we implement the SP
architecture, described in Section 4. Hence, the Hard-
ware Emulation Module emulates the SP architecture
including its master secrets, secure memory, and inter-
rupt protection. We have also implemented a library
of protected software for SP, which is used for a remote
key-management application as described in Section 4.4.
Our Testing Application uses this library to exercise the
software, and in turn, the SP hardware.
4 SP Architecture and Emula-
tion
For the rest of this paper, we will use the Secret Protec-
tion (SP) architecture [1] [5] to demonstrate our frame-
work. We have chosen SP because it was specifically
designed to be as simple as possible to facilitate veri-
fication, while providing robust security utilizing both
hardware and software components. At the same time,
it uses a somewhat controversial and unproven design,
skipping layers in the trust chain by using hardware
to directly protect an application without trusting the
underlying operating system. To be accepted by the se-
curity community, SP's security properties need to be
validated, demonstrating that it can protect the confi-
dentiality and integrity of cryptographic keys in its per-
sistent storage which in turn protect sensitive user data.
Furthermore, it is important to write and test many se-
cure software applications to run on SP in a realistic
environment, where the untrusted OS can be a source
of attacks. To the best of our knowledge no single tool
exists to test hardware-software security architectures
like SP.
Our testing framework first emulates SP's hardware fea-
tures using modifications to the VMM. This allows us to
directly test the primitives and guarantees made by the
SP hardware itself and how those primitives interact
with software components. Additionally, we can con-
sider the hardware emulation as a constant and test a
Function
