dangers of TCPA/palladium

[Jay Sulzberger]

On Mon, 5 Aug 2002, AARG!Anonymous wrote:

< ... />

> Why not give the market a chance?  Company A provides the data with
> Draconian DRM restrictions; company B gives you more flexibility in what
> you do.  All else being equal, people will prefer company B.  So they
> can charge more.  In this way a balance will be reached depending on how
> much people really value this kind of flexibility and how much they are
> willing to pay for it.  You and I don't get to decide, the people who
> are making the decisions about what content to buy will decide.

I am much in sympathy with the "Give the market a chance." slogan.  But
TCPA/Palladium/DRM and Jack Valenti are not.  Nor are you.  Phillips could
make and sell a device, even the sort of trammeled computer that Jack
Valenti wishes to be universally imposed by law, within one year from
today.  Indeed, IBM, Sun, Apple, Dell, Sony, and any number of other
companies could have sold such a device any day they wished over the past
fifteen years.  Yet they have not.  So the market has decided, by your
standard.  The decision is clear: No DRM.

>
> And nobody's got the root key to my computer.  You make this claim in many
> places in the document.  What exactly is this "root key" in TCPA terms?
> The endorsement key?  It's private part is generated on-chip and never
> leaves the chip!

Of course, the minimal demand of the pro-DRM forces is to have root on
every machine in the world, with evasion of their root control a felony.

You support DRM lock stock and barrel, no matter your demonstrably
inaccurate claims that

1. You are all for the market.

2. Well, DRM is not so bad, see, RIAA-MPAA-AAP will give us all root on
their machines, so it is all equal!

3. Why, your computer will be exactly the same under DRM as it is today,
except better!

>
> > 5. Strong enforcement for the software renting model -- the types of
> > software licensing policy enforcement that can be built with the
> > platform will also start to strongly enable the software and object
> > rental ideas.  Again potentially these models have some merit except
> > that they will be sabotaged by API lock out, where the root key owners
> > will be able to charge monopoly rents for access to APIs.
>
> I don't follow this.  What root key owners?  What APIs?  Could you say
> more about how TCPA will help with software rental?

Today Microsoft and its script children have root on many machines, yet
there is no single root password for them.  Rather there is a system, which
includes

1. agreements with Dell, IBM, etc., to only offer for sale hardware with Microsoft OSes loaded

2. hardware that only runs right with a Microsoft OS

3. extortionate forced "license agreements" with end-users

4. hypnotic control of the mass media, which always claim that "After all,
you will have to run only Microsoft OSes forever."

5. hypnotic control of the managers who "decide" which OS to run, which
managers always claim that "After all, we have to run only Microsoft OSes
forever."

Of course, this hypnosis is mainly self-hypnosis, with only trim-tab level
direction by Microsoft, Dell, IBM, Sun, Apple, etc..

oo--JS.


>
> > 6. Audits and certification become vastly more prevalent.  Having had
> > some involvement with software certification (FIPS 140-1 / CC) I can
> > attest that this can be expensive exercises.  It is unlikely that the
> > open source community will be able to get software certified due to
> > cost (the software is free, there is no business entity to claim
> > ownership of the certification rights, and so no way to recuperate the
> > costs).  While certification where competition is able to function is
> > a good thing, providing users with a transparency and needed
> > assurance, the danger with tying audits to TCPA is that it will be
> > another barrier to entry for small businesses, and for open source
> > particularly.
>
> This is a good point, but again it depends on the specific content
> realm.  There are not just one or two - there are thousands of kinds
> of content, or even more.  Not everyone is going to require FIPS 140
> levels of certification!
>
> But possibly Disney and Sony will.  My guess is that if there ever is
> a Linux program that will play their movies, it will be because those
> companies contracted to get it written.  You may see this in many contexts
> - software applications don't get certified, rather they are supplied
> by the vendors, or the vendors arrange to get them done.
>
> > 7. Untrusted, unauditable software will be able to run without
> > scrutiny inside the hardware assisted code compartments.  Some of the
> > documentation talks about open sourcing some aspects.  While this may
> > come to pass, but that sounded like the TOR (Trusted Operating Root);
> > other extension modules also running in unauditable compartments will
> > not be so published.
>
> This part I don't understand too much; it's not a TCPA concept, and there
> is little known about Palladium.  Supposedly the idea is that this is a
> place that code can run without being touched by debuggers or viruses.
> I don't know what happens if a virus gets itself loaded into this area,
> if that is even possible.  Maybe all the different compartments are
> isolated from each other.
>
> Does this seem like a bad feature to you?
>
> > 8. Gives away root control of your machine -- providing potentially
> > universal remote control of users machines to any government agencies
> > with access to the TCPA certification master keys, or policies
> > allowing them to demand certifications on hostile code on demand.
> > Central authorities are likely to be the only, or the default
> > controllers of the firmware/software upgrade mechanism which comes as
> > part of the secure bootstrap feature.
>
> Now you're starting to go paranoid.  All the TCPA certification master
> keys do is to certify that a system is TCPA compliant.  They don't have a
> remote control over your machine!  They are more analogous to Verisign
> in the X.509 world.  Last I checked they hadn't taken over my box.
> As far as the field upgrade, it has to be authorized by the owner.
>
> I'm disappointed to see this kind of fantasizing in what has been a
> well grounded document until now.  If you're going to make this kind
> of charge, that TCPA gives a universal remote control to government,
> you need to back it up in detail.
>
>
> > 9. Provides a dangerously tempting target for government power-grabs
> > -- governments will be very interested to be able to abuse the power
> > provided by the platform, to gain access to it's keys to be able to
> > insert remote backdoors, and/or to try to mandate government policy
> > enforcement modules once such a platform is built.  Think this is
> > unrealistic?  Recall clipper?  The TCPA is a generic extensible policy
> > enforcement architecture which can be configured to robustly enforce
> > policies against the interests of the machine owner.  Clipper,
> > key-escrow the whole multi-year fight, at some point in the near
> > future if some of the more egregious TCPA/Palladium framework features
> > and configuration possibilities becomes widely deployed could be
> > implemented after the fact, as a TCPA/Palladium policy extentsion
> > which runs in the hardware assisted code compartment and is
> > authenticated up to the hardware boot by the secure bootstrapping
> > process.
>
> I don't agree with your characterization that TCPA enforces policies
> against the owner's interests.  He has to voluntarily agree to everything,
> from turning on TCPA, to booting a TCPA compliant program, to running
> an application which some third party will trust, to accepting data from
> that third party under agreed-upon conditions.  If at any step he didn't
> feel that what he was doing was in his interests, he can stop and do
> something else.
>
> When you walk into a store and pay money for food, is that store enforcing
> policies against your interests?  Only from the most shallow perspective,
> for if such policies were not widely enforced, you and I and everyone
> else would starve.  We all participate voluntarily in these institutions.
> Each payment we make is in our interests.  And the same thing is true
> if you receive some data with conditions on how it is manipulated.
>
> As far as the concern about changes, I think the smart thing to do is
> to fight the bad and promote the good.  Definitely we should oppose any
> proposal to make TCPA non-voluntary, to force people to boot a certain
> OS, to limit what they can do on their computers.  But presently none
> of those features are in TCPA.  Rather than saying TCPA is bad because
> someone could make all these hypothetical changes, it makes more sense
> to judge TCPA on its own, as a system that emphasizes user choice.
>
> Involuntary TCPA is bad, voluntary is good.  So we should not fight TCPA,
> we should fight proposals to make it involuntary.
>
> > So what I've read so far, I think people's gut reactions are right --
> > that it's an aggressive and abmitious power grab by the evil empire --
> > the 3 cartels / monopolies surrounding PC hardware, Operating systems
> > and Content Distribution.  The operating system near monoply will
> > doubtless find creative ways to use and expand the increased control
> > to control application interoperability (with the sealing function),
> > to control with hardware assistance the access to undocumented APIs
> > (no more reverse engineering, or using the APIs even if you do / could
> > reverse engineer).
>
> I think you are looking at it far too narrowly.  Yes, this will provide
> many opportunities for Microsoft to write new kinds of software.  But the
> same is true for every other software company!  Financial software, web
> services, security software, accounting - anything that involves trust
> and security can benefit from TCPA.  Look at the example I gave earlier
> for a TCPA based anonymous comm network.  Multiply that a thousand fold.
> It's stupid to just look at what one company can do with this, without
> considering what a whole world of creative people can accomplish.
>
> Yes, it can make reverse engineering much more difficult.  But I'd rather
> see people put their creative efforts into creating new products rather
> than copying and piggybacking off someone else's success.
>
> > So some of the already applications are immediately objectionable.
> > The scope for them to become more so with limited recourse or
> > technical counter-measures possible on the part of the user community
> > is huge.  Probably the worst aspect is the central control -- it
> > really effectively does give remote root control to your machine to
> > people you don't want to trust.  Also the control _will_ be abused for
> > monopolistic rent seeking and exclusionary policies to lock-out
> > competition.  Don't forget the fact that microsoft views linux as a
> > major enemy as revealed by documents uncovered some the anti-trust
> > discovery process.
>
> Again, you need to justify this remote root control notion.  I don't
> see it at all.  Go back to your four functions of TCPA/Palladium -
> they were pretty accurate.  Where was the remote root control in there?
>
> > In fact I'd say this is the biggest coming risk to personal freedom
> > since the days during the onset of the clipper chip / key escrow
> > looked like they stood some chance of becoming reality.
>
> I'd say that it is a powerful technology with an almost infinite number of
> potential applications.  Being able to trust software running on a remote
> system is something that has never been possible before on the Internet.
> We can only begin to see what will be possible with this capability.
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com