Palladium and malware

[Nomen Nescio]

Paul Crowley asks: > I'm informed that malware authors often go to some
lengths to prevent > their software from being disassembled.  Could they
use Palladium for > this end?  Are there any ways in which the facilities
that Palladium > and TCPA provide could be useful to a malware author
who wants to > frustrate legitimate attempts to understand and defeat
their software?

Palladium provides a "curtained" memory area where software is supposed to
be relatively free from being accessed or modified.  (Apparently it can be
configured to be debugged when in this area by the use of "test keys".)
If disassembling a program requires access to it in memory, then this
curtained memory region could present an obstacle to disassembling.

However in most cases the memory would be loaded from the disk so having
access to the program on disk would allow you to disassemble it just as
well as if it were in memory.  From what has been said about Palladium,
it will not support encrypted programs.

However that might not stop a determined malware author from having the
program encrypt itself when it first runs (using the "virtual vault"
concept) and store the encrypted version on the disk, deleting the
original plaintext version.  The Palladium vault technology would
then make it impossible for any other software to decrypt that data.
The malware might not be able to use the regular Palladium program loader
to run its encrypted portion, but conceivably it could "manually" load
that encrypted data into the curtained area, decrypt it using a key
accessible only to itself, and then run.

This would still leave the program vulnerable until the first time it
runs, but afterwards it would be impossible to get at the program text
in the clear.

A program could reduce its window of vulnerability if it were distributed
in encrypted form, using a key that would be provided by a remote server
- which could even be any other infected computer!  The program stub
would start up, use Palladium attestation to connect reliably to another
virus-corrupted instance of itself on the net, and receive a global,
system-wide key.  This key would be kept locked in the "virtual vault"
and would decrypt the remainder of the program, which could then run in
the curtained area.  Even if all instances of the virus shared the same
key or set of keys, it would be impossible for non-virus programs or
programmers to get access to the key except by hacking their hardware,
scraping out a key, and creating a virtual Palladium system.

So the main question at this point is how program code and/or data gets
loaded into the curtained area, and whether it would be possible to
load encrypted data into that area, decrypt it and then run it as code.
There is a computer design called the Harvard architecture which has a
strict separation between code and data space, and conceivably Palladium
could use a similar approach to make it impossible to run decrypted code.
Adopting this approach would add credibility to Microsoft's promises
not to use Palladium for software copy protection.  But if they don't
go to such an extreme, it is likely that Palladium would allow the use
of various techniques to help malware hide from its opponents.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com