Architecture Support for 3D Obfuscation Page: 15
This article is part of the collection entitled: UNT Scholarly Works and was provided to UNT Digital Library by the UNT College of Engineering.
Extracted Text
The following text was automatically extracted from the image on this page using optical character recognition software:
15
6) Supporting fork: In order to fork a protected pro-
cess, the OS has to invoke transferprot_process API of
Arc3D. This causes a new ST to be allocated to the
forked child process and then makes a copy of process
context as save_prot_process. Thus the parent and child
processes could be differentiated by Arc3D. OS has to
make a copy of SOTP for the child process.
7) Exiting a Protected Process: When a protected
process finishes execution, OS has to invoke
exit_prot_process API to relinquish the ST (state
OTP register) allocated to the process currently in
context. This is the only resource that limits the number
of protected process allowed in the Arc3D system.
Hence Arc3D is susceptible to denial-of-service (DOS)
kind of attacks.
8) Protected Cache: Arc3D has a protected direct
mapped L2 cache of page size, i.e., 64KB. This protected
cache is used to obfuscate the second order address se-
quences only for instructions, as temporal order doesn't
have any meaning with respect to data. Whenever there
is an ILl miss in protected mode, Arc3D sends request
to L2prot. Since L2prot is on-chip the access latency will
be small. We assume it to be 1 cycle. If there is a miss
in L2prot then L2 is accessed. L2prot is also invalidated
whenever a protected process is started or restored.
VI. ATTACK SCENARIOS
In this section we argue that Arc3D achieves our initial
goals, namely, copy protection, tamper resistance and
IP protection. Several attacks causing information leak
in various dimensions could be combined to achieve the
adversary's goal. These attacks could be classified into
two categories - attacks that target Arc3D to manipulate
its control or reveal its secrets. If the adversary is
successful in either getting the stored secret (Ek-) or in
changing the control logic, the security assurances built
upon Arc3D could be breached. But these type of attacks
have to be based on hardware, as there are no software
control handles into Arc3D. There are several possible
hardware attacks, like Power Profile Analysis attacks,
Electro magnetic signal attacks. The scope of this paper
is not to provide solutions to these attacks. Hence we
assume that Arc3D is designed with resistance to these
hardware attacks.
The second type of attacks are white-box attacks. Such
an attack tries to modify the interfaces of Arc3D to theexternal world, to modify the control. The guarantees
that are provided by Arc3D to software in protectedmode of execution are 3D obfuscation for protected
pages, and unique identity per CPU. Protected mode of
execution guarantees that the control is not transferred
to any unauthorized code (which is undetected). Arc3D
will fault when an instruction from an unprotected page
or from a page that was protected with different Ks
is fetched in protected mode. This will prevent buffer
overflow kind of attacks. 3D obfuscation provides us
both IP protection and tamper resistance. IP protection
is achieved because at every stage of its life, the binary
is made to look different, hence reducing the correlation
based information leaks to the maximum extent possible.
Tampering could be performed by many means. But all
of them have to modify the image of the process. Since
every cache-block in every protected page potentially
could have a different OTP the probability that the
adversary could insert a valid content is extremely small.
Applications can obfuscate new pages that are created at
run-time by designating them as protected. Applications
can further maintain some form of Message Digest for
sensitive data, because obfuscation only makes it harder
to make any educated guess, while random modification
of data is still possible. In the case of instructions the
probability that a random guess would form a valid
instruction at a valid program point is extremely small.
Another form of tampering, splicing attack, uses valid
cipher texts from different locations. This attack is not
possible because every cache block in every page has
a unique OTP and every page has a unique address
obfuscation function. This makes it hard for the ad-
versary to find two cache blocks with the same OTP.
Another common attack is replay attack, where valid
cipher text of a different instance of the same application
is passed (replayed). As we discussed earlier, this attack
is prevented by XORing Ks with a randomly generated
OTP which is kept in the Arc3D state. This value is used
as a key to encrypt the protected process's context. Thus
when restoring a protected context, Arc3D makes sure
that both Sauth and saved context are from the same run.
When the adversary knows the internals of the underly-
ing architecture, another form of attack is possible. This
form of attack is denial of resources, which are essential
for the functioning of the underlying architecture. For
example, XOM maintains a session table and has to store
a mutating register value per session-id. This mutating
register is used to prevent any replay attacks. This kind
of architecture has an inherent limitation on the number
of processes it can support, i.e., the scalability issue.Thus an attacker could exhaust these resources and make
the architecture non-functional. This kind of attack is
Upcoming Pages
Here’s what’s next.
Search Inside
This article 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 Article.
Gomathisankaran, Mahadevan & Tyagi, Akhilesh. Architecture Support for 3D Obfuscation, article, April 3, 2006; [New York, New York]. (https://digital.library.unt.edu/ark:/67531/metadc132973/m1/15/: accessed April 25, 2024), University of North Texas Libraries, UNT Digital Library, https://digital.library.unt.edu; crediting UNT College of Engineering.