Framework for Design Validation of Security Architectures Page: 7
The following text was automatically extracted from the image on this page using optical character recognition software:
range of software implementations which take advan-
tage of the SP hardware. We wish to test how SP hard-
ware protects its software, how trusted software can be
written to take advantage of the hardware guarantees,
and how trusted software interacts with untrusted soft-
ware on an SP device.
4.1 Secret Protection Architecture
In the Secret Protection (SP) architecture, the hardware
primarily protects a Trusted Software Module (TSM),
which protects the sensitive or confidential data of an
application. Hence, a TSM plus hardware SP mech-
anisms form the equivalent of the trusted computing
base (TCB) for the application. Rather than protect-
ing an entire application, only the security-critical parts
of an application are made into a TSM, while the rest of
the application can remain untrusted. Furthermore the
operating system is not trusted; the hardware directly
protects the TSM's execution and data.
Protecting the TSM's execution requires ensuring the
integrity of its code and the confidentiality and integrity
of its intermediate data. Code must be protected from
the time it is stored on disk until execution in the pro-
cessor. Data must be protected any time when the op-
erating system or other software can access it. This in-
cludes storage on disk, in main memory, and in general
registers when the TSM is interrupted.
To provide this protection, SP maintains its state using
new processor registers. It assumes the processor chip
to be the security boundary, safe from physical attacks
which are very costly to mount on modern processors.
As shown in Figure 3, SP uses two on-chip master se-
crets: the Device Root Key (DRK) and the Storage
Root Hash (SRH). For code integrity, the DRK is used
to sign a MAC (a keyed cryptographic hash) of each
block of TSM code on disk. When a TSM is execut-
ing, the processor enters a protected mode called Con-
cealed Execution Mode (CEM). As the code is loaded
into the processor for execution in the protected mode,
the processor hardware verifies the MAC before execut-
ing each instruction. For the TSM's intermediate data,
while in protected mode, the TSM can designate cer-
tain memory accesses as "secure", which will cause the
data to be encrypted and hashed before being written
to main memory. This secure data is verified and de-
crypted when it is loaded back into the processor from
secure memory. Secure data and code are tracked with
tag bits added to the on-chip caches. Additionally, the
SP hardware intercepts all faults and interrupts that
occur while in the protected mode before the OS gets
control of the processor. SP will encrypt the contents of
the general registers in place, and keep a hash of the reg-
isters on-chip in the interrupt registers to verify before
decryption when the TSM is resumed.
_-----TSM UserApp 1 UserApp 2
: .. "' Operating System
Disk * Processor Chip Concealed
/1 Storage Root Hash Execution Main
SUser I/O ic Mode Memory
/ Device Root Key
Interrupt I Data Hashing
(a) Registers Caches Engine
Figure 3: Secret Protection (SP) Architecture. Enlarge-
ments show (a) the additional CEM hardware and (b)
the application secrets protected by the TSM.
Secret data belonging to the application is also pro-
tected in persistent storage by encryption using keys
protected by the TSM. SP allows a TSM to derive new
keys from the DRK using a new hardware instruction,
DRK DeriveKey. These derived keys are used by the
TSM to protect the confidentiality and integrity of its
persistent data. Other software, including the OS, may
not use the DRK DeriveKey instruction. The TSM is
also the only software that can read and write the SRH
register, using it as the root of a hash tree to protect
the integrity of this persistent secure data.
Hence, to emulate SP hardware we require the follow-
ing components: new processor registers (including the
protected mode and master secrets); new instructions;
hardware mechanisms for code integrity checking, se-
cure memory, and interrupt protection; and new hard-
ware faults which these mechanisms generate.
4.2 Emulation of the SP Architecture
A traditional VMM provides a virtual machine which
is (nearly) identical to the physical machine, matching
the instruction set and behavior of the real CPU. It does
this by trapping or translating privileged code, while ig-
noring microarchitecture effects that do not affect pro-
gram correctness, such as cache memory. Most of the
time, the VMM runs code on the physical hardware,
and only emulates the components that are virtualized.
In order to implement and emulate new hardware archi-
tecture features, we take advantage of the VMM's vir-
tualization methods. For example, the VMM maintains
data structures for the virtual CPU state, which we can
expand to store new security registers. The VMM then
emulates accesses that are made to those new registers.
Other useful VMM behaviors include: interception of all
hardware interrupts, binary translation of code, map-
ping of virtual memory translations, and virtualization
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/7/: accessed January 22, 2018), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.