[e-lang] Palladium

[Lucky Green]

Mark Miller wrote:
> Btw, even after reading Ross Anderson's
> http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html , I'm not sure I 
> understand 
> what the TCPA is.  
> At 
> http://www.agorics.com/Library/agoricpapers/aos/aos.6.html#sec
> tion6.1.2 
> Eric Drexler and I explain a concept we called an "Opaque 
> Box", which would 
> seem to be similar.  (And which I thought was a good idea at 
> the time.) 
> However, the opaque box contained all the ram within the box, and 
> encrypted/decrypted on paging in/out to disk.  Plaintext only 
> existed within 
> the box.  It seems the TCPA does less, but I don't see how 
> that leaves them 
> with any enforceable properties.

Spoken like a true scientist. :) You are correct. TCPA's current phase
does not leave any enforceable properties in the theoretical sense. As
long as the op codes remain available in the clear on the bus, you can
microprobe them off the bus. See my post to Cypherpunks on this topic
about a week ago.

To do better than that, one would need a secure execution environment
that maintains encrypted instructions or provides significant tamper
resistance all the way to the CPU, similar to nCipher's SEE or Wave
Systems EMBASSY.

Such a system was very much in the works for x86 CPU's, but the effort
was cut short at the time due to the uproar over processor ID. The
replacement phase required a non-CPU vendor driven, at least on paper,
approach with broad industry support.

The solution was the CPU vendor-neutral TPM. For a TPM to approach the
security properties of an SEE, the TPM would have to be in a similar
price range as an SEE. Since the motherboard manufacturers did not
foresee selling a great number of additional motherboards just because
the board features a TPM, charging an additional $500+ per board for
this feature was out of the question. The ideal cost of a TPM from the
motherboard manufacturers' perspective is zero dollars, though perhaps
$1 per part might be acceptable.

For that one dollar or so, the bar to breaking systems will be raised
considerably. There are certainly a good number of folks with the
knowledge and ability to break a TPM protected system. I know if I were
to take a stab at it, I would have to call in some favors to gain access
to the required equipment. A break of a TPM by even the most motivated
16-year old Norwegian hacker is unrealistic.

In fact, I cannot think of a single person that I am aware of that has
both the ability to break a TCPA system and would be willing to face the
resultant criminal charges. Myself very much included.

Can TCPA be broken? Sure. Will it be broken with the break being
distributed publicly? I wouldn't bet on it. (See my post to Cypherpunks
as to why for-profit criminal actors are anticipated and non-threatening
to TCPA. In brief, such criminal actors are just another competitor.
Most business models can survive another competitor. It is when the
marginal cost of an illegal copy drops to zero and it is faster for a
person to download an illegal copy of Office XP than to locate the
person in IT that knows where in the building to potentially find the
licensed CD, that business models threaten to collapse).

One issue that was raised on this list is that of encapsulation (little
surprise for E-lang :) and how TCPA-protected data relates to other
means of protection, such as storing the data on a web server.

I believe the two to be quite analogous. In my mind, Palladium (or
DRMOS, as it was called initially) has been the offline variant of .NET
with additional local protections against electronic access to cleartext
of bits (be that files or applications).

Let's look at some properties of .NET and Palladium:

Property							.NET
Palladium

- Prevent use of the application w/o pay		YES	YES

- Enforces time-limited software
licensing terms.
(Known as "recurring revenue steam")		YES	YES

- Plug the "analog hole"				NO	YES

- OS vendor can enforce licensing
fees from application vendor				Maybe	YES

- Centralized document invalidation			NO	YES

- Distributed document invalidation			YES	YES

- Requires online access				YES
Occasionally

--Lucky