Palladium, not a good thing? (was Re: [H-GEN] antivirus and squid recommendations?)

[Anthony Towns]

> On Tuesday 14 January 2003 05:01 pm, Tony Nugent wrote:
> > DRM (digital rights
> > management) has the ability to not only kill the very concept of
> > viruses, 

On Tue, Jan 14, 2003 at 05:56:46PM +1000, Ewan Edwards wrote:
> http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html

That one has a link to Microsoft's technical Palladium FAQ:

 http://crit.org/http://www.t8o.org/~mca1001/crit/cached/0821PalladiumFAQ.html

which says:

] Q: Will "Palladium" really stop spam/prevent viruses for me?
] 
] A: Unfortunately, no. Despite the hype in the media, "Palladium" will not
] stop spam or prevent viruses all by itself. But by using "Palladium" as a
] foundation, there are a number of trust and infrastructure models we can
] build that will help combat spam and viruses in new and effective ways.

It goes on to handwave about spam prevention in a fairly unconvincing way,
and indicates that it could make virus checkers a bit more reliable. Which
is about as far as you can get from eliminating either as you can get,
without actually helping them.

Anyway, to blather a bit: DRM, by definition, is about allowing
the producer of some data to limit access to it on systems owned
by consumers. This could perhaps be used to limit you to verbatim
copying rather than distributing modified copies (ie, one with a virus
attached). This assumes a whole bunch of things, though:

	* that modification is blocked; most DRM schemes are more
	  interested in stopping copying altogether, tracing copies
	  whether they've been modified or not, and so forth. Blocking
	  distribution of modified copies isn't any more difficult than
	  the other things DRM covers, but it doesn't help Microsoft or
	  Disney stop people making pristine copies of their products,
	  so it doesn't seem likely to get much attention

	* that this applies to the majority of shared data; mp3s,
	  formatted documents, and emails have all potential vectors for
	  viruses in recent history, so all of them would have to be DRMed

	* that you can't "tar" the unmodified contents, and distribute it
	  *with* something else. Saying "Here is the program you requested",
	  and giving them a script that does something like:

		#!/bin/sh
		echo larooti::0:0:root:/:/bin/sh >>/etc/passwd
		cat >/tmp/dumdedum <<EOF
		[uuencoded version of original binary]
		EOF
		uudecode /tmp/dumdedum
		exec /tmp/dumdedum.out

	  will work quite effectively as a virus. If you can distribute
	  a .zip file containing the unmodified binary (renamed or
	  relocated say), it's even easier.

	* that all this DRM stuff is built properly in the first
	  place. Viruses don't just use social engineering to work,
	  they usually exploit bugs in various programs to get more
	  privleges or to do something harmful; if there are bugs in
	  the DRM subsystem, they'll be exploited too.

	* that the people implementing the DRM stuff aren't going to be
	  the ones distributing the viruses too; eg the first Word macro
	  virus was distributed from Microsoft, iirc

None of that is particular to Palladium.

Also from the Palladium FAQ:

] *  Curtained memory.  The ability to wall off and hide pages of main
]    memory so that each "Palladium" application can be assured that it is not
]    modified or observed by any other application or even the operating system

Maybe it's just me, but that sounds like a *great* feature for viruses
and other malware to avoid detection by the user or virus checkers,
and probably investigation too.

Actually, none of this makes much sense to me: there's nothing in that
FAQ that stops you from writing an entirely software implementation of
Palladium. Generating an RSA and an AES key are trivial, and pretending
to provide all the services Palladium claims to offer is easy too. What's
missing is some way for software to refuse to run if Palladium isn't
really there, that is, to securely authenticate the exsitance of Palladium
on the system you're using. You'd need to do it by encrypting the program
entirely, in a way that only a Palladium chip could encode and pass to
the processor, something like:

    Pd_handle = Request_Palladium_Environment();
    Pd_handle->Set_Encoded_Key(0xDEADBEEF,0xCAFEBABE,0xDECAFBAD,0xDEAFC0ED);
    Pd_handle->Load_Encoded_Program("/opt/myprogram/realcode.crypted");
    Pd_handle->Run();

where Load_Encoded_Program() does something like convert the 128 bits
from Set_Encoded_Key() into an AES key in a way that can't be duplicated,
then decrypts and loads /opt/myprogram/realcode.crypted into inaccessible
memory. Alternatively, you could avoid the Set_Encoded_Key() call if every
Palladium chip has a common public/private keypair.

But either way, there needs to be a private key common to all Palladium
systems, or they're just obfuscating things, rather than securing them.

Well, the other alternative, I guess, is that any "secured" software
is tailored to the CPU it's to be run on before it leaves the vendor;
either by being loaded at the factory, or by a special download protocol,
that first sends something based on your manufacturer-signed RSA public
key, and then lets you download a specially encrypted copy of whatever
software or keys you need. That would work, but would mean you couldn't
mirror DRM-enabled player software, nor distribute it on CD or DVD.

All the real keys you use seem to be generated by a "pseudo-identity
provider"; which let the Palladium chip ask for a key to be authenticated,
then presumably send such an authentication back in a manner that only the
Palladium chip can access. There's some comments about allowing you to
migrate secrets between Palladium devices, which seems reasonable. It'd
be interesting to see how you manage to handle backups -- ie, when you
want to migrate data without being able to simultaneously access the
two Palladium chips at any point in time. Maybe you'll only be able to
backup Palladium machines to other Palladium machines (as opposed to
dumb storage like tapes, even, maybe).

One interesting feature is:

] * Secure input and output. A secure path from the keyboard and mouse to 
]   "Palladium" applications, and a secure path from "Palladium"
]   applications to a region of the screen

which seems to imply that applications won't be calling the OS functions
to access the display. Which presumably means you don't get to use any
special drivers for your graphics cards -- if you could, you could just
write some drivers that dump straight to disk or something. Presumably
it works something like Palladium telling the graphics card to put this
bit of memory on screen and then not allowing anything else to read/write
that bit of memory (of course, if you build a "video" card that copies
that memory somewhere else instead of displaying it...). Anyway, that's fine,
but what it seems like it means, especially coupled with:

] When running, "Palladium" provides a parallel execution environment
] to the "traditional" Windows kernel- and user-mode stacks; "Palladium"
] runs alongside the OS, not underneath it.

is that "Palladium" software probably doesn't, and can't, use the OS
at all.  After all, if it did, then you could hax0r the OS libraries
to make something like strcmp() do a complete dump to disk of all the
supposedly secure memory the app had access to, then kill the program and
let you analyse what the hell was going on and recover any secret keys.
Leaking information between security zones (Palladium and ordinary in
this case) is incredibly easy in general, so the only way to avoid this
is to ensure you untrusted people -- like OS authors -- don't have any
access to the other security zone.

And if that's the case, then it means that it ought to be easy to run
Palladium software on a Palladium equipped machine running Linux, or
BSD, or whatever -- the different kernels and so forth are irrelevant,
since they're entirely bypassed by the Palladium system. Which should
mean that, say, running a Windows DRM-enabled media player on Linux/i386
would be a matter of pulling out the Palladium enabled code, and adding
a Linux wrapper to load the encrypted data, invoke the Palladium code,
and add a title bar to the window. With luck, that could be automatable.
Wouldn't work across architectures though.

Hrm. That was more stream-of-conscious than it was meant to be. Oh well.
Linux is mentioned three times, it's gotta be on topic.

Cheers,
aj

-- 
Anthony Towns <aj at humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.

    ``Australian Linux Lovefest Heads West''
                   -- linux.conf.au, Perth W.A., 22nd-25th January 2003
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 350 bytes
Desc: not available
URL: <http://lists.humbug.org.au/pipermail/general/attachments/20030114/bbe8bf01/attachment.sig>