Seth on TCPA at Defcon/Usenix

[AARG!Anonymous]

In discussing how TCPA would help enforce a document revocation list
(DRL) Joseph Ashwood contrasted the situation with and without TCPA
style hardware, below.  I just want to point out that his analysis of
the hardware vs software situation says nothing about DRL's specifically;
in fact it doesn't even mention them.

His analysis actually applies to a wide range of security features,
such as the examples given earlier: secure games, improved P2P,
distributed computing as Adam Back suggested, DRM of course, etc..
TCPA is a potentially very powerful security enhancement, so it does
make sense that it can strengthen all of these things, and DRLs as well.
But I don't see that it is fair to therefore link TCPA specifically with
DRLs, when there are any number of other security capabilities that are
also strengthened by TCPA.

Joseph Ashwood wrote:

> Actually it does, in order to make it valuable. Without a hardware assist,
> the attack works like this:
> Hack your software (which is in many ways almost trivial) to reveal it's
> private key.
> Watch the protocol.
> Decrypt protocol
> Grab decryption key
> use decryption key
> problem solved

It's not always as easy as you make it sound here.  Adam Back wrote
Saturday about the interesting history of the giFT project, which
reverse-engineered the Kazaa file-sharing protocol.  That was a terrific
effort that required considerable cryptographic know-how as well as
supreme software reverse engineering skills.  But then Kazaa changed the
protocol, and giFT never managed to become compatible with the new one.
I'm not sure whether it was lack of interest or just too difficult,
but in any case the project failed (as far as creating an open Kazaa
compatible client).

It is clear that software hacking is far from "almost trivial" and you
can't assume that every software-security feature can and will be broken.

Furthermore, even when there is a break, it won't be available to
everyone.  Ordinary people aren't clued in to the hacker community
and don't download all the latest patches and hacks to disable
security features in their software.  Likewise for business customers.
In practice, if Microsoft wanted to implement a global, facist DRL,
while some people might be able to patch around it, probably 95%+ of
ordinary users would be stuck with it.

Therefore a DRL in software would be far from useless, and if there
truly was a strong commercial need for such a solution then chances are
it would be there today.

I might mention BTW that for email there is such a product,
disappearingink.com, which works along the lines Seth suggested, I
believe.  It encrypts email with a centralized key, and when that email
needs to be deleted, the key is destroyed.  This allows corporations to
implement a "document retention policy" (which is of course a euphemism
for a document destruction policy) to help reduce their vulnerability to
lawsuits and fishing expeditions.  I don't recall anyone getting up in
arms over the disappearingink.com technology or claiming that it was a
threat, in the same way that DRLs and SNRLs are being presented in the
context of Palladium.


> With hardware assist, trusted software, and a trusted execution environment
> it (doesn't) work like this:
> Hack you software.
> DOH!!!!! the software won't run
> revert back to the stored software.
> Hack the hardware (extremely difficult).
> Virtualize the hardware at a second layer, using the grabbed private key
> Hack the software
> Watch the protocol.
> Decrypt protocol
> Grab decryption key
> use decryption key
> Once the file is released the server revokes all trust in your client,
> effectively removing all files from your computer that you have not
> decrypted yet
> problem solved? only for valuable files

First, as far as this last point, you acknowledge that if they can't
tell where it came from, your hacked hardware can be an ongoing source of
un-DRL'd documents.  But watermarking technology so far has been largely
a huge failure, so it is likely that someone clueful enough to hack his
TPM could also strip away any identifying markings.

Second, given that you do hack the hardware, you may not actually need
to do that much in terms of protocol hacking.  If you can watch the data
going to and from the TPM you can extract keys directly, and that may
be enough to let you decrypt the "sealed" data.  (The TPM does only
public key operations; the symmetric crypto is all done by the app.
I don't know if Palladium will work that way or not.)

Third, if a document is "liberated" via this kind of hack, it can
then be distributed everywhere, outside the "secure trust perimeter"
enforced by TCPA/Palladium.  We are still in a "break once read anywhere"
situation with documents, and any attempt to make one disappear is not
going to be very successful, even with TCPA in existence.

In short, while TCPA could increase the effectiveness of global DRLs,
they wouldn't be *that* much more effective.  Most users will neither
hack their software nor their hardware, so the hardware doesn't make
any difference for them.  Hackers will be able to liberate documents
completely from DRL controls, whether they use hardware or software
to do it.  The only difference is that there will be fewer hackers,
if hardware is used, because it is more difficult.  Depending on the
rate at which important documents go on DRLs, that may not make any
difference at all.


> Now about the claim that MS Word would not have this "feature." It almost
> certainly would. The reason being that business customers are of particular
> interest to MS, since they supply a large portion of the money for Word (and
> everything else). Businesses would want to be able to configure their
> network in such a way that critical business information couldn't be leaked
> to the outside world. Of course this removes the advertising path of
> conveniently leaking carefully constructed documents to the world, but for
> many companies that is a trivial loss.

I agree that providing an option to store documents in restricted form
could be a desirable feature for businesses.  And having the ability
to delete documents on a company-wide basis, a la disappearingink.com,
could make sense as well.  I don't know that there is a huge market for
this capability, or I suspect we'd see it already.  But it does make
sense as an auxiliary part of a business document product.

But to me this points to a localized DRL, part of a document-management
library that is used solely for documents within the company.  The company
would want to control the administration of its documents.  I don't
see this leading to the kind of centralized, global system which I
think opponents of TCPA are attempting to invoke when they talk about it
allowing DRLs, and which is the kind of thing I was talking about above.

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