How to Hide Secrets from Operating System: Architecture Level Support for Dynamic Address Trace Obfuscation Page: 1
The following text was automatically extracted from the image on this page using optical character recognition software:
How to Hide Secrets from Operating System:
Architecture Level Support for Dynamic Address
Abstract- The adversary model for digital rights management
is much more powerful than for the traditional security scenarios.
The adversary has complete control of the computing node -
supervisory privileges, physical as well as architectural object
observational capabilities. In essence, this makes the operating
system (or any other layer around the architecture) itself the
adversary. The repercussions of this observation are severe. It
creates a need to "keep secrets" from the operating system (OS).
It isolates the architecture from the operating system.
We argue for the need to keep secrets from the OS in hardware.
This concept is demonstrated through architectural support for
the obfuscation of dynamic address traces on the memory bus.
The objective is to leak as little information about the executed
program sequence as possible. This is done by handing over
many of the virtual memory management responsibilities from
the operating system to an architecturally isolated hardware
black-box (VM black-box). We provide a detailed design for
the VM blackbox and some microarchitecture level simulation
derived performance data. We also describe a compiler directed
prefetch scheme that uses both instruction and data prefetches to
obfuscate the address traces on the address bus between on-chip
L2 cache and memory.
Digital rights management (DRM) refers to the process of
protecting the intellectual property (IP) embedded in digital
domain. This paper addresses digital rights management for
software. The DRM violations for software can result in
either financial losses for the software developers or a loss
of competitive advantage in a critical domain such as defense
(for example, when an aircraft lost in hostile territory contains
embedded systems with critical IP). Software piracy alone
accounted for $13 billion annual loss  to the software
industry in 2002.
Software digital rights management traditionally consists
of watermarking, obfuscation, and tamper-resistance. All of
these tasks are made difficult due to the power of adversary.
The traditional security techniques assume the threat to be
external. The system itself is not an adversary. This provides
a "safe haven" or "sanctuary" for many security solutions.
However, in DRM domain, the operating system itself is not
trustworthy. On the contrary, the operating system constitutes
the primary and formidable adversary. This is where the core
of the difficulty arises. In essence, every security technique
needs to hide some secrets from its adversary. Where can
a DRM technique hide such "secrets"? The current system
design exposes every system component to the operating
system (OS). The access rights model is hierarchical with an
entity at a higher level endowed with the access rights of all its
children and some more. In such a model, the operating system
sits at the root node. In such a scenario, there is no "sanctuary"
left for the DRM technique's secrets that is not accessible
to the operating system. Hence, we believe that the primary
distinction between the traditional security and DRM is that
the focus shifts from the problem of "protecting the operating
system from adversary" to the problem of "protecting the
program from the operating system". A key thesis of this
paper is: "All of the component technologies of digital rights
management: specifically watermarking, static and dynamic
behavior obfuscation, and tamper resistance can be made
significantly more robust if they have a mechanism to hide
a secret from the operating system.".
Any software-only solution to the "secret-hiding" from
OS seems to be inadequate. It leads to the classical meta-
level inconsistencies encountered in classical software verifi-
cation derived from Gadel's incompleteness theorem. In the
end, in most scenarios, it reduces to the problem of "last
mile" wherein only if some small kernel of values could
be isolated from the operating system (as an axiom), the
entire schema can be shown to work! At this point, it is
worth noting that even in the Microsoft's next generation
secure computing base (NGSCB) , the process isolation
from operating system under a less severe adversary model
is performed with hardware help. The NGSCB's goal is to
protect the process from the operating system corrupted by
external attacks by maintaining a parallel operating system
look-alike called "nexus". The nexus in turn relies upon a Se-
curity Support Component (SSC), a hardware component, for
performing cryptographic operations and for securely storing
cryptographic keys! The trusted computing group consisting
of AMD, HP, IBM, and Intel among many others is expected
to release trusted platform module (TPM) , to provide the
SSC hardware support. Our own experience with static and
dynamic obfuscation and tamper resistance has convinced us
that without hardware support not very robust guarantees can
be made for any of these technologies.
We explore architecture level support for the one DRM
component, dynamic address obfuscation. The resulting archi-
tecture collectively is called DRMAr (DRM Architecture).
A. Dynamic Address Obfuscation
Static obfuscation is designed to make it hard to infer
anything more than what is already observable through a
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.
Gomathisankaran, Mahadevan & Tyagi, Akhilesh. How to Hide Secrets from Operating System: Architecture Level Support for Dynamic Address Trace Obfuscation, report, 2004; (digital.library.unt.edu/ark:/67531/metadc94282/m1/1/: accessed November 23, 2017), University of North Texas Libraries, Digital Library, digital.library.unt.edu; crediting UNT College of Engineering.