dangers of TCPA/palladium

[Mike Rosing]

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

> Adam Back writes:
>

> > 2. DSS over-again -- a big aspect of the DSS reverse-engineering was
> > to allow DVDs to be played in software on linux.  The TCPA platform
> > seems to have the primary goal of making a framework within which it
> > is possible to build extensions to implement hardware tamper resistant
> > DRM.  (The DRM implementation would run in a hardware assisted code
> > compartment as described in feature 3 above).  So now where does that
> > put open source platforms?  Will they be able to read such DRM
> > protected content?  It seems likely that in the longer term the DRM
> > platform will include video cards without access to video memory,
> > perhaps encryption of the video signal out to the monitor, and of
> > audio out to the speakers.  (There are other existing schemes to do
> > these things which dovetail into the likely TCPA DRM framework.)
> >
> > With the secure boot strap described in feature 1, the video card and
> > so on are also part of the boot strap process, so the DRM system would
> > have ready support from the platform for robustly refusing to play
> > except on certain types of hardware.  Similarly the application
> > software which plays these DRM policy protected files and talks to the
> > DRM policy module in the hardware assisted code compartment will
> > itself be an application which uses the security boot-strapping
> > features.  So it won't be possible to write an application on for
> > example linux to play these files without an audit and license etc
> > from various content, DRM and OS cartels.  This will lead to exactly
> > the kind of thing Richard Stallman talked about in his prescient paper
> > on the coming platform and right to develop competing software control
> > wars [9].
>
> I think this analysis is largely correct, except that it won't be
> as monolithic as you make it sound.  There won't be just one content
> supplier who judges all software, that's obviously impossible.  Rather,
> each different supplier will make its own determination of which software
> you can trust.  And likewise for non-DRM applications.  Banks will decide
> which banking software to trust.  Game networks will decide which game
> clients to trust, etc.
>
> > 3. Privacy support is broken -- the "privacy" features while clearly
> > attempts to defuse a re-run at the pentium serial number debacle, have
> > not really fixed it's problems.  You have to trust the "Trusted Third
> > Party" privacy CA not to track you and not to collude with other CAs
> > and software vendors.  There are known solutions to this particular
> > sub-problem, for example Stefan Brands digital credentials [10], which
> > can be used to build a cryptographically assured privacy preserving
> > PKI avoiding the linking problems arising from identity based and
> > attribute certificates.
>
> I agree that it would be nice to see more flexibility there.  The Chaum
> blinding patent expires in 2005, so maybe around then we can start seeing
> privacy CA's that use blind signatures, which solves that problem.
> The spec is obviously trying hard to protect privacy, it's just that
> the mechanisms to do it right are extremely complex compared to the
> straightforward way.
>
>
> > 4. Strong enforcement for DMCA DRM excesses -- the types of DRM system
> > which the platform enables stand a fair chance of providing high
> > levels of enforcement for things which though strictly legally
> > mandated (copyright licensing restrictions, limited number of plays of
> > CDs / DVDs other disadvantageous schemes; inflexible and usurious
> > software licensing), if enforced strictly would have deleterious
> > effects on society and freedom.  Copyright violation is widely
> > practiced to a greater or less extent by just about all individuals.
> > It is widely viewed as acceptable behavior.  These social realities
> > and personal freedoms are not taken into account or represented in the
> > lobbying schemes which lead to the media cartels obtaining legal
> > support for the erosion of users rights and expansionist power grabs
> > in DMCA, WIPO etc.
> >
> > Some of these issues might be not so bad except for the track records,
> > and obvious monopolistic tendencies and economic pressures on the
> > entities who will have the root keys to the worlds computers.  There
> > will be no effect choice or competition due to existing near
> > monopolies, or cartelisation in the hardware, operating system, and
> > content distribution conglomerates.
>
> Nobody's putting a gun to your head and making you download content.
> If you can't agree to the conditions, go do something else.  There are
> much worse things that can happen in the world than that copyright
> becomes enforceable.
>
> 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.
>
> 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!

I agree that the market can have the chance!!  Just don't make it
anything to do with the law!  If people want to buy platforms with TCPA
built in they should be allowed to, and those who don't should be
free to choose that way.  You now claim there are at least 2 keys
that don't leave the chip, but if you are going to recover anything
encrypted by those keys you had better have them off chip when the
chip dies.

> > 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?

D'oh!!  Obviously it's a bad feature - it gives my computer to some
unknown entity.  In fact, it gives the entire network of computers
to one entity - it creates a huge monster of unequal power.  I can
sure see why a government like Iraq would love to have this feature.
Or China.  Or the US.  You could run a special program that nobody
can stop or find or know about.  That's *POWER*.  It is difficult
to understate how bad that is.

> > 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.

Look, if there can be a section of code that only the manufacturer
has access to, then that section of code could have an internet download
section that sucks "evil intent" from someplace the manufacturer (or
someone who's broken into them) has designated.  It's not that we're
saying it'd be done on purpose up front, but somebody some day will
figure it out and all the tools are there to make it happen.  Sometimes
a good imagination can save you from having to be paranoid.

> > 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.

Then we agree completely!  So long as no laws are passed around TCPA,
and it is not linked to any copyright laws, or mandated in any way,
then there's no problem!  IF TCPA gives people something they want,
and they understand how it works, I don't see anything wrong with it.
I do see a problem in it being written into any laws because the
potential for abuse is huge.

> > 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.

It will also make backups really expensive.

> > 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?

The only way it works is if there can be code the user doesn't control
the loading of.  That means somebody else controls the machine.  It's
pretty basic.

> > 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.

Horsepucky.  I can run trusted software right now.  *I* wrote it, that's
why I trust it!  I don't need a dongle on the motherboard to ship trusted
software.  An external dongle works just fine.  And I can check the
signature of source code I compile to be sure the author has sent me
the correct code - I trust it will do what it's supposed to because
the encrypted hash matches the source hash.

going back to the key stuff - you've changed the names, but what it
boils down to is that *somebody* has to have a copy of the internal
keys used to encrypt data by the TPM.  If it's not the user, who is
it?  That's the person who owns the data, because they own the keys.

I'd say Adam did a nice job nailing TCPA to the wall.  Now let's see
if it dies slowly or quickly.

Patience, persistence, truth,
Dr. mike