Framework for Design Validation of Security Architectures Page: 9
The following text was automatically extracted from the image on this page using optical character recognition software:
how the security-critical components of the remote key-
management software can be partitioned off into a TSM
which can be used by other software. Using the frame-
work, we then subject our TSM to a suite of attacks to
see if the desired security properties are preserved.
For remote key-management, we consider a central
trusted authority which owns multiple SP devices and
wants to distribute sensitive data to them. The author-
ity installs its remote key-management TSM on each
device as well as the protected data, consisting of se-
crets and cryptographic keys that protect these secrets.
It also stores policies for each key which dictate how it
may be used by the local user. During operation, the
TSM will accept signed and encrypted messages from
the authority to manage its stored keys, policies, and
data. It also provides an interface to the application
through which the local user can request access to data
according to the policies attached to the keys. The TSM
must authenticate the user, check the policy, and then
decrypt and display the data as necessary.
Testing SP requires testing TSM software in combina-
tion with SP hardware mechanisms. The TSM pro-
vides protection for the application's critical data and
is itself protected by the SP hardware. We can at-
tack the robustness of the TSM's memory usage, persis-
tent storage, network protocols, and software interfaces.
We thereby use our testing framework as a testbed for
secure software development in addition to the secure
hardware both the software TSM and the hardware
SP features are required to provide SP's confidentiality
and integrity guarantees.
4.5 Testing Example
We now give an example of how the TSC can test an ap-
plication and TSM running on the SUT. Table 3 shows,
on the left, the protected application using a TSM
(TSMapp) and a corresponding unprotected application
(unsafeApp). The attack script is shown on the right.
The attack simulates a compromised OS trying to access
confidential data currently being used by a TSM (in this
case, a secret key used for encrypting sensitive data) by
interrupting the TSM during its execution. The TSMapp
uses SP instructions to enter and exit protected mode
(BEGIN TSM and END TSM) and to generate a key
(DRKDeriveKey). The unsafeApp is instrumented to
explicitly notify the TSP (with TSPNotify)when it
generates a key.
The application first generates a new key, for
TTP KeylD, which it uses to encrypt data. It then
sends the encrypted data over the network to the re-
mote Trusted Third Party (TTP). In the first line of the
attack script, the TSC launches the testing application,
either using the TSMapp (where we expect the attacks to
fail) or the unsafeApp (where the attacks should suc-
ceed). The script then watches for a particular event to
occur in the application, in this case the generation of a
key. The application executes normally until it triggers
this event which the attack script is monitoring.
Steps 1-5 in figure 4, show the steps taken by the testing
framework to detect an event. In step 1, the TSM uses
an SP instruction to generate a new derived key from
the DRK master secret. This requires making a hyper-
call down to the SP HW Emulation Module to emulate
the instruction and produce results into the general reg-
isters. In step 2, the SP HW notifies the Event & Attack
Module of this HW event (the execution of an SP in-
struction). In step 3, the event is passed up to the TSC
kernel module via a virtual HW interrupt/IRQ, and the
VMM freezes execution of the entire SUT. In step 4, the
TSC is notified of the event via a Linux signal. In step
5, the TSC returns the event to the attack script which
was waiting for notification of this key generation event.
It can now continue executing the script to perform any
hardware attacks while the SUT is frozen. These steps
are repeated for every hardware event monitored by the
System Under Test
TS Proxy - Controller Attack
," TSM App I App Scripts
TSP / TSC
Hypercallj Linux Kenel Kernel Linux
S Event& Event &
SP HW , attack attack
Emulator module module VMM (hooksadded)
Figure 4: Example Attack Sequence
The script resumes the TSM and then attacks by in-
structing the TSC to generate an interrupt during the
TSM's execution. This triggers the SP HW's interrupt
protection mechanism, encrypting the general registers
and secure memory, and suspending protected mode for
the TSM. Next the script, acting like a corrupted oper-
ating system's interrupt handler, attempts to read and
modify the TSM's general registers. It overwrites the
generated key with a known key. With SP protection, it
can only read an encrypted version of the registers, and
upon resuming from the interrupt, the incorrect gen-
eral register values will cause an SP fault. If the same
attack is performed using the unprotected application
without SP and its TSM, the attacker would obtain the
generated key and the user of the SUT would remain
unaware of the modification to its registers, encrypting
with a key known to the attacker.
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/9/: accessed April 23, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.