dangers of TCPA/palladium

Adam Back adam at cypherspace.org
Wed Aug 7 02:20:16 EDT 2002


Thanks for the clarifications of the differences between TCPA and
Palladium.  The lack of Palladium docs and fact that TCPA docs
describe OS level features led to the inference that Palladium unless
otherwise stated did what TCPA proposed.

Peter Biddle writes:
> Adam Back wrote:
> > I think some of the current disagreements and not very strongly
> > technology grounded responses to anonymous are due to the lack of any
> > concise and informative papers describing TCPA and palladium.
> 
> I agree, and from my perspective this is a problem. We have a great deal of
> information we need to get out there.


* Documentation

I'm feeling frustrated in being unable to properly analyse Palladium
due to lack of documentation.  Surely microsoft must have _some_
internal documentation that could be released.  Two second hand blog
articles by third parties doesn't quite cut it!

The documents claim privacy advocacy group consultation?  Could the
information shared with these groups be published?

It's quite difficult to reason about implications and limits of a
novel new architecture with incomplete information -- you need
grounded facts down to the technical details to work out what the
implications are from first principles and compare and evaluate the
proponents claims.


* privacy CA

> The suggestions for TCPA responses that William Arbaugh raises seem
> quite good (c). 1 and 2 are already true for Pd, I believe that 3 is
> true but I would need to talk with him about what he means here to
> confirm it, 4 is covered in Eric Norlin's blog (d), and 5 is
> something we should do.

Insufficient data to comment on the degree of openness provided by
palladium for 1 (allow owner to load trusted root cert), and 2 (allow
TPM to be completely disabled).

For 3, the TCPA version of the "privacy CA" is broken (implemented
using "trust me" by a server the user does not and should not have to
trust).  Does Palladium do something different?

later in same message you said:

> The privacy model in Pd is different from TCPA. I could go on for a
> long time about it, but the key difference is that the public key is
> only revealed to named third parties which a user trusts. You are
> right in thinking that you need to trust them, but you don't have to
> show anyone your key if you don't trust them, so you (the user) are
> always in control of this.

It sounds as if Palladium suffers from the same broken privacy problem
as TCPA then.  Saying you have a choice about whether to use a service
doesn't alter the fact that you are linkable and identifiable to some
extent -- the extent depending on the exact permutation of attribute,
identity and endoresment certificates you have used.

This vulnerability is unnecessary.  You can certifying things without
having to trust anyone.


* architecture functionality

>From the limited information available my understanding is that the
main features of Palladium together with a hardware collection called
the SCP (= ?) can do the following things:

1. no secure-bootstrapping -- unlike TCPA this is not implemented 

2. software-attestation -- Palladium uses SCP able to hash perhaps
   the TOR, Trusted Agents, and application software, and then uses
   TCPA-like endorsed hardware keys in the SCP to remotely attest to
   these hashes.  

3. hardware assisted compartmentalization -- CPU can run another layer
   of privileged software with ability to prevent supervisor mode
   (and user mode) reading chosen user mode process memory areas.  The
   ubermode code is called the TOR.  The supervisor mode can install
   any TOR into the ubermode, but the TOR can be remotely attested(?)
   
4. sealing -- TCPA-style sealing

on 2, softeware-attestation from information so far, it's unclear what
is hashed and what is attested.

on 3, hardware assisted compartmentalization

- Presumably Palladium enabled applications would refuse to run
  unless a Palladium/Microsoft certified TOR is running?

  - Limits the meaningfulness of claims of openness in loading your
    own TOR.  More "you can turn x off but nothing will work if you
    do".

   - or perhaps it is up to the individual Palladium application
     which TOR it trusts?

     - but wouldn't this lead to a break:

       - If a microsoft written Palladium enabled application would
         talk to any TOR, user can load a TOR which is under user
         control to by-pass the compartmentalized memory
         restrictions, regaining root.  But if he can do this, he
         can break Palladium enforced DRM.

also about hardware assisted compartmentalization, earlier I said:

> > Optionally the software source can be published but that is not
> > necessary, and if it's not you won't be able to reverse-engineer it
> > as it can be encrypted for the CPU

you responded:

> Confusion. The memory isn't encrypted, nor are the apps nor the TOR
> when they are on the hard drive. Encrypting the apps wouldn't make
> them more secure, so they aren't encrypted.

If I understand the architecture makes it possible to write a TOR
which supports encrypted applications encrypted for the machines key
which is stored in the SCP.

I thought this scheme would be in the current design because as far as
I can see this would in fact be necessary for strong copy protection
for software (software licensed only for a given machine), which I
presumed microsoft has an interest in.

It would be a bit like a "sealed" application.


* on claim "palladium doesn't prevent anything":

> I believe that there isn't a single thing you can do with your PC
> today which is prevented on a Palladium PC. I am open to being
> challenged on this, so please let me know what you think you won't
> be able to do on a Pd PC that you can do today.

Well as you can still run the same software that is a tautology.

The correct question is: can Palladium enabled software prevent you
from doing things you could do with non-Palladium enabled software.
Palladium is in fact designed explicitly to prevent the user doing
things!

The are whole classes of things Palladium enabled software using
Trusted Agents, a default TOR and SCP features can prevent the user
from doing:

- it prevents the owner modifying application code running on his
  machine which uses the remote-attestation functions to talk to
  remote servers

- it could be used to robustly prevent the user auditing what
  information flowing into and out of his machine (the user can't
  obtain the keys negotiated by the SCP and a remote site, and can't
  grab the keys from the application because it's a trusted agent
  running in a TOR mediated code compartment.)

- it could be used to make file formats which are impossible for third
  parties to be compatible with (Ross Anderson came up with this
  example in [4])

- it could be used to securely hide undocumented APIs

- it could be used to securely implement software copy-protection
  using encrypt for endorsed SCP stored machine keys

- it could be used to prevent reverse-engineering applications

- it could be used for DRM to enforce play-once, to revoke fair use
  rights or any other arbitrary policies (on formats only available to
  Palladium enabled applications)

- it could be used to implement key-escrow of SCP stored keys to put
  government or corporate backdoors in sealed data, and comms with
  remote servers encrypted using SCP negotiated keys; wasn't there a
  statement somewhere that CAPI uses would more immediately get
  benefit from Palladium SCP functions?  Not sure how the mix of
  non-palladium using CAPI applications and palladium enabled SCP
  and/or CAP using applications work out for the key-escrow
  implementing TOR scenario.

now as I mentioned in an earlier post you could claim, oh that's ok
because the user has choice, he can still boot with his own custom
TOR.  In the short term that argument would work.  In the long term we
run the risk that:

a) many users will be so baffled by technology they won't know when
they are at risk and when they are not.

b) new non-backwards compatible file formats and feature creep
together with potential "palladium only format" enforcement could
start to make it very inconvenient to use non-standard TORs or non
palladium applications.

On top of that there are next gen issues, and on-going legal issues.

For example what happens when this scenario plays out:

1. recent release digital content is published early (same time as
cinema for the right price say).

2. hardware hackers do a break-once run anywhere by ripping all the
content on their hacked machine and start distributing it on kazaa
(2.5 Peta-bytes of ripped content and growing weekly)

3. RIAA/MPAA goes back and lobbys for further controls, DMCA
extensions

4. new legal, DMCA and RIAA/MPAA, and competition from Sony pressures
are placed on microsoft

difficult to see that far out what is going to happen, but blase
presumptions that it's unrealistic to expect key-escrow, or certified
TOR only and to assume that Lucky Green's Document Revocation Lists
don't get rolled out with DMCA style laws against interfering with --
that ignores a lot of history.


Also mentioned in previous post: just because it's law doesn't mean it
should be enforced.  People are currently afforded the ability to
ignore the masses of extreme and ridiculous IP law as individuals.
When a large chunk of it gets implemented into DRM, and narcware the
once free-wheeling internet information exchanges will become
marginalized, or underground only affairs -- the world will become
stifled by their own computers acting as the policeman inside -- your
own computer deputized by the US government, DMCA et al.


> > 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 know that we aren't using undocumented API's 

I think you must have misinterpreted what I said: I wasn't talking
about Palladium APIs.

I was talking about the fact that microsoft has historically used
undocumented APIs as a business tactic, and I presume this is still an
ongoing strategy, and the Palladium hardware architecture could be
used to build a TOR which forced competitors attempting to discover
undocumented APIs in order to fairly compete to resort to hardware
hacking.  Unless and until we get the software copyright analog of
DMCA reverse-engineering restrictions which makes that illegal.

> and that we will strive for the highest degree of interoperability
> and user control possible. Pd represents massive de-centralization
> of trust, not the centralization of it.

I'm not sure what you mean by "de-centralized trust".  Perhaps that
the TOR is publicly audited?  Perhaps that there are multiple vendors
endorsing SCP implementations?


I think Palladium clearly has possibilities to magnify centralized
control.


It is in microsoft's economic interests, and historically their
modus-operandi to aggresively try to create and exploit control points
to extract monopolistic rents, and/or suppress competition.  And of
course other companies also have used the same strategies, but the
current limits placed on such practices by the ability to reverse
engineer for compatibility may come to be eroded by TCPA/Palladium.

> I think that time is going to have to tell on this one. I know that this
> isn't true. You think that it is. I doubt that my saying it isn't true is
> going to change your mind; I know that the technology won't do much of what
> you are saying it does do, but I also know that some of these things boil
> down to suspicion around intent, and only time will show if my intent is
> aligned with my stated goals.

It's nothing personal, it's just that intent is open to evolutionary
change, legislative attack, pressures outside of your personal, or
microsoft's control -- economic and legal incentives will arise which
make the platform deviate from current stated intent.  2002 stated
intent is zip guarantee.

Someone sent me this hugely appropriate quote in email relating to
this point:

| "You do not examine legislation in the light of the benefits it will
| convey if properly administered, but in the light of the wrongs it
| would do and the harms it would cause if improperly administered." -
| Lyndon Johnson

except here we are not talking about legislation directly but a
hardware platform with the tools to create different control points
and the legal and business pressures that act upon the use and misuse
of that platform and those created control points.

> I think that Pd represents an enhancement to personal freedoms and
> user control over their machines. I hope that over time I will be
> able to explain Pd sufficiently well so that you have all the facts
> you need to understand how and why I say this.

I can only think that your definitions of user control probably are in
terms of abstract "security" rather than a distrusting viewpoint that
wants to be able to audit and modify application behavior.  

I presume you mean "freedom" in the sense of freedom from the ills
that it is claimed Palladium enabled applications could improve.

I think of freedom as the ability for self-determination, to
completely control and audit all aspects of software running on my
system.  Without these freedoms applications and vendors can conspire
against the machine owner.  I suspect the majority of people feel
similarly.

With current information it seems that the Palladium platform is
damaging to freedom and indivdual liberty, and a future risk to free
society.  I am of course completely open to being proven wrong, and
look forward to seeing more detailed Palladium specs so that this can
be tested, and to see the community given the opportunity to point out
potential more open and less control point prone modifications.

Adam

[4] "Security in Open versus Closed Systems (The Dance of Boltzmann,
Coase and Moore)", Ross Anderson,

(Sections 4 and 5 only, rest is unrelated) 

http://www.cl.cam.ac.uk/ftp/users/rja14/toulouse.pdf

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



More information about the cryptography mailing list