All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Millan <rmh@aybabtu.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: TPM support with SATA drives
Date: Sat, 19 Apr 2008 13:34:01 +0200	[thread overview]
Message-ID: <20080419113401.GA22920@thorin> (raw)
In-Reply-To: <1208542846.6642.30.camel@dukephillips.omgwallhack.org>

On Fri, Apr 18, 2008 at 11:20:46AM -0700, Julian Blake Kongslie wrote:
> 
> Sorry, but this message is confusing me. Having the TPM in my machine
> act as a cryptographic proxy on my behalf is the entire point of the
> TPM:

It's part of the point, but there's more to it.  You can see evidence of that
in two facts:

  - The TPM has a master key that the owner never gets a copy of.  Not even
    if she requests it to the vendor.
  - The TPM refuses to sign things with its master key when it doesn't feel
    like it.  So if you want to use the TPM to emmit a certificate that
    proves you're running Microsoft Windows, but you're not, the TPM will
    refuse to help you.

> if the software stack has access to the SRK then attackers would
> prefer to attack dead swap space or temp files rather than the TPM
> itself.

Of course.  But we're talking about the *owner* having control.  The software
stack is not the only way the owner can control her own hardware.  For example,
she could get a printed copy of the master key.  Or there could be a
jumper/button in the TPM that overrides the restrictions I explained above
(So-called "owner override", which was proposed and rejected because "it was
against the purpose of providing TPMs" -- draw conclussions from what that
means).

> > The idea behind this is that you can be coerced into accepting that someone
> > else can spy on your computer (they call it "remote attestation").  When
> > enough users accept this form of blackmail, it will become impossible to
> > resist to it in practice.
> 
> And this is the really confusing part. How can someone else spy on my
> computer because of my TPM? I can *voluntarily* enter into a remote
> attestation system, but to do that I would need to tell my peers the
> public key I will be using to sign the attestations; if I was so
> inclined, I could choose any key that I like for this purpose, and
> instruct the software on my machine to get the unencrypted PCRs from my
> TPM, modify their values as I saw fit, and sign that configuration
> instead.
> 
> Even if the software that runs the remote attestation is honest (say,
> because I'm running some Windows-based scheme that I can't easily
> change), I can still elect to boot into Linux, authenticate to the TPM
> with the owner password, and ask it to perform whatever operations I
> want with whatever PCR configuration I want.

You think remote attestation is voluntary, but by its nature it cannot be
made voluntary.  Voluntary means I can refuse to participate without giving
the challenger any information about my system.  However, my refusal to
participate *IS* already information.  In fact, if you add to it another
piece of information -- namely, the (future) fact that everyone has a
complete Treacherous stack --, what do you get?  Right!  You get the ability
to distinguish who is running your CrapWare 2000[tm] DRM program and who
isn't.

Which means that in the future (unless computer users reject it outright),
DRM proponents will have a very powerful tool in order to coerce everyone
into using the anti-features they put in their programs (which obviously
nobody *wants* to have, that's why they have to make it so confusing).

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)



  parent reply	other threads:[~2008-04-19 11:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-18  9:06 TPM support with SATA drives Laurent Dufréchou
2008-04-18 11:22 ` Robert Millan
2008-04-18 18:20   ` Julian Blake Kongslie
2008-04-18 18:33     ` Laurent Dufréchou
2008-04-19 11:41       ` Robert Millan
2008-04-19 11:34     ` Robert Millan [this message]
2008-04-27  2:58       ` Chris Knadle
2008-05-06 14:33         ` Robert Millan
2008-04-18 11:27 ` Robert Millan
2008-04-18 12:07   ` Laurent Dufréchou
2008-04-18 12:23     ` Robert Millan
2008-04-18 12:08   ` Laurent Dufrechou
2008-04-18 12:08   ` Laurent Dufrechou
2008-04-18 12:33     ` Robert Millan
     [not found] <1208675222.25233.32.camel@dukephillips.omgwallhack.org>
2008-04-20  9:58 ` Robert Millan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080419113401.GA22920@thorin \
    --to=rmh@aybabtu.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.