Seth David Schoen <[EMAIL PROTECTED]> writes:

>You could conceivably have a PC where the developers don't trust Linus, but
>instead trust the PC manufacturer.  The PC manufacturer could have made it
>extremely expensive for Linus to tamper with the PC in order to "violate [the
>developers'] security model".  (It isn't logically impossible, it's just
>extremely expensive.  Perhaps it costs millions of dollars, or something.)

Do you trust the PC manufacturer though?  Let's assume:

  - The security target is DRM.
  - The users of the security are content providers.
  - The threat model/attackers are consumers.

In other words the content providers have to trust the PC manufacturer to
provide security to restrict what the consumer can do.  The PC manufacturer's
motivation though is to enhance their own revenue stream by selling as much
hardware as they can, not to enhance the content provider's revenue stream by
making it as crippled as they can.  If you look at the DVD market, every DVD
player made outside the US has some form of vulcan nerve pinch that you can
apply that'll remove the enforcement of region coding.  Depending on your
country's view of differential pricing enforcement mechanisms, this may be
enabled by default (I don't know if you can buy a DVD player in NZ that
enforces region coding, if I was more of an enterpreneur I could start a good
business exporting universal-region, universal-format players to the US :-),
or at least will be a widely-known secret that everyone applies ten minutes
after they first plug the device in.  Given that the goals of the hardware
vendor and the user (= content provider) are mutually exclusive, I wouldn't
trust the hardware vendor.  Conversely, as a consumer, I would trust the
hardware vendor to provide backdoors to bypass the DRM in order to sell more
units after the first year or two, when it's become a commodity and they need
some other way of competing for sales than the novelty value.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to