It's a question of trust.
The trust of the content owner in this case.
If the content owner is to trust the h/w (which has been
called a varient of a media player elsewhere on this
list) then it will require a signature from a trusted
third party.
As has been noted before in the smart card case, trusted
third parties need to know that the private key, for
which they issue a cert, is well protected. I believe
we all agree that the best place to protect a private
key is h/w.
If you want a cert from a 3rd party with that level of
asertion, then YOU need to prove that YOU have provide
that level of protection. Both smart cards (see FINREAD
specs.) and similar h/w can provide this level of
protection. (Pls note that I did not claim that all do,
only that they can do it if they chose.)
hth ..tom
> I have one gap in the picture:
>
> In a previous message in this Peter Biddle said:
>
> > In Palladium, SW can actually know that it is running on a given
> > platform and not being lied to by software. [...] (Pd can always be
> > lied to by HW - we move the problem to HW, but we can't make it go
> > away completely).
>
> But what feature of Palladium stops someone taking a Palladium enabled
> application and running it in a virtualized environment. ie They
> write software to emulate the SCP, sealing and attestation APIs.
>
> Any API calls in the code to verify non-virtualization can be broken
> by putting a different endoresment root CA public key in the
> virtualized SCP.
>
> The Palladium application (without the remote attestation feature) has
> no way to determine that it is not virtualized. If the Palladium
> application contains the endoresement root CA key that can be changed.
> If the application relies on the SCP to contain the endoresmenet key
> but doesn't verify it that can be virtualized with a replacement fake
> endoresment root CA public key using the existing SCP APIs.
>
> Then Palladiumized application could be debugged and it's features
> used without the Palladium non-virtualization guarantee.
>
> Am I free to do this as the owner of palladium compatible hardware
> running a version of windows with the proposed palladium feature set?
>
> If so how does this reconcile with your earlier statement that:
>
> > In Palladium, SW can actually know that it is running on a given
> > platform and not being lied to by software
>
>
> Then we also have the remote attestation feature which can't be so
> fooled, but for local attestation does the above break work, or is
> there some other function preventing that?
>
> Does that imply that the BORA protections only apply to:
>
> - applications which call home to use remote attestation before
> functioning
>
> - and even here the remote attestation has to be enforced to data
> separation levels -- ie it has to be that the server provides a
> required and central part of the application -- like providing the
> content, or keys to the content -- otherwise the remote
> attestation call can also be nopped out with no ill-effect (much
> as calls to dongles with no other effect than to check for
> existance of a dongle could be nopped)
>
> - applications which are encrypted to a machine key which is buried in
> the SCP and endorsed by the hardware manufacturer
>
> - however you said in your previous mail that this is not planned
>
> * now about my attempts to provide a concise, representative and
> readily understandable summary of what the essence of palladium is:
>
> my previous attempt which you point out some flaws in:
>
> > Adam Back wrote:
> > > Effectively I think the best succinct description of the platforms
> > > motivation and function is that:
> > >
> > > "TCPA/Palladium is an extensible, general purpose programmable dongle
> > > soldered to your mother board with centralised points belonging to
> > > Microsoft/IBM/Intel/".
> >
> > The Pd SCP isn't extensible or programable.
>
> OK that is true. I presume you focussed on SCP because you took the
> dongle to mean literally the SCP component alone.
>
> Let's me try to construct an improved succint Palladium motivation and
> function description. We need to make clear the distinction that the
> programmability comes from the hardware/firmware/software ensble
> provided by:
>
> hardware: the SCP, new ring0 and code compartmentatlization
>
> (btw what are the Palladium terms for the new ring0 that the TOR runs
> in, and what is the palladium term for the code compartment that
> Trusted Agents run in -- I'd like to use consistent terminology)
>
> super-kernel: TOR operating in new ring0
>
> software: palladium enabled applications using the features such as
> software attestation, and sealing with control rooted in hardware and
> the TOR
>
>
> So would it be fair to characterize the negative aspects of Palladium
> as follows:
>
> "Palladium provides an extensible, general purpose programmable
> dongle-like functionality implemented by an ensemble of hardware and
> software which provides functionality which can, and likely will be
> used to expand centralised control points by OS vendors, Content
> Distrbuters and Governments."
>
> So I think that statement though obviously less possitively spun than
> Microsoft would like perhaps addresses your technical objections with
> the previous characterization.
>
> btw I readily concede of course that Palladium platform offers the
> security compartmentalization and software assurance aspects anonymous
> and Peter Biddle have described; I am just mostly examining the
> flip-side of the new boundary of applications buildable to data
> separation standards of security with this platform. One could
> perhaps construct a more balanced characterization covering both
> positive features and negative risks, but I'll let Palladium
> proponents work on the former.
>
> So to discuss your objections to the previous version of my attempted
> Palladium characterization:
>
> - as you say the hardware platform does not itself provide control
> points (I agree)
>
> - as you say, the TOR being publicly auditable does not itself provide
> control points
>
> however the platform can, and surely you can admit the risk, and even
> the likelihood that it will in fact be used to continue and further
> the existing business strategies of software companies, the content
> industry and governments.
>
> The dongle soldered to your motherboard can conspire with the CPU and
> memory management unit to lock the user out of selected processes
> running on their own machine.
>
> If you focus on the subset of buildable applications which operate in
> the users interests you can call this a good thing. If you look at
> the risks of buildable applications which can be used to act against
> the users interests it can equally be a very dangerous thing. Also if
> you look at historic business practices, legal trends, and the wishes
> of the RIAA/MPAA there are risks that these bad practices and trends
> will be futher accelerated, exarcerbated and more strongly enforced.
>
> I'd be interested to see you face and comment on these negative
> aspects rather than keep your comments solely on beneficial user
> functions, claim neutrality of low level features, and disclaim
> negative aspects by claiming at a low level user choice. The low
> level user choice may in the long run prove impractical or almost
> impossible for novice users, or even advanced users without hardware
> hacking tools, to technically exercise. (I elaborated on the
> possiblities for robust format compatibility prevention, and related
> possibilities a previous mail.)
>
> > I wouldn't say that it is "general purpose" either, but I am not
> > sure what you mean by this.
>
> I mean it is programmable in the sense that software attestation,
> certification and the endoresed new privileged ring0 code, together
> with the hardware enforced code compartments allow the protections of
> the firmware and hardware running in the SCP to be extended up to
> complete applications -- the Trusted Agents running in code
> compartments.
>
> That makes it general purpse because it is programmable. It could be
> used to build many classes of application across a spectrum of good,
> debatable and evil:
>
> - more flexibile and secure anonymity systems (clear user
> self-interest as anonymous suggested)
>
> - DRM (mixed positive and negative, debatable depends on your point of
> view)
>
> - and for example key-escrow of SCP support crypto functions
> implemented in the TOR accessed with say CAPI (very negative)
>
> > > >From my current understanding, the worst problem is the centralised
> > > control of this platform. If it were completely open, and possible to
> > > fix it's potential dangers, it would bring about a new framework of
> > > secured computing and could be a net positive. In it's current form
> > > with centralised control and other problems it could be a big net
> > > negative.
> >
> > There isn't centralized control in Pd. Users are in control. It is
> > up to whomever cares about the trust on a given system to decide if
> > they trust it, and this obviously must start with the user.
>
> You're focussing on the low level platform specifics, not on the
> bigger implications of the overall hardware, TOR, OS and software
> ensemble which I was talking about. Yes you can run different TORS.
> But using a specific (and audited published) TOR which the user may
> find himself choosing to run in order to run Palladium-enabled
> applications, all the applications, file formats, services and content
> which are tied to doing that -- control points could and likely will
> be built.
>
> It is my opinion that the directions and business pressures are such
> that meaningful distributed control is unlikely to be the long term
> result of the things that will be built using the Palladium
> hardware/software ensemble.
>
> This seems a fairly clearly consistent and predictable outcome, unless
> the software, IP law, RIAA/DMCA and legal systems all make an
> _astounding_ complete U-turn in policy and tacitcs coincident with the
> deployment of Palladium.
>
> Can you defend the arguement that Palladium and TCPA don't change the
> balance of control against the user and against personal control in
> our current balance between technical feasibility of building software
> systems enforcing third party control and law?
>
> (btw I'll stop nagging about documentation now, previous mail crossed
> with your reply on the topic).
>
> Adam
> --
> "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
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com
