TPM support with SATA drives

TPM support with SATA drives

[Laurent Dufréchou]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Hello,

I’m trying to use a TPM chip on a motherboard. I’ve seen trusted-grub
project but the problem is that it can’t work because my motherboard
supports only SATA drive.

=== 2.6 Known Bugs ===

* SATA and Floppy support is currently not included due to the limitation of
stage1.

 

Now, I’ve just discovered Grub2.

I’m wondering if there is some patch to add support for TPM chip and
measurement of files on system, thus on sata drive.

If you’ve got any other idea to help me on using measurement with sata on
grub, I will be really happy too.

 

Regards,

 

Laurent Dufréchou

 


[-- Attachment #2: Type: text/html, Size: 3510 bytes --]

Re: TPM support with SATA drives

[Robert Millan]

On Fri, Apr 18, 2008 at 11:06:19AM +0200, Laurent Dufréchou wrote:
> Hello,
> 
> I’m trying to use a TPM chip on a motherboard. I’ve seen trusted-grub
> project but the problem is that it can’t work because my motherboard
> supports only SATA drive.
> 
> === 2.6 Known Bugs ===
> 
> * SATA and Floppy support is currently not included due to the limitation of
> stage1.
> 
>  
> 
> Now, I’ve just discovered Grub2.
> 
> I’m wondering if there is some patch to add support for TPM chip and
> measurement of files on system, thus on sata drive.
> 
> If you’ve got any other idea to help me on using measurement with sata on
> grub, I will be really happy too.

Hi Laurent,

The problem with these TPM chips is that they have the hidden purpose of
restricting you as user.  Despite that you paid for the hardware and are its
owner, the chip will never give you its master key.

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.

For these reasons, I'd like to encourage you to consider the ethical
implications of using and supporting this technology, and look for
alternatives that would satisfy whatever needs you had in it (I'd welcome
some discussion about that, to see how GRUB can help).

-- 
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 /.)

Re: TPM support with SATA drives

[Robert Millan]

On Fri, Apr 18, 2008 at 11:06:19AM +0200, Laurent Dufréchou wrote:
> 
> Now, I’ve just discovered Grub2.
> 
> I’m wondering if there is some patch to add support for TPM chip and
> measurement of files on system, thus on sata drive.

Just in case my last message was a bit too confusing, measurement is something
that I think would be nice to have.  It just happens that we don't need a TPM
at all to implement it (TPM is not about measuring but _being_ measured, and
by an hostile party).

-- 
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 /.)

Re: TPM support with SATA drives

[Laurent Dufréchou]

[-- Attachment #1: Type: text/plain, Size: 1681 bytes --]

Yeah I see what you mean., and I agree a lot. I got a TPM chip in my
computer that I could use to encrypt my hard dsk but I will never use it as
I don't have access to all the thing.
In fact what i'm askig is for a special use case.
My use case is that I provide an embedded computer running linux operating
system, and I want to be sure that the all system that I can't remotly
manage isn't corrupted to its task.
In this case I'm in the case of the "Hostile party Bad Guy wanting to
measure you" ;).
I think TPM chip can only be used for that. Not for like they claim to give
to classical user a trusted computer.
I want to use it to trust MY computer used by another guy (that can be an
attacker). (industry market, not consumer one)
I think in this use case it is ehicaly correct as I try to measure and
ensure my system is not corrupted. (Must be the only case where TPM chip are
good at :) )

Laurent

2008/4/18, Robert Millan <rmh@aybabtu.com>:
>
> On Fri, Apr 18, 2008 at 11:06:19AM +0200, Laurent Dufréchou wrote:
> >
>
> > Now, I've just discovered Grub2.
> >
> > I'm wondering if there is some patch to add support for TPM chip and
> > measurement of files on system, thus on sata drive.
>
>
> Just in case my last message was a bit too confusing, measurement is
> something
> that I think would be nice to have.  It just happens that we don't need a
> TPM
> at all to implement it (TPM is not about measuring but _being_ measured,
> and
> by an hostile party).
>
>
> --
> 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 /.)
>
>

[-- Attachment #2: Type: text/html, Size: 2017 bytes --]

Re: TPM support with SATA drives

[Laurent Dufrechou]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

2008/4/18, Robert Millan <rmh@aybabtu.com>:
>
> On Fri, Apr 18, 2008 at 11:06:19AM +0200, Laurent Dufréchou wrote:
> >
>
> > Now, I've just discovered Grub2.
> >
> > I'm wondering if there is some patch to add support for TPM chip and
> > measurement of files on system, thus on sata drive.
>
>
> Just in case my last message was a bit too confusing, measurement is
> something
> that I think would be nice to have.  It just happens that we don't need a
> TPM
> at all to implement it (TPM is not about measuring but _being_ measured,
> and
> by an hostile party).
>
>
> --
> 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 /.)
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

[-- Attachment #2: Type: text/html, Size: 1345 bytes --]

Re: TPM support with SATA drives

[Laurent Dufrechou]

[-- Attachment #1: Type: text/plain, Size: 2037 bytes --]

Hope the mail will reach you this time...

Yeah I see what you mean., and I agree a lot. I got a TPM chip in my
computer that I could use to encrypt my hard dsk but I will never use it as
I don't have access to all the thing.
In fact what i'm askig is for a special use case.
My use case is that I provide an embedded computer running linux operating
system, and I want to be sure that the all system that I can't remotly
manage isn't corrupted to its task.
In this case I'm in the case of the "Hostile party Bad Guy wanting to
measure you" ;).
I think TPM chip can only be used for that. Not for like they claim to give
to classical user a trusted computer.
I want to use it to trust MY computer used by another guy (that can be an
attacker). (industry market, not consumer one)
I think in this use case it is ehicaly correct as I try to measure and
ensure my system is not corrupted. (Must be the only case where TPM chip are
good at :) )

Laurent

2008/4/18, Robert Millan <rmh@aybabtu.com>:
>
> On Fri, Apr 18, 2008 at 11:06:19AM +0200, Laurent Dufréchou wrote:
> >
>
> > Now, I've just discovered Grub2.
> >
> > I'm wondering if there is some patch to add support for TPM chip and
> > measurement of files on system, thus on sata drive.
>
>
> Just in case my last message was a bit too confusing, measurement is
> something
> that I think would be nice to have.  It just happens that we don't need a
> TPM
> at all to implement it (TPM is not about measuring but _being_ measured,
> and
> by an hostile party).
>
>
> --
> 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 /.)
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Laurent Dufrechou
Hardware Engineering

Marport
16 Blv Abbé Louis LE CAM
56100 Lorient

Tél  : +33(0)635028304
Fax : +33(0)297884812

[-- Attachment #2: Type: text/html, Size: 2541 bytes --]

Re: TPM support with SATA drives

[Robert Millan]

On Fri, Apr 18, 2008 at 02:07:12PM +0200, Laurent Dufréchou wrote:
> Yeah I see what you mean., and I agree a lot. I got a TPM chip in my
> computer that I could use to encrypt my hard dsk but I will never use it as
> I don't have access to all the thing.
> In fact what i'm askig is for a special use case.
> My use case is that I provide an embedded computer running linux operating
> system, and I want to be sure that the all system that I can't remotly
> manage isn't corrupted to its task.
> In this case I'm in the case of the "Hostile party Bad Guy wanting to
> measure you" ;).
> I think TPM chip can only be used for that. Not for like they claim to give
> to classical user a trusted computer.
> I want to use it to trust MY computer used by another guy (that can be an
> attacker). (industry market, not consumer one)
> I think in this use case it is ehicaly correct as I try to measure and
> ensure my system is not corrupted. (Must be the only case where TPM chip are
> good at :) )

I believe you can accomplish that by booting the system from USB.  Just point
your /boot partition to a USB stick, then encrypt the hard drive.  Then use
the stick as a "key" that is never left to untrusted hands (or, at most, is
only copied from a master, known-untampered key).

This would allow you to have security without making yourself dependant on
such kind of nasty technology.

-- 
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 /.)

Re: TPM support with SATA drives

[Robert Millan]

On Fri, Apr 18, 2008 at 02:08:59PM +0200, Laurent Dufrechou wrote:
> I think in this use case it is ehicaly correct as I try to measure and
> ensure my system is not corrupted. (Must be the only case where TPM chip are
> good at :) )

This is true in fact.  What happens here is that Treacherous Computing
proponents realize they would have no case for marketing their crap if they
just advertized it as "when you surrender your freedom to someone else, this
device allows you to prove you have surrendered it, so that those who don't
can be challenged and wiped out".

So they coupled their technology with other use cases, such as making systems
you own tamper-proof against illegitimate attackers.  There's nothing ethically
wrong with protecting yourself!  But if you use their technology to do it, in
a way you're supporting them.  Next time you buy a motherboard, you'll demand
a TPM in it;  and help make sure every motherboard has a TPM in it.  Then, when
everyone has a TPM around, and uses a TPM-capable software stack, remote
attestation can be implemented in a breeze.

-- 
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 /.)

Re: TPM support with SATA drives

[Julian Blake Kongslie]

On Fri, 2008-04-18 at 13:22 +0200, Robert Millan wrote:
> Hi Laurent,
> 
> The problem with these TPM chips is that they have the hidden purpose of
> restricting you as user.  Despite that you paid for the hardware and are its
> owner, the chip will never give you its master key.

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: 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.

> 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.

> For these reasons, I'd like to encourage you to consider the ethical
> implications of using and supporting this technology, and look for
> alternatives that would satisfy whatever needs you had in it (I'd welcome
> some discussion about that, to see how GRUB can help).

-- 
-Julian Blake Kongslie
<jblake@omgwallhack.org>

If this is a mailing list, please CC me on replies.
vim: set ft=text :

RE: TPM support with SATA drives

[Laurent Dufréchou]

So, will grub2 will one day support TPM ? ;)

-----Message d'origine-----
De : grub-devel-bounces+laurent.dufrechou=gmail.com@gnu.org
[mailto:grub-devel-bounces+laurent.dufrechou=gmail.com@gnu.org] De la part
de Julian Blake Kongslie
Envoyé : vendredi 18 avril 2008 20:21
À : The development of GRUB 2
Objet : Re: TPM support with SATA drives

On Fri, 2008-04-18 at 13:22 +0200, Robert Millan wrote:
> Hi Laurent,
> 
> The problem with these TPM chips is that they have the hidden purpose of
> restricting you as user.  Despite that you paid for the hardware and are
its
> owner, the chip will never give you its master key.

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: 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.

> 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.

> For these reasons, I'd like to encourage you to consider the ethical
> implications of using and supporting this technology, and look for
> alternatives that would satisfy whatever needs you had in it (I'd welcome
> some discussion about that, to see how GRUB can help).

-- 
-Julian Blake Kongslie
<jblake@omgwallhack.org>

If this is a mailing list, please CC me on replies.
vim: set ft=text :



_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/grub-devel

Re: TPM support with SATA drives

[Robert Millan]

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 /.)

Re: TPM support with SATA drives

[Robert Millan]

On Fri, Apr 18, 2008 at 08:33:07PM +0200, Laurent Dufréchou wrote:
> So, will grub2 will one day support TPM ? ;)

It doesn't really matter.  GRUB 2 is free software, so if it doesn't support
TPM, someone else will provide a modified version.

We can't stop the evil by refusing to implement it, but at least we can speak
out about it, and let people know that TPMs are inherently designed to restrict
against the legitimate owner of a device.

I once came across this comment on slashdot, which summarises the problem
very well IMHO:

  http://it.slashdot.org/comments.pl?sid=221046&cid=17934808

-- 
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 /.)

Re: TPM support with SATA drives

[Robert Millan]

On Sun, Apr 20, 2008 at 12:07:01AM -0700, Julian Blake Kongslie wrote:
> I'm taking this sub-discussion off-list because we're clearly no longer
> particularly relevant to Grub. If you particularly want to keep it
> on-list, feel free to forward this message to the list on your own.

Ok.  With your permission, I will.  But I encourage you to reconsider keeping
it on-list.  I think it's beneficial to have this discussion in public, and
also think it's relevant to GRUB.  We get enquiries about this all the time,
and I believe it's critical that information about this problem can be spread
as much as possible.

> On Sat, 2008-04-19 at 13:34 +0200, Robert Millan wrote:
> > 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.
> 
> Note that the vendor may not have the master key, either. In the TPM I
> have, taking ownership changes the keys stored on-chip, including the
> endorsement key and the SRK.
> 
> >   - 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.
> 
> Or, you can boot into Linux, feed in the same PCR updates that windows
> would, and generate the same certificate.
> 
> Note that TPM, as specified, is actually weaker than this: in my case,
> once I have informed someone of my true endorsement key, I cannot rerun
> the take ownership functionality of my TPM without being forced to
> notify them that my endorsement key has changed. In the normal TPM
> situation, I could freely give out my true endorsement public key,
> possibly running whatever software they wanted me to in the process,
> then wipe my system, rerun the take ownership function, and ask my
> (presumably free-software) operating system to send whatever PCR updates
> and endorse whatever messages I wanted, with the same key.

You're getting into very specific details, that I can't follow.  I haven't
studied how the TCG stack works in depth.  What I know are the fundamentals:

  - They say you can use that to implement remote attestation.
  - You can't implement remote attestation without a master key that the
    TPM can use to sign things, but is not under your control.

This is enough of a point for me.  Unless you can deny them, there's no reason
that we start discussing specific details.

> > 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).
> 
> Owner override is a means of directly changing PCRs instead of following
> the PCR update protocol -- this very nearly removes the point of the
> PCRs entirely, yes. That said, I suspect tieing it to the physical
> access bit and adding another control bit would be acceptable, as there
> are already ways to arrange for an arbitrary final PCR configuration
> with work and a cooperative OS

When you say "cooperative OS", do you mean an OS that will cooperate with
the user, or that will cooperate with someone else in order to implement
remote attestation?

> -- I, personally, would be quite happy
> with a tainted bit that was set on any PCR configuration which had been
> overridden, and could not be used as a dependant bit by the TPM sealing
> mechanism (a purely informative bit), but I would be very hesitant of a
> completely invisible override. I am not aware of the exact proposals or
> reasons for rejection that the TCG has made.

Because otherwise remote attestation can't be implemented.  It's obvious
they wanted to embed that mallicious feature in their TPMs in a way that
users can't put it off.

> > 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.
> 
> Alternatively, you could "elect to participate" by sending the
> challenger an arbitrary public key that you claim is from your TPM, but
> is not. How do you propose they tell the difference?

I demand they *DON'T*.  It is my right to claim I'm running CrapWare 2000[tm]
any time I want to, whether I'm really running it or not.  It is in fact a
very basic right.  If you live in the US, it's protected under the First
Amendment.  And TPM proponents are trying to jeopardize it by use of technical
means.

And in fact the consequences are terrible.  Next time you see, your right to
run a free operating system will have disappeared.  Websites you visit will
insist you run Adobe Flash or Microsoft Silverlight, since they want to use
DRM features on these programs.  Heck, maybe even your ISP will forbid you
from using the Internet unless you agree to let them spy on you.

> > 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).
> 
> It seems, to me, like you are heavily confusing the hardware features
> provided by a TPM and the software dis-features commonly provided by,
> for example, the Windows operating system. They really don't depend on
> eachother

I know that.  In fact remote attestation is not completely implemented yet.

But it's only a matter of time untill existing anti-features are ported to
it, or new anti-features are developed.

> - a TPM is a wonderful tool for me, as a free-software user,
> to gain significant extra security on my system. If you're using an
> operating system you already don't trust to act in your interest, the
> hardware's cooperation isn't particularly required for it to make your
> life torture and deny you access to your own files.

It would be a wonderful tool if they hadn't added poison to it.  When you can
buy a TPM and get a printed copy of its master key at the same time, *then*
I'll agree with you on this.

Really, we're on the same boat.  You just want security features, which is
fine.  The only problem is that hardware vendors who would provide these
features to you, put a poison pill in them.  Instead of accepting their
blackmail, demand that they provide those features without the poison.  It'll
work wonders for you if they do, and you won't be acting against the freedoms
of users.

Btw, my expertise with hardware engineering is very limited.  How difficult
would it be for a small group to develop schematics for a TPM chip that
doesn't restrict the user?  Then its licensing terms could demand that its
master key is always passed along to its owner, or something like that.

-- 
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 /.)

Re: TPM support with SATA drives

[Chris Knadle]

On Saturday 19 April 2008, Robert Millan wrote:
> 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).

   I think you're right about TPM, Robert.  :-/

   I recently acquired a laptop that came with a TPM chip; thankfully I was 
aware of what TPM was indended to be used for and had read warnings on the 
matter from privacy advocates.  The laptop came with Vista preloaded, which 
asked a vague [and perhaps intentionally misleading] question, something 
along the lines of: "This device has a TPM chip which has not yet been 
activated, would you like to activate it now?  It will help security if you 
do."  [To which I answered NO.]

   And in the BIOS settings, sure enough there are some TPM feature settings 
that are very clearly not to the benefit of the user/owner:

   Security Reporting Options: (each below has enable/disable option)
      BIOS ROM String Reporting
      ESCD Reporting
      CMOS Reporting
      NVRAM Reporting
      SMBIOS Reporting
   Clear Security Chip (enable/disable)
      Note says: "It will not be possible to access already-encrypted data
                  after these keys are cleared"

   I think it's pretty clear that the intent is to report the above 
information to the OS manufacturer rather than to the user or owner.

   -- Chris

-- 

Chris Knadle
Chris.Knadle@coredump.us

Re: TPM support with SATA drives

[Robert Millan]

On Sat, Apr 26, 2008 at 10:58:14PM -0400, Chris Knadle wrote:
> 
>    I think you're right about TPM, Robert.  :-/
> 
>    I recently acquired a laptop that came with a TPM chip; thankfully I was 
> aware of what TPM was indended to be used for and had read warnings on the 
> matter from privacy advocates.  The laptop came with Vista preloaded, which 
> asked a vague [and perhaps intentionally misleading] question, something 
> along the lines of: "This device has a TPM chip which has not yet been 
> activated, would you like to activate it now?  It will help security if you 
> do."  [To which I answered NO.]
> 
>    And in the BIOS settings, sure enough there are some TPM feature settings 
> that are very clearly not to the benefit of the user/owner:
> 
>    Security Reporting Options: (each below has enable/disable option)
>       BIOS ROM String Reporting
>       ESCD Reporting
>       CMOS Reporting
>       NVRAM Reporting
>       SMBIOS Reporting
>    Clear Security Chip (enable/disable)
>       Note says: "It will not be possible to access already-encrypted data
>                   after these keys are cleared"
> 
>    I think it's pretty clear that the intent is to report the above 
> information to the OS manufacturer rather than to the user or owner.

I'm not sure if this is what you found.  Maybe it's too early, but it's
certainly something that I expect seeing in the near future.  When EFI
starts being deployed out there, new firmware implementations will have
the capability to spy on you all by themselves, since they can trap all
memory accesses and come with a networking stack they can use to call home.

Really scary...

-- 
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 /.)