[cap-talk] Palladium, er, NGSCB

Ka-Ping Yee cap-talk@mail.eros-os.org
Sat, 1 Mar 2003 01:12:30 -0600 (CST)


There is a DRM conference taking place in Berkeley.  I attended
the tutorial session yesterday, at which Brian LaMacchia explained
Palladium (now known as NGSCB) in some detail.

Here is some of the information that was new for me.

The following four-quadrant picture much improved my understanding:

                                |
                                |
                       apps     |     NCAs
                                |
        user                    |
     ---------------------------+----------------
       kernel                   |
                                |
                        OS      |     nexus
                                |
                                |
                                |
                       standard | trusted


The "standard" things on the left are untrusted.  The things
on the right are components that can be attested to.  Whenever
sensitive data travels from right to left, it gets encrypted.

According to Brian:

  - You can turn Palladium (i.e. the right side) on and off
    while the rest of the system is running, without a reboot.

  - You can start up and run the system without the right side.

  - You can switch nexuses (bring down and swap in a new right
    side) without a reboot, but the context switch is fairly slow.

  - Anybody can write a nexus.

  - The user can choose to run any nexus.

  - Anybody can write an NCA.

  - Brian acknowledged that there was a significant challenge
    in separating out the trusted parts of an application
    program, into as small an NCA as possible; and that one
    needs to be careful to resist the temptation to pull the
    entire app over to the right side.

  - Brian acknowledged that it is possible to write apps that
    will run only on a particular nexus, by requiring an
    attestation in order to run.  But he didn't believe there
    were plans for Microsoft apps to lock in use of the
    Microsoft nexus in this way.

  - Brian thinks capabilities are generally a good thing.

  - Brian understands the file-browser example of good security UI.

  - Brian disagrees with the First Immutable Law and
    understands that you have to be able to run untrusted code
    with restricted abilities.

I got the impression that Brian is very intelligent and
clear-headed, knows what he is doing, and that what he is
doing will probably work as advertised.  (That is: no
protection against viruses or Trojans; but if the hardware
chip can protect its keys, it will be possible to enforce
many kinds of DRM.)

                        *       *       *

Today at a panel on information flow and fair use, i asked:

For their Trustworthy Computing initiative, Microsoft had the
choice to make a system that would protect their users from
dangers such as viruses and Trojan horses, or a system that
would protect the media companies against (from) the users.
Palladium protects the media companies and does nothing for
viruses.  Why would Microsoft choose to work for the media
companies and against their own users?

The response, from Ed Felten on the panel, was that my question
was an invalid oversimplification: Palladium doesn't work only
for the media companies, because users can also use it to
protect their own information (e.g. to prevent companies from
sharing their personal information).  John Manferdelli (manager
of trustworthy computing at Microsoft) was in the audience, and
he agreed.

I feel that it's unrealistic to expect users to benefit from
Palladium in this way.  I had a long discussion/argument with
John Manferdelli after the panel, in which i tried to explain
to him that Palladium would shift the balance of power heavily
toward the media companies and away from the users.

My argument is that the media companies can easily use Palladium
to force users to install software they want; but users have
little or no power to force big companies to install software
they want.  Compare two parallel scenarios:

    In order for a music distributor to give me music while
    preventing me from copying it:

        - The distributor must select a set of music players
          that are assured to enforce copying restrictions.

        - The distributor must request from my computer an
          attestation that I am running an approved player.

        - I must install and run an approved player.

    In order for me to give my credit card number to an online
    store while preventing the store from distributing it:

        - I must select a set of database systems that are
          assured to enforce copying restrictions.

        - I must request from the online store an attestation
          that it is running an approved database system.

        - The online store must install and use an approved
          database system.

It is clear to me that the music distributor is very likely
to achieve the first three goals, whereas an individual user
is extremely unlikely to achieve the last three.

Or in short, as Bob Blakley put it, Palladium is a force
multiplier.  It thus further exaggerates the power difference
between the large company and the little user: it gives the
large company tremendously more control over the little user,
whereas the additional control that the user gets makes almost
no difference.

John Manferdelli disagreed with me; he felt that Palladium
did not shift any power balances at all, and stated that my
arguments were simply wrong.

I also attempted to explain to John that Palladium gives
Microsoft stronger control over the software industry,
because it gets to set default acceptance policies, which
may include choosing the set of software components whose
attestations will be accepted.  John explained that the
Palladium platform included no default policies and that
he wanted to stay as far away from choosing policies as
possible.  I considered this effectively the same as handing
over an unloaded gun (ready to be loaded and fired at other
software companies, the moment Microsoft chooses to adjust
the default policies).


-- ?!ng