[11613] in cryptography@c2.net mail archive
Re: Palladium and malware
daemon@ATHENA.MIT.EDU (Bill Frantz)
Wed Sep 4 18:14:52 2002
In-Reply-To: <aed2b04e03b35c889abd9976c4c68736@dizum.com>
Date: Tue, 3 Sep 2002 19:54:10 -0700
To: Nomen Nescio <nobody@dizum.com>, cryptography@wasabisystems.com
From: Bill Frantz <frantz@pwpconsult.com>
At 9:00 PM -0700 8/30/02, Nomen Nescio wrote:
>Bill Frantz writes, regarding the possibility that the Palladium
>architecture could be designed to resist the use of encrypted
>code:
>
>> All general purpose computers require a way to move data space to code
>> space to support compilation.
>
>Well, this is usually done by storing the data to the disk, and
>then later loading it as a program file. It does not prevent data
>and code memory from being distinct, which was the proposal for how
>Palladium could reduce the risk of being used to run encrypted code.
>If a Palladium program was forced to go through the disk, that is, to
>load data, decrypt it, store it to the disk, and then load it as code,
>then that would provide a means to get access to the unencrypted code,
>defeating the goal of keeping the code within the "vault".
Usually, but not always. Just-in-time compilation systems take interpreted
code sequences and compile it, in RAM, to machine instructions. A number
of Java virtual machines make use of this technique. More relevant, it is
also applicable to some of the Microsoft languages.
>> Even if you don't allow compilation, most
>> modern systems have enough different powerful scripting languages that
>> interpretation is sufficient to support viruses.
>
>It's not clear why these languages would use the Palladium features and
>run their scripts in the shielded mode. But you're right that if they
>did, this could provide a mechanism for disassembly-resistant code.
Well, some vendors might want to protect their scripts. Just because a
program is written in an interpreted language instead of a compiled
language doesn't mean that vendors don't want to protect their code. There
is an active market in Java obfuscators for just this reason.
Cheers - Bill
-------------------------------------------------------------------------
Bill Frantz | The principal effect of| Periwinkle -- Consulting
(408)356-8506 | DMCA/SDMI is to prevent| 16345 Englewood Ave.
frantz@pwpconsult.com | fair use. | Los Gatos, CA 95032, USA
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
