TPM support status ?

TPM support status ?

[Emmanuel Fleury]

Dear all,

I know this is a quite sensitive topic and I'm really not willing to
start a new flame-war about it. I just want to know the exact status of
it and what is the (official) position of the GRUB team on the TPM support.

Last discussion about the TPM issue was in February (see:
http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00217.html) and
it ended up with a kind of statu quo.

I just propose to expose the consequences of TPM support for GRUB, first
in a technical point of view and then on an ethical one. Then, I hope
the GRUB team will write his official position on the TPM support.


1) Technical Aspects
====================

From a purely technical point of view, the TPM support in GRUB is about
the "Trusted Boot" with a partial support and a full one.

Partial support means that GRUB is able to (TPM commands are taken from
"Part 3 - Commands", see further for references):

1) Perform a SHA-1 digest (TPM_SHA1Start and TPM_SHA1Update commands) of
the kernel that is intended to be loaded.

2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
SHA-1 digest.

3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
of a previous (safe) boot. We assume that the previous link of the chain
of trust (BIOS?) has already checked that GRUB hasn't been tampered
before starting it.

If this part fail, GRUB should stop here and tell the user that the
kernel has been tampered. If everything went ok, GRUB get back to the
usual way...



A full support of TPM means that GRUB should also be able to ask to a
remote authority if the content of the PCR is still ok... Technically,
it would be stupid to include a full TCP/IP stack (or whatever network
protocol) into GRUB, so it would be much more realistic to just leave it
to the OS and only pass the needed data to it.

[Note: I have to admit that I don't see how to deal properly with this
full support as you somehow need to rely on some links of the chain of
trust that may have been tampered. Implementing this step may require
quite a lot of thinking (and personally, I don't think it worth it...
but it's only my humble opinion).]


For the TPM specifications see:

- Part 1 - Design Principles
http://www.trustedcomputinggroup.org/files/resource_files/ACD19914-1D09-3519-ADA64741A1A15795/mainP1DPrev103.zip

- Part 2 - Structures of the TPM
http://www.trustedcomputinggroup.org/files/resource_files/8D3D6571-1D09-3519-AD22EA2911D4E9D0/mainP2Structrev103.pdf

- Part 3 - Commands
http://www.trustedcomputinggroup.org/files/static_page_files/ACD28F6C-1D09-3519-AD210DC2597F1E4C/mainP3Commandsrev103.pdf


2) Ethical Aspects
==================

Ok, lets end here with the technical point of view and consider now the
ethical point of view.

The core of the problem with TPM has been nicely summed up by Robert
Millan in the last thread about it:

« If there was a device that behaves like a TPM except remote
attestation is not possible (e.g. by one of the means described above),
I wouldn't object to it, and I think the GNU project wouldn't either,
but then referring to that as "TPM" is misleading. »

Indeed, let us imagine one moment that GRUB has a full support of TPM
(meaning what I've stated before plus remote attestation).

Firms will be able to use GRUB to lock down a computer to a specific
software suite. Being able to remotely add (or revoke) at will some of
its customers. Which is quite close to the "treacherous computing"
described by Stallman...

The only thing users can do, would be to install a new BIOS, totally
reformat the hard-drive and install his own OS.

[Note that, according to the TPM specifications, it is always possible
to clear the TPM without password under physical presence assertion
(TPM_ForceClear command, Part 3, p.29) and thus the user will also be
able to use the TPM (if you are ok to loose all the data stored on the
platform).]

On the other hand, there is a quite high step between the partial
support that I've described before and the full support with remote
attestation... (and users may require this partial support for their own
usage).

Now, the question whether one shouldn't support a technology because it
may lead to evil usage is something that should be solved inside the
GRUB team (and I believe that the GRUB team has already solved this
question out).


3) GRUB Team Position ?
=======================

So, what is the official position of the GRUB team about TPM ? Did it
change since February ?

Regards
-- 
Emmanuel Fleury

Programs must be written for people to read,
and only incidentally for machines to execute.
  -- Abelson & Sussman, SICP, preface to the first edition

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 1:00 PM, Emmanuel Fleury<fleury@labri.fr> wrote:
> Dear all,
>
> I know this is a quite sensitive topic and I'm really not willing to
> start a new flame-war about it. I just want to know the exact status of
> it and what is the (official) position of the GRUB team on the TPM support.
>
> Last discussion about the TPM issue was in February (see:
> http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00217.html) and
> it ended up with a kind of statu quo.
It wasn't a status quo. TPM is a harmful technology which can't be
accepted in any software conscious of freedom. I know that TPM can
provide features some people consider useful but:
1) Making use of TPM you become dependent on good will of TPM
manufacturer. You can never know if or when the TPM manufacturer or
someone connected with them will ask you to use remote attestation to
prove them that you use only the software they signed and that they
effectively control your computer. Put in simple words it's like
locking you with your computer in a prison cell and going in this cell
every time you use your computer and relying on someone else to gently
open you the door every time you need it. It this case even if you
really trust the person holding cell keys it's not a freedom.
You can argue that there are several TPM manufacturers and none will
do any nasty things but you forget about TPM consortium and that
actions around TPM are coordinated and that harmful features are a
part of TPM specification.
2) The similar features can be implemented without resorting to TPM by
using coreboot and make every stage verify the signature of every next
stage. Signature handling will be done in grub when crypto patches are
merged and someone (perhaps me) will have enough time to implement
signatures (I already implemented RSA once but unfortunately I deleted
my compile directory which also had sources). This is like locking
your computer and keeping the key.
3) TPM manufacturers claim to achieve the goals like being
tamperproof. This is simply not possible. Everything is tamperable.
It's just the question of effort. Someone with electronic microscope
and enough time and material would be able to recover TPM key. And
electronic microscope is something you can have access to if you have
a diploma or connections. Even without such equipment it's just a
question of time before a fatal flow in TPM is discovered and
published. After that point TPM wouldn't be very different from WEP.
One of such flows is very known: firewire. Anyone with physical access
to your computer can add a firewire card to it and dump RAM through it
and have any information he wants.
Any cryptographical implementation claiming to achieve impossible has
a weakness. If it's open-source it clearly states "weakness is this"
and explains whole functionality. Commercial implementations would
just close the specifications, hide the weakness and sell as much as
they can before the weakness is found out.
It's like trusting someone something is steel just because it looks like such.
In short tamperproof is unachievable. If your goal is to delay the
attacker, obfuscate your system yourself. This way you have the
advantage that the attacker can't just read publication and see the
weaknesses of a particular system. If your goal is to deflect physical
attacks the only way to do so is to restrict physical access. Put good
locks and guards around your computer or bury it and put concrete
around it or use any of 1000 ways to physically protect the computer.
>
> I just propose to expose the consequences of TPM support for GRUB, first
> in a technical point of view and then on an ethical one. Then, I hope
> the GRUB team will write his official position on the TPM support.
>
GRUB is GNU project and GNU's position is detailed here:
http://www.gnu.org/philosophy/can-you-trust.html
>
> 1) Technical Aspects
> ====================
>
> From a purely technical point of view, the TPM support in GRUB is about
> the "Trusted Boot" with a partial support and a full one.
>
> Partial support means that GRUB is able to (TPM commands are taken from
> "Part 3 - Commands", see further for references):
>
> 1) Perform a SHA-1 digest (TPM_SHA1Start and TPM_SHA1Update commands) of
> the kernel that is intended to be loaded.
>
Michael Gorven has ported libgcrypt SHA-1 and other hashes to grub2.
Additionally SHA-1 is depreceated and flawed.
> 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
> SHA-1 digest.
>
Why would we need a chip to check if SHA-1 matches if we can use signatures?
>
> 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
> of a previous (safe) boot. We assume that the previous link of the chain
> of trust (BIOS?) has already checked that GRUB hasn't been tampered
> before starting it.
You propose to check that our checksum in PCR is ok but you already
assume GRUB wasn't tampered. If you assume grub wasn't tampered no
need to checksum. If you don't it's useless to checksum.
>
> If this part fail, GRUB should stop here and tell the user that the
> kernel has been tampered. If everything went ok, GRUB get back to the
> usual way...
>
Signatures give that
>
>
> A full support of TPM means that GRUB should also be able to ask to a
> remote authority if the content of the PCR is still ok...
Why do I as user need someone else to check my computer?
>
> [Note that, according to the TPM specifications, it is always possible
> to clear the TPM without password under physical presence assertion
> (TPM_ForceClear command, Part 3, p.29) and thus the user will also be
> able to use the TPM (if you are ok to loose all the data stored on the
> platform).]
If you assume attacker has no physical access to a machine checking
signatures on updates recieved from network and proper permission
model is enough to deflect any attack
>
> On the other hand, there is a quite high step between the partial
> support that I've described before and the full support with remote
> attestation... (and users may require this partial support for their own
> usage).
Usage like? We're speaking about security here and any serious secure
system has to answer questions:
1) "Which attacks is it supposed to deflect?"
2) "Does it deflect those attacks?"
3) "How much does the security costs?" (in money, ressources and inconvinience)
4) "Which other holes does it open?"
(inexact quotation of Bruce Schneier)
Just adding crpytography layers, pronouncing "AES" three times a day
or putting autographed picture of Bruce Schneier on your computer
doesn't enhance the security.
>
> Now, the question whether one shouldn't support a technology because it
> may lead to evil usage is something that should be solved inside the
> GRUB team (and I believe that the GRUB team has already solved this
> question out).
It's not like just "can lead". Remote attestation is a part of TPM
spec. It's like saying nuclear bombs aren't a problem just because
"they can explode".



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
> 1) Making use of TPM you become dependent on good will of TPM
> manufacturer. You can never know if or when the TPM manufacturer or
> someone connected with them will ask you to use remote attestation to
> prove them that you use only the software they signed and that they
> effectively control your computer.

How are you dependent? If they ask you to use remote attestation then just say 
no -- what would you gain? You're probably not using any of their software 
anyway. They can't stop your system from working.

> 2) The similar features can be implemented without resorting to TPM by
> using coreboot and make every stage verify the signature of every next
> stage.

Trust has to start somewhere, and the more difficult it is to compromise that 
the better.
 
> 3) TPM manufacturers claim to achieve the goals like being
> tamperproof. This is simply not possible. Everything is tamperable.
> It's just the question of effort.

Correct, but making hardware the root of trust is more secure than a flashable 
BIOS or the harddrive contents.

> Even without such equipment it's just a
> question of time before a fatal flow in TPM is discovered and
> published. After that point TPM wouldn't be very different from WEP.

Yes, but we used WEP because it was the best available security at the time. 
And then we moved on to WPA. You can't argue that one shouldn't use something 
because it will surely have flaws because otherwise we wouldn't use anything 
at all.

> > 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
> > SHA-1 digest.
>
> Why would we need a chip to check if SHA-1 matches if we can use
> signatures?

Because the BIOS or bootloader can be replaced to remove the check.

> > 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
> > of a previous (safe) boot. We assume that the previous link of the chain
> > of trust (BIOS?) has already checked that GRUB hasn't been tampered
> > before starting it.
>
> You propose to check that our checksum in PCR is ok but you already
> assume GRUB wasn't tampered. If you assume grub wasn't tampered no
> need to checksum. If you don't it's useless to checksum.

That isn't assumed -- the BIOS checks that GRUB isn't tampered with before 
moving control to it.

> > A full support of TPM means that GRUB should also be able to ask to a
> > remote authority if the content of the PCR is still ok...
>
> Why do I as user need someone else to check my computer?

Because you don't always own or completely control the computer. 

> If you assume attacker has no physical access to a machine checking
> signatures on updates recieved from network and proper permission
> model is enough to deflect any attack

There will always be flaws in the system ;-)

> > Now, the question whether one shouldn't support a technology because it
> > may lead to evil usage is something that should be solved inside the
> > GRUB team (and I believe that the GRUB team has already solved this
> > question out).
>
> It's not like just "can lead". Remote attestation is a part of TPM
> spec. It's like saying nuclear bombs aren't a problem just because
> "they can explode".

It is, but that doesn't mean it has to be implemented.

I see TPM as a very useful security measure, and support in GRUB can help make 
*nix systems much more secure. As Emmanuel noted, the TPM can always be 
cleared, and even if it's holding harddrive encryption keys you should have a 
backup key anyway. You can only be held hostage to the TPM if you're not 
sensible about the way it's setup.

The only valid argument I see against TPM is the 
supporting-possibly-harmful-technology one. But then we shouldn't use crypto 
at all because it can be used for DRM...

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 2:25 PM, Michael Gorven<michael@gorven.za.net> wrote:
> On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
>> 1) Making use of TPM you become dependent on good will of TPM
>> manufacturer. You can never know if or when the TPM manufacturer or
>> someone connected with them will ask you to use remote attestation to
>> prove them that you use only the software they signed and that they
>> effectively control your computer.
>
> How are you dependent? If they ask you to use remote attestation then just say
> no -- what would you gain? You're probably not using any of their software
> anyway. They can't stop your system from working.
Even if they can't stop from working at all they can make it
effectively useless by e.g. not allowing you to see online videos, buy
online or even just send an e-mail (saying it's "spam control") if you
aren't TPM-checked
>
>> 2) The similar features can be implemented without resorting to TPM by
>> using coreboot and make every stage verify the signature of every next
>> stage.
>
> Trust has to start somewhere, and the more difficult it is to compromise that
> the better.
>
flash rom with cut write wire is impossible to compromise without
physical access.
>> 3) TPM manufacturers claim to achieve the goals like being
>> tamperproof. This is simply not possible. Everything is tamperable.
>> It's just the question of effort.
>
> Correct, but making hardware the root of trust is more secure than a flashable
> BIOS or the harddrive contents.
>
Cut write wire?
>> Even without such equipment it's just a
>> question of time before a fatal flow in TPM is discovered and
>> published. After that point TPM wouldn't be very different from WEP.
>
> Yes, but we used WEP because it was the best available security at the time.
> And then we moved on to WPA. You can't argue that one shouldn't use something
> because it will surely have flaws because otherwise we wouldn't use anything
> at all.
But TPM isn't the "best available security" now.
>
>> > 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
>> > SHA-1 digest.
>>
>> Why would we need a chip to check if SHA-1 matches if we can use
>> signatures?
>
> Because the BIOS or bootloader can be replaced to remove the check.
>
And you can mess with PCI to fool TPM.
>> > 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
>> > of a previous (safe) boot. We assume that the previous link of the chain
>> > of trust (BIOS?) has already checked that GRUB hasn't been tampered
>> > before starting it.
>>
>> You propose to check that our checksum in PCR is ok but you already
>> assume GRUB wasn't tampered. If you assume grub wasn't tampered no
>> need to checksum. If you don't it's useless to checksum.
>
> That isn't assumed -- the BIOS checks that GRUB isn't tampered with before
> moving control to it.
>

Coreboot can make this too. And firmware doesn't need TPM to do such checks.

>> > A full support of TPM means that GRUB should also be able to ask to a
>> > remote authority if the content of the PCR is still ok...
>>
>> Why do I as user need someone else to check my computer?
>
> Because you don't always own or completely control the computer.
>

Then someone is already holding you hostage. We won't help them to
restrict your freedom further.

>> > Now, the question whether one shouldn't support a technology because it
>> > may lead to evil usage is something that should be solved inside the
>> > GRUB team (and I believe that the GRUB team has already solved this
>> > question out).
>>
>> It's not like just "can lead". Remote attestation is a part of TPM
>> spec. It's like saying nuclear bombs aren't a problem just because
>> "they can explode".
>
> It is, but that doesn't mean it has to be implemented.
>
> I see TPM as a very useful security measure, and support in GRUB can help make
> *nix systems much more secure.
How? Respond to questions I asked (the 4 crypto questions). During
your whole discussion you assumed that attacker already has root
access and argued how to prevent him from changing the kernel. But
what's the use if he already has root access (or in other words
already has the security on the knees and can do whatever he wants).
>
> The only valid argument I see against TPM is the
> supporting-possibly-harmful-technology one. But then we shouldn't use crypto
> at all because it can be used for DRM...
It's not just "possibly harmful", it's "designed with harm in the mind".
>
> Michael
>
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
> Even if they can't stop from working at all they can make it
> effectively useless by e.g. not allowing you to see online videos, buy
> online or even just send an e-mail (saying it's "spam control") if you
> aren't TPM-checked

That falls under the supporting-possibly-harmful-technology argument. It's not 
very different from saying "you must use Silverlight to view videos" and 
whatnot. If you don't want to follow their requirements, then don't.

> >> 2) The similar features can be implemented without resorting to TPM by
> >> using coreboot and make every stage verify the signature of every next
> >> stage.
> >
> > Trust has to start somewhere, and the more difficult it is to compromise
> > that the better.
>
> flash rom with cut write wire is impossible to compromise without
> physical access.

Valid solution, but does it protect the contents of the flash ROM? (i.e. can 
you read the contents?) A minor point is that it does mean you can't upgrade 
your BIOS anymore. It also gets tricky if you're wanting to securely store a 
hardrive decryption key though.

> >> > 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded
> >> > value of a previous (safe) boot. We assume that the previous link of
> >> > the chain of trust (BIOS?) has already checked that GRUB hasn't been
> >> > tampered before starting it.
> >>
> >> You propose to check that our checksum in PCR is ok but you already
> >> assume GRUB wasn't tampered. If you assume grub wasn't tampered no
> >> need to checksum. If you don't it's useless to checksum.
> >
> > That isn't assumed -- the BIOS checks that GRUB isn't tampered with
> > before moving control to it.
>
> Coreboot can make this too. And firmware doesn't need TPM to do such
> checks.

Yes, except coreboot isn't widely supported.

> >> > A full support of TPM means that GRUB should also be able to ask to a
> >> > remote authority if the content of the PCR is still ok...
> >>
> >> Why do I as user need someone else to check my computer?
> >
> > Because you don't always own or completely control the computer.
>
> Then someone is already holding you hostage. We won't help them to
> restrict your freedom further.

Or you're the person who owns and wants to secure the computer. Maybe you want 
to co-locate your server and make sure the technicians at the DC can't 
compromise it, or you're guarding against data loss if your laptop gets 
stolen without having to enter decryption passwords on boot, or a whole lot 
of other situation where *you* are putting *your* computer in an untrusted 
environment.

> How? Respond to questions I asked (the 4 crypto questions). During
> your whole discussion you assumed that attacker already has root
> access and argued how to prevent him from changing the kernel. But
> what's the use if he already has root access (or in other words
> already has the security on the knees and can do whatever he wants).

> 1) "Which attacks is it supposed to deflect?"

My main use case is unattended booting with an encrypted harddrive, and 
protecting against physical access or theft.

> 2) "Does it deflect those attacks?"

It seriously raises the bar to such attacks, since the attacker would need to 
pry the decryption key out of the hardware.

> 3) "How much does the security costs?" (in money, ressources and
> inconvinience)

The cost of a TPM chip and some setup time.

> 4) "Which other holes does it open?" 

Obviously the TPM could have flaws which cause it to divulge the decryption 
key. I don't see it lessening the security of the system though.

> > The only valid argument I see against TPM is the
> > supporting-possibly-harmful-technology one. But then we shouldn't use
> > crypto at all because it can be used for DRM...
>
> It's not just "possibly harmful", it's "designed with harm in the mind".

Disagree.

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 3:24 PM, Michael Gorven<michael@gorven.za.net> wrote:
> On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
>> Even if they can't stop from working at all they can make it
>> effectively useless by e.g. not allowing you to see online videos, buy
>> online or even just send an e-mail (saying it's "spam control") if you
>> aren't TPM-checked
>
> That falls under the supporting-possibly-harmful-technology argument. It's not
> very different from saying "you must use Silverlight to view videos" and
> whatnot. If you don't want to follow their requirements, then don't.
>
If it becomes widespread you will need to crack TPM to use mplayer to
watch videos.
>> >> 2) The similar features can be implemented without resorting to TPM by
>> >> using coreboot and make every stage verify the signature of every next
>> >> stage.
>> >
>> > Trust has to start somewhere, and the more difficult it is to compromise
>> > that the better.
>>
>> flash rom with cut write wire is impossible to compromise without
>> physical access.
>
> Valid solution, but does it protect the contents of the flash ROM? (i.e. can
> you read the contents?)
You need root access or possibility to remove the chip. Which can be
made arbitrarily hard
>> Coreboot can make this too. And firmware doesn't need TPM to do such
>> checks.
>
> Yes, except coreboot isn't widely supported.
It's not a reason to obey BIOS manufacturers.
>
>> >> > A full support of TPM means that GRUB should also be able to ask to a
>> >> > remote authority if the content of the PCR is still ok...
>> >>
>> >> Why do I as user need someone else to check my computer?
>> >
>> > Because you don't always own or completely control the computer.
>>
>> Then someone is already holding you hostage. We won't help them to
>> restrict your freedom further.
>
> Or you're the person who owns and wants to secure the computer. Maybe you want
> to co-locate your server and make sure the technicians at the DC can't
> compromise it,
If you don't trust a location, change it. They have physical access
and can execute a wide range of attacks.
> or you're guarding against data loss if your laptop gets
> stolen without having to enter decryption passwords on boot, or a whole lot
> of other situation where *you* are putting *your* computer in an untrusted
> environment.
If there is no interractive authentication key is stolen together with
laptop. If you have data worth more than a laptop itself you can't
assume your attacker to be short on resources. If you don't most
thieves will just wipe the harddrive.
>
>> How? Respond to questions I asked (the 4 crypto questions). During
>> your whole discussion you assumed that attacker already has root
>> access and argued how to prevent him from changing the kernel. But
>> what's the use if he already has root access (or in other words
>> already has the security on the knees and can do whatever he wants).
>
>> 1) "Which attacks is it supposed to deflect?"
>
> My main use case is unattended booting with an encrypted harddrive, and
> protecting against physical access or theft.
>
>> 2) "Does it deflect those attacks?"
>
> It seriously raises the bar to such attacks, since the attacker would need to
> pry the decryption key out of the hardware.
>
You can't seriously assume an attacker with intentions not having
enough money to buy a system using same RAM format and few bottles of
liquid nitrogen and download linux designed for cold boot attack.
As you can see for an attacker with intentions TPM isn't of any
problem. Supporting it would mean waste time and risk freedom of all
GNU users just for the few to feel more secure ("feel" and not "be").
>> 3) "How much does the security costs?" (in money, ressources and
>> inconvinience)
>
> The cost of a TPM chip and some setup time.
>
And the freedom.
>> 4) "Which other holes does it open?"
>
> Obviously the TPM could have flaws which cause it to divulge the decryption
> key. I don't see it lessening the security of the system though.
>
using GPT instead of pc-style would also increase security with this
idea since you need an OS supporting it.

>> > The only valid argument I see against TPM is the
>> > supporting-possibly-harmful-technology one. But then we shouldn't use
>> > crypto at all because it can be used for DRM...
>>
>> It's not just "possibly harmful", it's "designed with harm in the mind".
>
> Disagree.
Why is remote attestation an important part of specification then? Why
don't they want to give you the key burned in TPM on a piece of paper?
Why do options to reset TPM are "optional"?
>
> Michael
>
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wed, Aug 19, 2009 at 03:48:18PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>On Wed, Aug 19, 2009 at 3:24 PM, Michael Gorven<michael@gorven.za.net> wrote:
>> On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
>>> Even if they can't stop from working at all they can make it
>>> effectively useless by e.g. not allowing you to see online videos, buy
>>> online or even just send an e-mail (saying it's "spam control") if you
>>> aren't TPM-checked
>>
>> That falls under the supporting-possibly-harmful-technology argument. It's not
>> very different from saying "you must use Silverlight to view videos" and
>> whatnot. If you don't want to follow their requirements, then don't.
>>
>If it becomes widespread you will need to crack TPM to use mplayer to
>watch videos.

Yes, this is a possibility.

>>> >> 2) The similar features can be implemented without resorting to TPM by
>>> >> using coreboot and make every stage verify the signature of every next
>>> >> stage.
>>> >
>>> > Trust has to start somewhere, and the more difficult it is to compromise
>>> > that the better.
>>>
>>> flash rom with cut write wire is impossible to compromise without
>>> physical access.
>>
>> Valid solution, but does it protect the contents of the flash ROM? (i.e. can
>> you read the contents?)
>You need root access or possibility to remove the chip. Which can be
>made arbitrarily hard

My use case involves physical access.

>>> Coreboot can make this too. And firmware doesn't need TPM to do such
>>> checks.
>>
>> Yes, except coreboot isn't widely supported.
>It's not a reason to obey BIOS manufacturers.

You're not obeying them.

>>> >> > A full support of TPM means that GRUB should also be able to ask to a
>>> >> > remote authority if the content of the PCR is still ok...
>>> >>
>>> >> Why do I as user need someone else to check my computer?
>>> >
>>> > Because you don't always own or completely control the computer.
>>>
>>> Then someone is already holding you hostage. We won't help them to
>>> restrict your freedom further.
>>
>> Or you're the person who owns and wants to secure the computer. Maybe you want
>> to co-locate your server and make sure the technicians at the DC can't
>> compromise it,
>If you don't trust a location, change it. They have physical access
>and can execute a wide range of attacks.

So you're saying that you can't solve my use case, right? TPM provides 
significantly more security against a physical attack.

>> or you're guarding against data loss if your laptop gets
>> stolen without having to enter decryption passwords on boot, or a whole lot
>> of other situation where *you* are putting *your* computer in an untrusted
>> environment.
>If there is no interractive authentication key is stolen together with
>laptop. If you have data worth more than a laptop itself you can't
>assume your attacker to be short on resources. If you don't most
>thieves will just wipe the harddrive.

Yes, but the key can only be used if the system is booted with the 
current trusted parts which would then enforce proper access control.

>>> How? Respond to questions I asked (the 4 crypto questions). During
>>> your whole discussion you assumed that attacker already has root
>>> access and argued how to prevent him from changing the kernel. But
>>> what's the use if he already has root access (or in other words
>>> already has the security on the knees and can do whatever he wants).
>>
>>> 1) "Which attacks is it supposed to deflect?"
>>
>> My main use case is unattended booting with an encrypted harddrive, and
>> protecting against physical access or theft.
>>
>>> 2) "Does it deflect those attacks?"
>>
>> It seriously raises the bar to such attacks, since the attacker would need to
>> pry the decryption key out of the hardware.
>>
>You can't seriously assume an attacker with intentions not having
>enough money to buy a system using same RAM format and few bottles of
>liquid nitrogen and download linux designed for cold boot attack.
>As you can see for an attacker with intentions TPM isn't of any
>problem. Supporting it would mean waste time and risk freedom of all
>GNU users just for the few to feel more secure ("feel" and not "be").

All security is a trade off. Yes, TPM doesn't make it impossible, it 
just makes it a heck of a lot harder and raises the bar significantly.

>>> 3) "How much does the security costs?" (in money, ressources and
>>> inconvinience)
>>
>> The cost of a TPM chip and some setup time.
>>
>And the freedom.

If you don't want to use it then don't. I'd like the freedom to make my 
system more secure.

>>> 4) "Which other holes does it open?"
>>
>> Obviously the TPM could have flaws which cause it to divulge the decryption
>> key. I don't see it lessening the security of the system though.
>>
>using GPT instead of pc-style would also increase security with this
>idea since you need an OS supporting it.

That doesn't provide any security whatsoever.

>>> > The only valid argument I see against TPM is the
>>> > supporting-possibly-harmful-technology one. But then we shouldn't use
>>> > crypto at all because it can be used for DRM...
>>>
>>> It's not just "possibly harmful", it's "designed with harm in the mind".
>>
>> Disagree.
>Why is remote attestation an important part of specification then? Why
>don't they want to give you the key burned in TPM on a piece of paper?
>Why do options to reset TPM are "optional"?

Okay, fair enough, there are parts of TPM which can and are possibly 
intended to screw over the user. That doesn't make the whole thing 
worthless however.

-- 
http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>>>> Coreboot can make this too. And firmware doesn't need TPM to do such
>>>> checks.
>>>
>>> Yes, except coreboot isn't widely supported.
>>
>> It's not a reason to obey BIOS manufacturers.
>
> You're not obeying them.
Yeah?
>> If you don't trust a location, change it. They have physical access
>> and can execute a wide range of attacks.
>
> So you're saying that you can't solve my use case, right? TPM provides
> significantly more security against a physical attack.
For me additional $15 (actually even less, perhaps $5) on attack
aren't "significant increase in security"
>
>>> or you're guarding against data loss if your laptop gets
>>> stolen without having to enter decryption passwords on boot, or a whole
>>> lot
>>> of other situation where *you* are putting *your* computer in an
>>> untrusted
>>> environment.
>>
>> If there is no interractive authentication key is stolen together with
>> laptop. If you have data worth more than a laptop itself you can't
>> assume your attacker to be short on resources. If you don't most
>> thieves will just wipe the harddrive.
>
> Yes, but the key can only be used if the system is booted with the current
> trusted parts which would then enforce proper access control.
>
Watch this: http://www.youtube.com/watch?v=JDaicPIgn9U
> All security is a trade off. Yes, TPM doesn't make it impossible, it just
> makes it a heck of a lot harder and raises the bar significantly.
Again cold boot attack is easy to execute.
>> And the freedom.
>
> If you don't want to use it then don't. I'd like the freedom to make my
> system more secure.
If DRM-TPM is implemented they can e.g. say "your freedom: use TPM or
don't use .doc format" then it may practically boil down to "use TPM
or have no possibility to find any job" or "use TPM or your computer
is useless". If you apply this logic a choice "obey or die" is
freedom.
>> using GPT instead of pc-style would also increase security with this
>> idea since you need an OS supporting it.
>
> That doesn't provide any security whatsoever.
>
Neither does TPM
>> Why is remote attestation an important part of specification then? Why
>> don't they want to give you the key burned in TPM on a piece of paper?
>> Why do options to reset TPM are "optional"?
>
> Okay, fair enough, there are parts of TPM which can and are possibly
> intended to screw over the user. That doesn't make the whole thing worthless
> however.
It makes it dangerous, too dangerous.



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 03:24:34PM +0200, Michael Gorven wrote:
> > > The only valid argument I see against TPM is the
> > > supporting-possibly-harmful-technology one. But then we shouldn't use
> > > crypto at all because it can be used for DRM...
> >
> > It's not just "possibly harmful", it's "designed with harm in the mind".
> 
> Disagree.

Can you give a reason not to provide the owner with any of:

  - A printed copy of the private key corresponding to the chip he paid for.

  - A button in the back of the chip that disables "hostile mode" and makes
    it sign everything that was asked for (so-called "owner override")

...other than implementing features that restrict the owner?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Michael Gorven]

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

On Wed, Aug 19, 2009 at 04:01:39PM +0200, Robert Millan wrote:
>Can you give a reason not to provide the owner with any of:
>
>  - A printed copy of the private key corresponding to the chip he paid for.

Not really, although not having any trace of the private key reduces the 
chance of it being stolen. I find this point kind of moot though because 
the chip can be reset completely -- you don't need the private key.

>  - A button in the back of the chip that disables "hostile mode" and makes
>    it sign everything that was asked for (so-called "owner override")

Because that would not make it secure from physical access.

Michael

-- 
http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 9:53 PM, Michael Gorven<michael@gorven.za.net> wrote:
> On Wed, Aug 19, 2009 at 04:01:39PM +0200, Robert Millan wrote:
>>
>> Can you give a reason not to provide the owner with any of:
>>
>>  - A printed copy of the private key corresponding to the chip he paid
>> for.
>
> Not really, although not having any trace of the private key reduces the
> chance of it being stolen. I find this point kind of moot though because the
> chip can be reset completely -- you don't need the private key.
>
burn it if you want so
>>  - A button in the back of the chip that disables "hostile mode" and makes
>>   it sign everything that was asked for (so-called "owner override")
>
> Because that would not make it secure from physical access.
>
there are ways to securily disable the button if it's needed.



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 09:53:10PM +0200, Michael Gorven wrote:
> On Wed, Aug 19, 2009 at 04:01:39PM +0200, Robert Millan wrote:
>> Can you give a reason not to provide the owner with any of:
>>
>>  - A printed copy of the private key corresponding to the chip he paid for.
>
> Not really, although not having any trace of the private key reduces the  
> chance of it being stolen. I find this point kind of moot though because  
> the chip can be reset completely -- you don't need the private key.

Of course I do.  How else am I supposed to tell this remote website that I am
running Internet Exploiter without actually running it?

It demands a signature that can only be produced with the private key that came
preinstalled in the TPM.  Resetting the TPM won't help at all.

See where this leads to?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 03:24:34PM +0200, Michael Gorven wrote:
> If you don't want to follow their requirements, then don't.

They never had the right to impose arbitrary requirements to media they
produce.  Under the US Constitution (and just about every jurisdiction in
the world) they can't ever get absolute rights over data once they hand it
over to you.

In other words, there's no such thing as "intellectual property".

And this "you opted in" argument is a fallacy.  If people were free to choose
between a crippled and a non-crippled option, they would always choose the
non-crippled one.  The only way they ever accept those terms is either
because they don't have choice or they're missinformed.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Isaac Dupree]

Michael Gorven wrote:
> On Wednesday 19 August 2009 14:42:37 Vladimir 'phcoder' Serbinenko wrote:
>> Even if they can't stop from working at all they can make it
>> effectively useless by e.g. not allowing you to see online videos, buy
>> online or even just send an e-mail (saying it's "spam control") if you
>> aren't TPM-checked
> 
> That falls under the supporting-possibly-harmful-technology argument. It's not 
> very different from saying "you must use Silverlight to view videos" and 
> whatnot. If you don't want to follow their requirements, then don't.
> 
>>>> 2) The similar features can be implemented without resorting to TPM by
>>>> using coreboot and make every stage verify the signature of every next
>>>> stage.
>>> Trust has to start somewhere, and the more difficult it is to compromise
>>> that the better.
>> flash rom with cut write wire is impossible to compromise without
>> physical access.
> 
> Valid solution, but does it protect the contents of the flash ROM? (i.e. can 
> you read the contents?) A minor point is that it does mean you can't upgrade 
> your BIOS anymore. It also gets tricky if you're wanting to securely store a 
> hardrive decryption key though.
> 
>>>>> 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded
>>>>> value of a previous (safe) boot. We assume that the previous link of
>>>>> the chain of trust (BIOS?) has already checked that GRUB hasn't been
>>>>> tampered before starting it.
>>>> You propose to check that our checksum in PCR is ok but you already
>>>> assume GRUB wasn't tampered. If you assume grub wasn't tampered no
>>>> need to checksum. If you don't it's useless to checksum.
>>> That isn't assumed -- the BIOS checks that GRUB isn't tampered with
>>> before moving control to it.
>> Coreboot can make this too. And firmware doesn't need TPM to do such
>> checks.
> 
> Yes, except coreboot isn't widely supported.
> 
>>>>> A full support of TPM means that GRUB should also be able to ask to a
>>>>> remote authority if the content of the PCR is still ok...
>>>> Why do I as user need someone else to check my computer?
>>> Because you don't always own or completely control the computer.
>> Then someone is already holding you hostage. We won't help them to
>> restrict your freedom further.
> 
> Or you're the person who owns and wants to secure the computer. Maybe you want 
> to co-locate your server and make sure the technicians at the DC can't 
> compromise it, or you're guarding against data loss if your laptop gets 
> stolen without having to enter decryption passwords on boot, or a whole lot 
> of other situation where *you* are putting *your* computer in an untrusted 
> environment.

Suppose you are the proud technical support person at a third-world 
school that just bought a thousand OLPC XOs.  You, as part of your 
country's government, are instructed to own those XOs.  If they are 
stolen and get into the hands of innocent third-world civilians who want 
a computer, those computers are instructed to shut off within 24 hours 
and demand to be returned to their original location before they're 
willing to work again.  This harms ordinary users who loved their 
student computer; they might choose not to return it anyway.  It does 
not harm the thieves who steal the XOs and break them down into parts 
and sell the parts.  Civilians with enough expertise might be able to 
replace the BIOS flash to get a working computer again, but there will 
be many ordinary users who can't figure out how to do this (or perhaps, 
don't have the tools). This restriction is not necessarily what makes 
OLPC designers happy, it is merely a condition set by many governments 
who decided to shell out lots of money for the XOs for schools.

Technical measures can never decide who, morally, "owns" a computer. 
When software technical measures do try to decide that, it is almost 
always the technically adept and/or the manufacturers who win.  In a 
project for a Free world, I suspect we want to give our best chance to 
anyone who ends up with a computer by any means... It's why I still have 
set an unrestricted boot option on my computer (without access to my 
personal-data encryption password of course - it's in my head) so that 
if someone accidentally ends up with my computer and doesn't return it 
and doesn't figure out how to reinstall an OS on it, the computer won't 
economically go completely to waste... :-)

The cost of taking that stance is that when you remote-access a 
computer, it (more easily)* might be running different software than you 
expected.  Is that so unreasonable?  If you need an Internet-connected 
secured computer, maybe you can put it in your home, or rent one from a 
local company (or friend) who you trust to keep your data safe because 
you know them?

*some options:
- Lock down not very much at all: Let anyone boot a CD, or even log in 
directly as root, or at least replace your hard drive.  Allowing only 
the former probably makes you safer from someone lazy grabbing your 
computer out of your hands and deleting your files in a stroke of anger; 
adding some time/practicality delay that's still much less than the 
nuisance of replacing hardware can be an okay compromise.
- Lock down via open chain of trust: Coreboot, and so forth, verifying 
signatures.  Booting a CD, and removing/modifying/replacing your hard 
drive, neither will allow the computer to boot something different. 
Different software can happen if "attacker" figured out how to 
physically replace your BIOS.  This is claiming ownership of your 
computer for as long as it remains your computer (or until someone 
steals your personal passwords or personal crypto-keys).  It's open 
design, but it's worth noticing that by choosing even this, you are 
still trying to using technical measures to decide who owns a 
computer... it just gets less 1984-esque when someone does decide to 
replace your computer's BIOS (they can use a standard chip rather than a 
horrible hack discovered by black hats)... This choice might be a good 
one to use in airplane cockpits.
- Lock down via proprietary crypto chip (TPM).  Different software can 
happen if "attacker" figured out how to break into your TPM, which is 
actually quite possibly easier, not harder, than replacing hardware 
because the TPMs are closed systems that don't disclose their design and 
flaws... This option is not safe from TPM manufacturers even if it does 
*seem* convenient and secure (considering how many PCs have TPMs these 
days).  This might be okay for airplanes because -Airplane manufacturers 
are big enough to negotiate with TPM manufacturers -Airplane control 
systems had better never function as ordinary computers for ordinary 
people! (-Isolating the risks in a smaller chip might be safer from 
electromagnetic effects; Except that you don't actually get reliability 
that way.  You can make every security measure here, and even TPM remote 
attestation, flawed, as soon as your RAM becomes unpredictable.  Not in 
a convenient way, but it should definitely be possible..)  Also, none of 
the airplane arguments really apply to small, non-life-critical systems. 
  If car manufacturers build PCs into the cars for people's enjoyment, 
the PCs should not be locked down; the critical circuits should use 
separate chips anyway, because it's just better engineering practice not 
to rely on a fast multi-purpose computer when you don't have to.

I think, we need to be activists for open (e.g. Coreboot-based) 
security.  Fewer of its possible scenarios lead to dystopian 
circumstances.  Too many people expect and demand a logical chain of 
security for their computers (I'm not one of them, I don't want to lock 
down my laptop, as above).  I don't know if this chain of security is 
"useful" in an absolute sense, but it is nevertheless part of the 
struggle to make computers more open and understandable, including 
making people understand better the comparative role of TPM.  I believe 
this role is: a very badly implemented form of basically the Coreboot 
chain of things, plus a form of remote attestation that requires you (or 
anyone) to tech-battle the manufacturer to circumvent (or instead of 
battling, maybe you're an agency that can convince manufacturers to give 
you a backdoor. Money and slimy promises are good tools for this.).  I'm 
not sure, I might be missing something here -- what are you thinking 
about it?

-Isaac

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

> Technical measures can never decide who, morally, "owns" a computer.
I agree. Anyone who can open the computer can make it do whatever he
wants too. It's possible to increase the cost of such operations by
all kind of obfuscation schemes. If a cost to make a laptop behave for
the thief is bigger than the cost of the laptop noone will steal one.
To achieve this some kind of hardware secret (which needs to be
figured out for operating laptop) or watermarking (or visible
engravings) should be enough, no need for TPM. The last one in this
case is actually of no use - it can replaced with a new chip.
All the software can protect is the data. Just encrypt your data with
your password. Some people say "with TPM I don't need to enter my
password". If you don't want to, buy a small USB stick and put the key
on it and attach it on your keychain. This way you keep the key and
not TPM manufacturer.
> It's why I still have set an unrestricted boot
> option on my computer (without access to my personal-data encryption
> password of course - it's in my head)
I made the same decision.
> *some options:
> - Lock down not very much at all: Let anyone boot a CD, or even log in
> directly as root, or at least replace your hard drive.  Allowing only the
> former probably makes you safer from someone lazy grabbing your computer out
> of your hands and deleting your files in a stroke of anger; adding some
> time/practicality delay that's still much less than the nuisance of
> replacing hardware can be an okay compromise.

Someone who wants your data to be gone would just destroy the HD.

I mostly agree with the rest of the mail just there is an additional
usecase which is remote booting
> - Lock down via open chain of trust: Coreboot, and so forth, verifying
> signatures.  Booting a CD, and removing/modifying/replacing your hard drive,
> neither will allow the computer to boot something different. Different
> software can happen if "attacker" figured out how to physically replace your
> BIOS.  This is claiming ownership of your computer for as long as it remains
> your computer (or until someone steals your personal passwords or personal
> crypto-keys).  It's open design, but it's worth noticing that by choosing
> even this, you are still trying to using technical measures to decide who
> owns a computer... it just gets less 1984-esque when someone does decide to
> replace your computer's BIOS (they can use a standard chip rather than a
> horrible hack discovered by black hats)... This choice might be a good one
> to use in airplane cockpits.
> - Lock down via proprietary crypto chip (TPM).  Different software can
> happen if "attacker" figured out how to break into your TPM, which is
> actually quite possibly easier, not harder, than replacing hardware because
> the TPMs are closed systems that don't disclose their design and flaws...
> This option is not safe from TPM manufacturers even if it does *seem*
> convenient and secure (considering how many PCs have TPMs these days).  This
> might be okay for airplanes because -Airplane manufacturers are big enough
> to negotiate with TPM manufacturers -Airplane control systems had better
> never function as ordinary computers for ordinary people! (-Isolating the
> risks in a smaller chip might be safer from electromagnetic effects; Except
> that you don't actually get reliability that way.  You can make every
> security measure here, and even TPM remote attestation, flawed, as soon as
> your RAM becomes unpredictable.  Not in a convenient way, but it should
> definitely be possible..)  Also, none of the airplane arguments really apply
> to small, non-life-critical systems.  If car manufacturers build PCs into
> the cars for people's enjoyment, the PCs should not be locked down; the
> critical circuits should use separate chips anyway, because it's just better
> engineering practice not to rely on a fast multi-purpose computer when you
> don't have to.
>
> I think, we need to be activists for open (e.g. Coreboot-based) security.
>  Fewer of its possible scenarios lead to dystopian circumstances.  Too many
> people expect and demand a logical chain of security for their computers
> (I'm not one of them, I don't want to lock down my laptop, as above).  I
> don't know if this chain of security is "useful" in an absolute sense, but
> it is nevertheless part of the struggle to make computers more open and
> understandable, including making people understand better the comparative
> role of TPM.  I believe this role is: a very badly implemented form of
> basically the Coreboot chain of things, plus a form of remote attestation
> that requires you (or anyone) to tech-battle the manufacturer to circumvent
> (or instead of battling, maybe you're an agency that can convince
> manufacturers to give you a backdoor. Money and slimy promises are good
> tools for this.).  I'm not sure, I might be missing something here -- what
> are you thinking about it?
>
> -Isaac
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Isaac Dupree a écrit :
> Suppose you are the proud technical support person at a third-world
> school that just bought a thousand OLPC XOs.  You, as part of your
> country's government, are instructed to own those XOs.  If they are
> stolen and get into the hands of innocent third-world civilians who want
> a computer, those computers are instructed to shut off within 24 hours
> and demand to be returned to their original location before they're
> willing to work again.  This harms ordinary users who loved their
> student computer; they might choose not to return it anyway.  It does
> not harm the thieves who steal the XOs and break them down into parts
> and sell the parts.  Civilians with enough expertise might be able to
> replace the BIOS flash to get a working computer again, but there will
> be many ordinary users who can't figure out how to do this (or perhaps,
> don't have the tools). This restriction is not necessarily what makes
> OLPC designers happy, it is merely a condition set by many governments
> who decided to shell out lots of money for the XOs for schools.
> 
I don't see the link with TPM. oO

> Technical measures can never decide who, morally, "owns" a computer.
> When software technical measures do try to decide that, it is almost
> always the technically adept and/or the manufacturers who win.  In a
> project for a Free world, I suspect we want to give our best chance to
> anyone who ends up with a computer by any means... It's why I still have
> set an unrestricted boot option on my computer (without access to my
> personal-data encryption password of course - it's in my head) so that
> if someone accidentally ends up with my computer and doesn't return it
> and doesn't figure out how to reinstall an OS on it, the computer won't
> economically go completely to waste... :-)
> 
I completly agree with this. However, in my world, I have a lot people
that loves jokes, so I ended up with some protections ;)

> The cost of taking that stance is that when you remote-access a
> computer, it (more easily)* might be running different software than you
> expected.  Is that so unreasonable?  If you need an Internet-connected
> secured computer, maybe you can put it in your home, or rent one from a
> local company (or friend) who you trust to keep your data safe because
> you know them?
> 
Hey, that's the point. Can you trust your computer? Can you trust the
software on your computer? Can you trust the hardware on your computer?
Can you trust the local company whom you rented a computer from (or
perhpas your closest cyber-café ... where in France they have to log
everything for anti-terrorism counter-measure ...)?

> *some options:
> - Lock down not very much at all: Let anyone boot a CD, or even log in
> directly as root, or at least replace your hard drive.  Allowing only
> the former probably makes you safer from someone lazy grabbing your
> computer out of your hands and deleting your files in a stroke of anger;
> adding some time/practicality delay that's still much less than the
> nuisance of replacing hardware can be an okay compromise.
I can imagine a world with computers you can access from free and from
whom you can boot with your USB pen-drive (or trust the installed OS, or
whatever you want). But this world is still far away from here ... :|

> - Lock down via open chain of trust: Coreboot, and so forth, verifying
> signatures.  Booting a CD, and removing/modifying/replacing your hard
> drive, neither will allow the computer to boot something different.
> Different software can happen if "attacker" figured out how to
> physically replace your BIOS.  This is claiming ownership of your
> computer for as long as it remains your computer (or until someone
> steals your personal passwords or personal crypto-keys).  It's open
> design, but it's worth noticing that by choosing even this, you are
> still trying to using technical measures to decide who owns a
> computer... it just gets less 1984-esque when someone does decide to
> replace your computer's BIOS (they can use a standard chip rather than a
> horrible hack discovered by black hats)... This choice might be a good
> one to use in airplane cockpits.
No! No! No! and No! Coreboot is not an CRTM, and then you can't speak
about chain of trust if you are starting it with Coreboot ... It is
already very difficult to consider the TPM as a CRTM since there are
design flaws.
Also, you are not owning a computer by using a chain of trust. You are
only sure that the software you trust on your computer haven't been
tampered. And you can keep trusting them, even if they have a backdoor
you weren't aware of! ;)

> - Lock down via proprietary crypto chip (TPM).  Different software can
> happen if "attacker" figured out how to break into your TPM, which is
> actually quite possibly easier, not harder, than replacing hardware
> because the TPMs are closed systems that don't disclose their design and
> flaws...
Wow! Software hacked TPM? Software breaking into TPM? I must be missing
something. :|
Every technology has its design and its implementation, and also its
design flaws and implementation flaws. Remember Debian and OpenSSL.
Well, if a chip has a design flaw, it is more expensive to change it;
however, people that will truly require it will also be able to. ;)

> This option is not safe from TPM manufacturers even if it does
> *seem* convenient and secure (considering how many PCs have TPMs these
> days).  This might be okay for airplanes because -Airplane manufacturers
> are big enough to negotiate with TPM manufacturers -Airplane control
> systems had better never function as ordinary computers for ordinary
> people! (-Isolating the risks in a smaller chip might be safer from
> electromagnetic effects; Except that you don't actually get reliability
> that way.  You can make every security measure here, and even TPM remote
> attestation, flawed, as soon as your RAM becomes unpredictable.  Not in
> a convenient way, but it should definitely be possible..)  Also, none of
> the airplane arguments really apply to small, non-life-critical systems.
Airplane manufacter aren't using ordinary computer ...
>  If car manufacturers build PCs into the cars for people's enjoyment,
> the PCs should not be locked down; the critical circuits should use
> separate chips anyway, because it's just better engineering practice not
> to rely on a fast multi-purpose computer when you don't have to.
... nor does car manufacturer.
> 

> I think, we need to be activists for open (e.g. Coreboot-based)
> security.  Fewer of its possible scenarios lead to dystopian
> circumstances.  Too many people expect and demand a logical chain of
> security for their computers (I'm not one of them, I don't want to lock
> down my laptop, as above).  I don't know if this chain of security is
> "useful" in an absolute sense, but it is nevertheless part of the
> struggle to make computers more open and understandable, including
> making people understand better the comparative role of TPM.  I believe
> this role is: a very badly implemented form of basically the Coreboot
> chain of things, plus a form of remote attestation that requires you (or
> anyone) to tech-battle the manufacturer to circumvent (or instead of
> battling, maybe you're an agency that can convince manufacturers to give
> you a backdoor. Money and slimy promises are good tools for this.).  I'm
> not sure, I might be missing something here -- what are you thinking
> about it?
> 
This chain of trust is useful for people that have to work with a
computer and data in an untrusted environnement, and that's how and what
it was designed for. Basically, the computer says "trust me", but now
you know you can trust it (well, "trust" is very difficult, does anyone
truly trust the microcode in your ethernet daughter-board?)

> -Isaac
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMNXYACgkQBV7eXqefhqgtcQCfU0LjjyTGKg1KlPDwLrSYd4+x
5wMAoKCKAGCmF4+A0z8zcNYuDhuiaxwD
=tGsI
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Isaac Dupree]

Duboucher Thomas wrote:
> Also, you are not owning a computer by using a chain of trust. You are
> only sure that the software you trust on your computer haven't been
> tampered. And you can keep trusting them, even if they have a backdoor
> you weren't aware of! ;)

well it's true, even with the most open computer-hardware-design by 
manufacturers, you won't get anything as well-tested and understood and 
obviously trustworthy as 18/8 stainless steel (I was just thinking of an 
analogy to Klean Kanteen, who advertise how their 18/8 stainless steel 
water bottles are obviously safer than plastics, or than aluminium + 
secret-formula-enamel , http://www.kleankanteen.com/faqs/faqs.html )

-Isaac

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

> I can imagine a world with computers you can access from free and from
> whom you can boot with your USB pen-drive (or trust the installed OS, or
> whatever you want). But this world is still far away from here ... :|
TPM doesn't protect your computer from being stolen and HD wiped.
>> replace your computer's BIOS (they can use a standard chip rather than a
>> horrible hack discovered by black hats)... This choice might be a good
>> one to use in airplane cockpits.
> No! No! No! and No! Coreboot is not an CRTM, and then you can't speak
> about chain of trust if you are starting it with Coreboot ... It is
> already very difficult to consider the TPM as a CRTM since there are
> design flaws.
Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes!
Yes! Yes! Yes! Yes!
Coreboot is perfect for my use for *****.
Did I bring any argument in last 2 lines?
> Also, you are not owning a computer by using a chain of trust. You are
> only sure that the software you trust on your computer haven't been
> tampered. And you can keep trusting them, even if they have a backdoor
> you weren't aware of! ;)
>
That's what open source is here for. You just said it yourself that
you can easier trust open source than closed source and TPM doesn't
change that.

>> - Lock down via proprietary crypto chip (TPM).  Different software can
>> happen if "attacker" figured out how to break into your TPM, which is
>> actually quite possibly easier, not harder, than replacing hardware
>> because the TPMs are closed systems that don't disclose their design and
>> flaws...
> Wow! Software hacked TPM? Software breaking into TPM? I must be missing
> something. :|
It's possible that using some kind of obscure power control sequence
you can reset tpm to its boot state and then nicely ask it to do
whatever you want.
> Every technology has its design and its implementation, and also its
> design flaws and implementation flaws. Remember Debian and OpenSSL.
> Well, if a chip has a design flaw, it is more expensive to change it;
> however, people that will truly require it will also be able to. ;)
>
TPM claims to e.g. protect your hd encryption keys. But what a hacker
would do is to boot computer, wait that it retrieves the keys and then
execute cold boot attack (in most cases it's enough to just cool RAM
down and reboot with a USB key which will dump the memory). I don't
spend my time on implementing a "security" which increases hacking
cost by $15, claims to be unbreakable and can be used for evil
purposes (in which case it's more difficult to crack)
>> attestation, flawed, as soon as your RAM becomes unpredictable.  Not in
>> a convenient way, but it should definitely be possible..)  Also, none of
>> the airplane arguments really apply to small, non-life-critical systems.
> Airplane manufacter aren't using ordinary computer ...
So what?
Example stays an interesting one and their computers probably have
some kind of protection.
> This chain of trust is useful for people that have to work with a
> computer and data in an untrusted environnement, and that's how and what
> it was designed for.
Then this design is fundamentaly flawed. You just can't trust hardware
in untrusted environment.
Claiming to achieve impossible is an advantage proprietary security
suites have over free ones.

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
>> I can imagine a world with computers you can access from free and from
>> whom you can boot with your USB pen-drive (or trust the installed OS, or
>> whatever you want). But this world is still far away from here ... :|
> TPM doesn't protect your computer from being stolen and HD wiped.

Hey, I didn't say that TPM will replace a faithful dog! :D

>> No! No! No! and No! Coreboot is not an CRTM, and then you can't speak
>> about chain of trust if you are starting it with Coreboot ... It is
>> already very difficult to consider the TPM as a CRTM since there are
>> design flaws.
> Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes! Yes!
> Yes! Yes! Yes! Yes!
> Coreboot is perfect for my use for *****.
> Did I bring any argument in last 2 lines?

Since the BIOS can be "easily" replaced, it cannot be trusted, hence you
can't build a chain of trust starting from your BIOS. It is a "little"
more difficult to replace a TPM, even more if it's holding a shared
secret. :)

>> Also, you are not owning a computer by using a chain of trust. You are
>> only sure that the software you trust on your computer haven't been
>> tampered. And you can keep trusting them, even if they have a backdoor
>> you weren't aware of! ;)
>>
> That's what open source is here for. You just said it yourself that
> you can easier trust open source than closed source and TPM doesn't
> change that.
> 
I completly agree with the first part, but you twisted the ending. :'(
I trust an open-source software, because I can see the source code (uh,
wait! what if I can't trust the compiler!). I keep trusting it because
the TPM tells me it hasn't been altered on my computer by nasty people.

>>> - Lock down via proprietary crypto chip (TPM).  Different software can
>>> happen if "attacker" figured out how to break into your TPM, which is
>>> actually quite possibly easier, not harder, than replacing hardware
>>> because the TPMs are closed systems that don't disclose their design and
>>> flaws...
>> Wow! Software hacked TPM? Software breaking into TPM? I must be missing
>> something. :|
> It's possible that using some kind of obscure power control sequence
> you can reset tpm to its boot state and then nicely ask it to do
> whatever you want.

Well, that would be a design flaw, and not very TCG compliant. Things
like this happen, and when it does, it's always a little problematic in
cryptographics.

>> Every technology has its design and its implementation, and also its
>> design flaws and implementation flaws. Remember Debian and OpenSSL.
>> Well, if a chip has a design flaw, it is more expensive to change it;
>> however, people that will truly require it will also be able to. ;)
>>
> TPM claims to e.g. protect your hd encryption keys. But what a hacker
> would do is to boot computer, wait that it retrieves the keys and then
> execute cold boot attack (in most cases it's enough to just cool RAM
> down and reboot with a USB key which will dump the memory). I don't
> spend my time on implementing a "security" which increases hacking
> cost by $15, claims to be unbreakable and can be used for evil
> purposes (in which case it's more difficult to crack)

Uh, wait! There's something I don't understand there. What's the point
in puting the whole secret in the TPM? It's like writing your passphrase
on a paper and put it under your keyboard. A clever implementation would
be using the ownership capabilities of the TPM so that the secret can be
protected by system integrity _and_ password.

>>> attestation, flawed, as soon as your RAM becomes unpredictable.  Not in
>>> a convenient way, but it should definitely be possible..)  Also, none of
>>> the airplane arguments really apply to small, non-life-critical systems.
>> Airplane manufacter aren't using ordinary computer ...
> So what?
> Example stays an interesting one and their computers probably have
> some kind of protection.

Well, I think there's computer onboard, and I think they may have some
security, but personnaly I've never worked in a department that produces
planes. This would be only pure speculations.

>> This chain of trust is useful for people that have to work with a
>> computer and data in an untrusted environnement, and that's how and what
>> it was designed for.
> Then this design is fundamentaly flawed. You just can't trust hardware
> in untrusted environment.

This is what the TCPA is trying to solve. Not an easy question, but TPM
is a good begining imho (invalid the Stoned attack scheme for example)

> Claiming to achieve impossible is an advantage proprietary security
> suites have over free ones.
> 

Yup ;)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMRkUACgkQBV7eXqefhqjZXgCgmGik1TszdBP3tJDlWHFkDhuS
4ooAoJA7CmS+TR0Mv7UHuOJi4mBxBhtT
=Qqm3
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

> Since the BIOS can be "easily" replaced, it cannot be trusted, hence you
> can't build a chain of trust starting from your BIOS. It is a "little"
> more difficult to replace a TPM, even more if it's holding a shared
> secret. :)
Write wire? Concrete around the chip? Concrete is more resistant than
silicon as last studies have shown.
>>
> I completly agree with the first part, but you twisted the ending. :'(
> I trust an open-source software, because I can see the source code (uh,
> wait! what if I can't trust the compiler!).
It's a known attack (and there are ways to detect it).
> I keep trusting it because
> the TPM tells me it hasn't been altered on my computer by nasty people.
>
Suppose even that TPM or XYZ can ensure software isn't tampered at
all. Attacker can alter your hardware instead. It just changes the way
your computer is attacked, not the result. As a matter of fact
hardware attacks are now more widespread in these considerations.
>> TPM claims to e.g. protect your hd encryption keys. But what a hacker
>> would do is to boot computer, wait that it retrieves the keys and then
>> execute cold boot attack (in most cases it's enough to just cool RAM
>> down and reboot with a USB key which will dump the memory). I don't
>> spend my time on implementing a "security" which increases hacking
>> cost by $15, claims to be unbreakable and can be used for evil
>> purposes (in which case it's more difficult to crack)
>
> Uh, wait! There's something I don't understand there. What's the point
> in puting the whole secret in the TPM? It's like writing your passphrase
> on a paper and put it under your keyboard. A clever implementation would
> be using the ownership capabilities of the TPM so that the secret can be
> protected by system integrity _and_ password.
Then I wait that you enter you password and leave machine unattended
and execute my cold boot attack. If you never left machine unattended
you don't need a chip to ensure the integrity.
>>> This chain of trust is useful for people that have to work with a
>>> computer and data in an untrusted environnement, and that's how and what
>>> it was designed for.
>> Then this design is fundamentaly flawed. You just can't trust hardware
>> in untrusted environment.
>
> This is what the TCPA is trying to solve. Not an easy question, but TPM
> is a good begining imho (invalid the Stoned attack scheme for example)
>
When they provide a way to do so I would like to look at it. The only
way I'm aware of is to put computer in 10^n tones (n being a security
parameter) of concrete but it's pretty much a "safe" environment. Till
they don't I consider it a non-security. And even if they do freedom
concerns remain.


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wed, Aug 19, 2009 at 08:48:13PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> Since the BIOS can be "easily" replaced, it cannot be trusted, hence you
>> can't build a chain of trust starting from your BIOS. It is a "little"
>> more difficult to replace a TPM, even more if it's holding a shared
>> secret. :)
>Write wire? Concrete around the chip? Concrete is more resistant than
>silicon as last studies have shown.

99% of people with this use case are not going to put their BIOS chip in 
concrete. Configuring a TPM chip a lot easier.

>> I keep trusting it because
>> the TPM tells me it hasn't been altered on my computer by nasty people.
>>
>Suppose even that TPM or XYZ can ensure software isn't tampered at
>all. Attacker can alter your hardware instead. It just changes the way
>your computer is attacked, not the result. As a matter of fact
>hardware attacks are now more widespread in these considerations.

Yes -- the whole point is to make it more difficult and require more 
resources.

>>> TPM claims to e.g. protect your hd encryption keys. But what a hacker
>>> would do is to boot computer, wait that it retrieves the keys and then
>>> execute cold boot attack (in most cases it's enough to just cool RAM
>>> down and reboot with a USB key which will dump the memory). I don't
>>> spend my time on implementing a "security" which increases hacking
>>> cost by $15, claims to be unbreakable and can be used for evil
>>> purposes (in which case it's more difficult to crack)
>>
>> Uh, wait! There's something I don't understand there. What's the point
>> in puting the whole secret in the TPM? It's like writing your passphrase
>> on a paper and put it under your keyboard. A clever implementation would
>> be using the ownership capabilities of the TPM so that the secret can be
>> protected by system integrity _and_ password.
>Then I wait that you enter you password and leave machine unattended
>and execute my cold boot attack. If you never left machine unattended
>you don't need a chip to ensure the integrity.

That's a completely different issue which you don't have a solution to 
either.

-- http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>
> 99% of people with this use case are not going to put their BIOS chip in
> concrete. Configuring a TPM chip a lot easier.
>
98% of people in this case don't really care if they are secure or not.
>>> I keep trusting it because
>>> the TPM tells me it hasn't been altered on my computer by nasty people.
>>>
>> Suppose even that TPM or XYZ can ensure software isn't tampered at
>> all. Attacker can alter your hardware instead. It just changes the way
>> your computer is attacked, not the result. As a matter of fact
>> hardware attacks are now more widespread in these considerations.
>
> Yes -- the whole point is to make it more difficult and require more
> resources.
What ressources do you suppose your attacker have?
>> Then I wait that you enter you password and leave machine unattended
>> and execute my cold boot attack. If you never left machine unattended
>> you don't need a chip to ensure the integrity.
>
> That's a completely different issue which you don't have a solution to
> either.
>
And which makes all the hassle around TPM worth nothing


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wednesday 19 August 2009 22:25:00 Vladimir 'phcoder' Serbinenko wrote:
> > 99% of people with this use case are not going to put their BIOS chip in
> > concrete. Configuring a TPM chip a lot easier.
>
> 98% of people in this case don't really care if they are secure or not.

I said "with this use case".

> >> Then I wait that you enter you password and leave machine unattended
> >> and execute my cold boot attack. If you never left machine unattended
> >> you don't need a chip to ensure the integrity.
> >
> > That's a completely different issue which you don't have a solution to
> > either.
>
> And which makes all the hassle around TPM worth nothing

Cold boot attacks can be mitigated somewhat because the BIOS would be 
configured to only boot from the harddrive. The BIOS would have to be reset 
before booting from another device, but this would break the trusted path 
which means that it has to happen during the attack itself.

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 20, 2009 at 9:38 AM, Michael Gorven<michael@gorven.za.net> wrote:
> On Wednesday 19 August 2009 22:25:00 Vladimir 'phcoder' Serbinenko wrote:
>> > 99% of people with this use case are not going to put their BIOS chip in
>> > concrete. Configuring a TPM chip a lot easier.
>>
>> 98% of people in this case don't really care if they are secure or not.
>
> I said "with this use case".
It's also what I meant. Most sysadmins just need someone to blame if
it goes wrong.
>
>> >> Then I wait that you enter you password and leave machine unattended
>> >> and execute my cold boot attack. If you never left machine unattended
>> >> you don't need a chip to ensure the integrity.
>> >
>> > That's a completely different issue which you don't have a solution to
>> > either.
>>
>> And which makes all the hassle around TPM worth nothing
>
> Cold boot attacks can be mitigated somewhat because the BIOS would be
> configured to only boot from the harddrive. The BIOS would have to be reset
> before booting from another device, but this would break the trusted path
> which means that it has to happen during the attack itself.
It just means one needs to move memory to another computer.
>
> Michael
>
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Thursday 20 August 2009 12:15:42 Vladimir 'phcoder' Serbinenko wrote:
> On Thu, Aug 20, 2009 at 9:38 AM, Michael Gorven<michael@gorven.za.net> 
wrote:
> > On Wednesday 19 August 2009 22:25:00 Vladimir 'phcoder' Serbinenko wrote:
> >> > 99% of people with this use case are not going to put their BIOS chip
> >> > in concrete. Configuring a TPM chip a lot easier.
> >>
> >> 98% of people in this case don't really care if they are secure or not.
> >
> > I said "with this use case".
>
> It's also what I meant. Most sysadmins just need someone to blame if
> it goes wrong.

Oh great, so all we need to provide is someone to blame! Problem solved!

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>>
>> It's also what I meant. Most sysadmins just need someone to blame if
>> it goes wrong.
>
> Oh great, so all we need to provide is someone to blame! Problem solved!
Unfortunately in some cases it's really so. Sometimes it leads to
sysadmins choosing proprietary software not because they believe in
its security but because if something goes wrong they have someone to
sue.

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
>>> It's also what I meant. Most sysadmins just need someone to blame if
>>> it goes wrong.
>> Oh great, so all we need to provide is someone to blame! Problem solved!
> Unfortunately in some cases it's really so. Sometimes it leads to
> sysadmins choosing proprietary software not because they believe in
> its security but because if something goes wrong they have someone to
> sue.
> 

Well, when companies have hundreds of millions of euros in play, they do
not want them to be protected by softwares without warranties ...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqNe6cACgkQBV7eXqefhqjr2wCgjWiMeAzGqDVibpFrv9MPEYhY
hYwAoKc/FxYU+cL0sQFnnm63p1MyrEaj
=KpdO
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Michael Gorven]

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

On Wed, Aug 19, 2009 at 08:01:06PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> I can imagine a world with computers you can access from free and from
>> whom you can boot with your USB pen-drive (or trust the installed OS, or
>> whatever you want). But this world is still far away from here ... :|
>TPM doesn't protect your computer from being stolen and HD wiped.

No it doesn't, and that's not what I'm trying to avoid.

>> Also, you are not owning a computer by using a chain of trust. You 
>> are
>> only sure that the software you trust on your computer haven't been
>> tampered. And you can keep trusting them, even if they have a backdoor
>> you weren't aware of! ;)
>>
>That's what open source is here for. You just said it yourself that
>you can easier trust open source than closed source and TPM doesn't
>change that.

So make an open hardware TPM chip.

>>> - Lock down via proprietary crypto chip (TPM).  Different software can
>>> happen if "attacker" figured out how to break into your TPM, which is
>>> actually quite possibly easier, not harder, than replacing hardware
>>> because the TPMs are closed systems that don't disclose their design and
>>> flaws...
>> Wow! Software hacked TPM? Software breaking into TPM? I must be missing
>> something. :|
>It's possible that using some kind of obscure power control sequence
>you can reset tpm to its boot state and then nicely ask it to do
>whatever you want.

Yes, and then the decryption key is gone and my data is safe.

>> Every technology has its design and its implementation, and also its
>> design flaws and implementation flaws. Remember Debian and OpenSSL.
>> Well, if a chip has a design flaw, it is more expensive to change it;
>> however, people that will truly require it will also be able to. ;)
>>
>TPM claims to e.g. protect your hd encryption keys. But what a hacker
>would do is to boot computer, wait that it retrieves the keys and then
>execute cold boot attack (in most cases it's enough to just cool RAM
>down and reboot with a USB key which will dump the memory). I don't
>spend my time on implementing a "security" which increases hacking
>cost by $15, claims to be unbreakable and can be used for evil
>purposes (in which case it's more difficult to crack)

It's still more secure than your solutions.

>> This chain of trust is useful for people that have to work with a
>> computer and data in an untrusted environnement, and that's how and what
>> it was designed for.
>Then this design is fundamentaly flawed. You just can't trust hardware
>in untrusted environment.
>Claiming to achieve impossible is an advantage proprietary security
>suites have over free ones.

Yes it's impossible, but TPM moves it a lot closer.

-- 
http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>>>> - Lock down via proprietary crypto chip (TPM).  Different software can
>>>> happen if "attacker" figured out how to break into your TPM, which is
>>>> actually quite possibly easier, not harder, than replacing hardware
>>>> because the TPMs are closed systems that don't disclose their design and
>>>> flaws...
>>>
>>> Wow! Software hacked TPM? Software breaking into TPM? I must be missing
>>> something. :|
>>
>> It's possible that using some kind of obscure power control sequence
>> you can reset tpm to its boot state and then nicely ask it to do
>> whatever you want.
>
> Yes, and then the decryption key is gone and my data is safe.
Reset tpm to boot state means put it in the state as it is on boot.
Not "wipe TPM"
>
> It's still more secure than your solutions.
Not a lot.
>
>>> This chain of trust is useful for people that have to work with a
>>> computer and data in an untrusted environnement, and that's how and what
>>> it was designed for.
>>
>> Then this design is fundamentaly flawed. You just can't trust hardware
>> in untrusted environment.
>> Claiming to achieve impossible is an advantage proprietary security
>> suites have over free ones.
>
> Yes it's impossible, but TPM moves it a lot closer.
>
infinity-$15=infinity
> --
> http://michael.gorven.za.net/
> PGP Key ID 6612FE85
> S/MIME Key ID AAF09E0E
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBAgAGBQJKjFqlAAoJEIOxIz1l+Omh4F4QAIv+bH8dG5BHanHwm9HyBGF+
> 3golKVb+E3t0bDb/vzgLCMnRSkRvGpV6g2dMy3dUIom/Gima5AkLfixcaK1YYecv
> yFiHroIp3T+NhfBICfVYleAlKu9ri5fuoJzyONx5Uwhmo/fHdZYApvIm34dXJf0D
> 4V+z74OL/AHOZpc5HWoimvoO3p30nbBMALVKoH5du9vKtnRsL9uypqCBhP9tKe+L
> j2JdY5ZLZaAFMOCgnrkZ7kS1s6gQ74LD0kYRgW9idvdvRkH4t6vqqf8PRVLKAJJQ
> q/dL6WfLjlfkWwdH0HFOn4m7zvIvX3d5qTUrToSOgAJXuSWpW4vDlLwldepjlyfF
> 72pYDbFWHg3cMjQ46oQebCbA5dDogfQ+uNVh/8jwHzXr7rCArhpVwNBmuwIw3k9v
> hwljr4lsLtjg+8x0km3zGo7dS7vkStjVslPCp/XRz/3QwSYJETWZgwvGUAlxmIw0
> V5Ju7qxAKB3AowCe7RpLIy95LpRnjRmJZjLoVJwkf2BVJNte7yeQhSU6U5N59EEC
> PHlDuxbEWqzYXTmcOTjPu/2vBWdPysIUC7RpkisB592SJ8Zkr4iZtGEg/xmWWDLT
> wu9DphdcDaE62ePFlfouedOoDOl1ZUV1dGwuWXND55UJjlgzLEBegR1Sg6qoup3L
> NAjC4pUJowcsfog9vlY5
> =hJYM
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 02:25:21PM +0200, Michael Gorven wrote:
> On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
> > 1) Making use of TPM you become dependent on good will of TPM
> > manufacturer. You can never know if or when the TPM manufacturer or
> > someone connected with them will ask you to use remote attestation to
> > prove them that you use only the software they signed and that they
> > effectively control your computer.
> 
> How are you dependent? If they ask you to use remote attestation then just say 
> no

The trick is, you can't skip a remote attestation test.  Either you prove
you're clean or you're not.  So if you "just say no", what does it mean?

It could mean you can't access your bank account unless you use their
designated non-free browser.

It could mean you can't read a book unless you use their designated non-free
reader (with DRM restrictions, etc).

Since we're going to say no anyway, there's no reason to do it later.  The
longer we wait the stronger they'll be, and the more difficult for us to
reject their unreasonable demands.

> > Why do I as user need someone else to check my computer?
> 
> Because you don't always own or completely control the computer. 

Right, but we're defending the rights of the legitimate owner of that device,
which doesn't have to be the same as the end user (e.g. kiosk).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Michael Gorven]

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

On Wed, Aug 19, 2009 at 04:42:32PM +0200, Robert Millan wrote:
>On Wed, Aug 19, 2009 at 02:25:21PM +0200, Michael Gorven wrote:
>> On Wednesday 19 August 2009 13:51:34 Vladimir 'phcoder' Serbinenko wrote:
>> > 1) Making use of TPM you become dependent on good will of TPM
>> > manufacturer. You can never know if or when the TPM manufacturer or
>> > someone connected with them will ask you to use remote attestation to
>> > prove them that you use only the software they signed and that they
>> > effectively control your computer.
>> 
>> How are you dependent? If they ask you to use remote attestation then just say 
>> no
>
>The trick is, you can't skip a remote attestation test.  Either you prove
>you're clean or you're not.  So if you "just say no", what does it mean?
>
>It could mean you can't access your bank account unless you use their
>designated non-free browser.
>
>It could mean you can't read a book unless you use their designated non-free
>reader (with DRM restrictions, etc).

So use a different bank and a different publisher.

>Since we're going to say no anyway, there's no reason to do it later.  The
>longer we wait the stronger they'll be, and the more difficult for us to
>reject their unreasonable demands.

Because there are valid use cases that aren't about restricting the 
owner's freedom.

>> > Why do I as user need someone else to check my computer?
>> 
>> Because you don't always own or completely control the computer. 
>
>Right, but we're defending the rights of the legitimate owner of that device,
>which doesn't have to be the same as the end user (e.g. kiosk).

I don't see how you're defending the owner's rights. If the owner wants 
to lock down the device then they should be able to.

-- 
http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>> It could mean you can't read a book unless you use their designated
>> non-free
>> reader (with DRM restrictions, etc).
>
> So use a different bank and a different publisher.
How many record labels will not jump on occasion of an efficient DRM?
How many banks will resist the temptation to say "we're more secure
because of TPM"
>
>> Since we're going to say no anyway, there's no reason to do it later.  The
>> longer we wait the stronger they'll be, and the more difficult for us to
>> reject their unreasonable demands.
>
> Because there are valid use cases that aren't about restricting the owner's
> freedom.
Yes but the cost is too high. And few people who really need high
security can afford coreboot motherboard.
>> Right, but we're defending the rights of the legitimate owner of that
>> device,
>> which doesn't have to be the same as the end user (e.g. kiosk).
>
> I don't see how you're defending the owner's rights. If the owner wants to
> lock down the device then they should be able to.
kiosks are physically protected


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wed, Aug 19, 2009 at 10:27:59PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>>> Since we're going to say no anyway, there's no reason to do it 
>>> later.  The
>>> longer we wait the stronger they'll be, and the more difficult for us to
>>> reject their unreasonable demands.
>>
>> Because there are valid use cases that aren't about restricting the owner's
>> freedom.
>Yes but the cost is too high. And few people who really need high
>security can afford coreboot motherboard.

Your coreboot solution isn't really feasible. The flashed BIOS would 
contain a checksum of the bootloader, which means that you can't change 
the bootloader once the BIOS is flashed. Since the bootloader contains a 
checksum of the kernel, you can't change the kernel either.

-- http://michael.gorven.za.net/
PGP Key ID 6612FE85
S/MIME Key ID AAF09E0E

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 10:33 PM, Michael Gorven<michael@gorven.za.net> wrote:
> On Wed, Aug 19, 2009 at 10:27:59PM +0200, Vladimir 'phcoder' Serbinenko
> wrote:
>>>>
>>>> Since we're going to say no anyway, there's no reason to do it later.
>>>>  The
>>>> longer we wait the stronger they'll be, and the more difficult for us to
>>>> reject their unreasonable demands.
>>>
>>> Because there are valid use cases that aren't about restricting the
>>> owner's
>>> freedom.
>>
>> Yes but the cost is too high. And few people who really need high
>> security can afford coreboot motherboard.
>
> Your coreboot solution isn't really feasible. The flashed BIOS would contain
> a checksum of the bootloader, which means that you can't change the
> bootloader once the BIOS is flashed. Since the bootloader contains a
> checksum of the kernel, you can't change the kernel either.
>
Signatures.
> -- http://michael.gorven.za.net/
> PGP Key ID 6612FE85
> S/MIME Key ID AAF09E0E
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQIcBAEBAgAGBQJKjGGgAAoJEIOxIz1l+OmhbikP/RhE5ToVXuBjPxolIbTQVOVM
> 5SbmeCDA8Uu6H0eB4VoISxjJZ5hySObOMuDRjGua2ABfqxfxE8+yQARzbtaBq6tn
> COPWFoc8hMlcq1JptwsM16R+Qe2inM0Lp/Zew6npLVRWHv1ouQUsiRDp3QiWFVwQ
> ao+U+WfG532mDMgDlyPRamflsBxtzmg+Eb0v26OBAzh6T+k5bBAWUmbFo+iKfhp8
> pnb1j0YUxBxuOHsfQBlDytAwRzNoB4u7MP86LFwjoilo+xaCIw/7wLwq8GRfASEX
> gspgrL0vKUErxHGAYSLNkOW/DfUj82GTKO6NXEiqA7b9jMCIdNiz7CanbZQun+qK
> EICT1mB8FmWsqYjJJI+I5f1K12TQJGy/VWAejs9M/JUZA1dCPSF1q0jxtNEOluOO
> O+4+mJ8zzzt22A+p9RbANR34ix/5zG4z4T9erBqt6/+36b8FYNTth7z6S8qksW4V
> rzS76UMhSydNItFfAEgkywWI1TDrGxFcynY9vncdFiOBKFf/vIFbzJdYA1FRL5PT
> j5+0pZ8WbqokjqeLNOXYSOt/kMSRFuA1goL+io3aBMNajire55j+Ff5rKZ1PmamJ
> 8xArEgEMvoLX09FamxQ0BCcB1XPNDBzZ4sby+uTORic+h7YkKMiAkK8Rv78nOHmc
> f3Y/7dZtLqEUSEF9Eq6L
> =T4Gi
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> How many record labels will not jump on occasion of an efficient DRM?

In France, they still believe it takes three days for a .mp3 to travel
from Japan to France ...

> How many banks will resist the temptation to say "we're more secure
> because of TPM"

When it will be more openly used, most of them will with reas

>>> Since we're going to say no anyway, there's no reason to do it later.  The
>>> longer we wait the stronger they'll be, and the more difficult for us to
>>> reject their unreasonable demands.
>> Because there are valid use cases that aren't about restricting the owner's
>> freedom.
> Yes but the cost is too high. And few people who really need high
> security can afford coreboot motherboard.
>>> Right, but we're defending the rights of the legitimate owner of that
>>> device,
>>> which doesn't have to be the same as the end user (e.g. kiosk).
>> I don't see how you're defending the owner's rights. If the owner wants to
>> lock down the device then they should be able to.
> kiosks are physically protected
> 

Another use case can be associating a MTM and a TPM (data exchange
secured between two exclusive devices, i.e. a laptop and a cellphone).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMZE0ACgkQBV7eXqefhqi1oACfXDqR8wz0CYcgwAHU7lZrQB6F
OzEAoIlMbyhAjszQCA223k5jQHS4AxSr
=tqwt
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 10:27:59PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> It could mean you can't read a book unless you use their designated
> >> non-free
> >> reader (with DRM restrictions, etc).
> >
> > So use a different bank and a different publisher.
> How many record labels will not jump on occasion of an efficient DRM?
> How many banks will resist the temptation to say "we're more secure
> because of TPM"

And I forgot to mention tax filings, which may also end up preventing free
software from being used to file taxes.  Likewise for many other tasks that
citizens can't avoid.

So, just move to another state and use a different IRS?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Michael Gorven]

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

On Thursday 20 August 2009 18:09:00 Robert Millan wrote:
> And I forgot to mention tax filings, which may also end up preventing free
> software from being used to file taxes.  Likewise for many other tasks that
> citizens can't avoid.
>
> So, just move to another state and use a different IRS?

Nah, I'd go for a different country :-P

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 10:27:59PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> >> Right, but we're defending the rights of the legitimate owner of that
> >> device,
> >> which doesn't have to be the same as the end user (e.g. kiosk).
> >
> > I don't see how you're defending the owner's rights. If the owner wants to
> > lock down the device then they should be able to.
> kiosks are physically protected

I can lock devices just fine without ressorting to appointing someone else as
manager of my crypto chain.

TPM itself does *nothing* to lock down devices.  If using a TPM for this
purpose is more convenient, that's only because of artificial reasons.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 01:00:43PM +0200, Emmanuel Fleury wrote:
> Dear all,
> 
> I know this is a quite sensitive topic and I'm really not willing to
> start a new flame-war about it. I just want to know the exact status of
> it and what is the (official) position of the GRUB team on the TPM support.
> 
> Last discussion about the TPM issue was in February (see:
> http://lists.gnu.org/archive/html/grub-devel/2009-02/msg00217.html) and
> it ended up with a kind of statu quo.
> 
> I just propose to expose the consequences of TPM support for GRUB, first
> in a technical point of view and then on an ethical one. Then, I hope
> the GRUB team will write his official position on the TPM support.

Hi,

This is my official position on TPM support:

GRUB is part of the GNU project.  This means we follow the same ultimate
goal, that is, enabling all computer users to enjoy the freedoms they
should have when using computer programs in them.

"TPM" is a device that is part of the "Trusted Computing" initiative.  However,
referring to this as "Trusted" is misleading.  As owner of your computer, you
are *already* able to trust your computer.  The difference with "Trusted
Computing" is not on whether it's trusted, but on *who* can trust it:  Someone
else can trust your computer, at the expense that it won't always obbey your
orders anymore.

Because of this, we avoid referring to it as "Trusted" and use "Treacherous"
instead.

As you can see, the purpose of TPMs is fundamentally incompatible with our
goal.  It would be foolish for us to support them.

From a technical perspective, a TPM is not so different from a similar device
that we would consider legitimate: one that doesn't prevent the owner from
obtaining the private key of his own chip, or at least from using it to sign
arbitrary data.  Unless a clearly distinct name was used, this would still
have the inconvenient that we would be promoting the mallicious version if
we supported it, but since this theoretical device doesn't exist anyway, it's
pointless to argue about it.  TPMs as they exist today are not acceptable.

That said, remember that GRUB is free software, and you can modify it to
implement any feature (including mallicious ones like virus, spyware or
DRM), as long as you comply with the license requirements in the GPL.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> 1) Technical Aspects
> ====================
> 
>>From a purely technical point of view, the TPM support in GRUB is about
> the "Trusted Boot" with a partial support and a full one.
> 
> Partial support means that GRUB is able to (TPM commands are taken from
> "Part 3 - Commands", see further for references):
> 
> 1) Perform a SHA-1 digest (TPM_SHA1Start and TPM_SHA1Update commands) of
> the kernel that is intended to be loaded.
> 
> 2) Extend the PCR register (TPM_SHA1CompleteExtend command) with the
> SHA-1 digest.
> 
I advise you to read the documents named "PC Client Implementation for
BIOS" and "TCG EFI Protocol Specification" which defines how these
functions are to be implemented on an IBM/PC compatible hardware that
supports the TCG specifications. ;)
All of the functions defined there can be easily made using functions in
the BIOS or EFI (i.e. BIOS INT TCG_CompactHashLogExtendEvent). You can
also have a look at the Trusted Grub and/or Grub IMA project for an
insight with an older TCG specification.

> 3) Read the PCR (TPM_PCRRead command) and compare it to a recorded value
> of a previous (safe) boot. We assume that the previous link of the chain
> of trust (BIOS?) has already checked that GRUB hasn't been tampered
> before starting it.
> 
No, no, no and no! :)
This is a typical hen/egg problem: If you compare the PCR value with a
previously reccorded value, then this value must be part of the chain of
trust (if not, then you have no chain of trust and your TPM is useless);
If it is part of the chain of trust, it must be measured into one of the
PCR and it will modifiy the PCR values.
Try to think about a file that stores its own md5 sum, it'll give you a
headache.

> If this part fail, GRUB should stop here and tell the user that the
> kernel has been tampered. If everything went ok, GRUB get back to the
> usual way...
> 
True, but the TPM doesn't only check the kernel, it also works when
someone changed the MBR for instance (or less trivial, a PCI ROM).

> A full support of TPM means that GRUB should also be able to ask to a
> remote authority if the content of the PCR is still ok... Technically,
> it would be stupid to include a full TCP/IP stack (or whatever network
> protocol) into GRUB, so it would be much more realistic to just leave it
> to the OS and only pass the needed data to it.
> 
I've found no public implementation of remote authentication using TPM,
except from a proof of concept that makes use of a Java-based servlet.

> [Note: I have to admit that I don't see how to deal properly with this
> full support as you somehow need to rely on some links of the chain of
> trust that may have been tampered. Implementing this step may require
> quite a lot of thinking (and personally, I don't think it worth it...
> but it's only my humble opinion).]
> 
You can achieve this using TPM_Quote iirc, but I haven't studied this.
However, this is a very specific support for very specific applications
(like MTM), and I don't think it's usefull to see this in a bootloader
... This is highlighted by the fact that BIOS and EFI specifications
only stick to the SRTM and does not implement complex operations, only
leaving pass-through capabilities.

> 2) Ethical Aspects
> ==================
> 
Every technology has its evil uses, so does TPM. However, there's a very
large gap between currently implemented solutions and what you suggest.
Of course, someone may use TPM in a software suite that completly lock
down your computer. However, I don't think that it's the TPM's fault;
its just a technology. I would rather consider it's the fault of
countries with laws that tolerates these behaviours ...

The goal of TPM is to be used in broader security schemes. Its use is
only to make sure that the integrity of the system was preserved. This
would prevent an attacker from inserting a stealth PCI device which can
leaks data using SMM.

As an ending note, I am much more less confident in Intel's processor
microcode that is patented than in a chip I can deactivate and live
without it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMKXAACgkQBV7eXqefhqgLiwCgnQf3/vAS05SaFQhFm8op44y7
9+oAoIzZouLxPa16A2d+L8VTFNPlZit6
=zq07
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>> 2) Ethical Aspects
>> ==================
>>
> Every technology has its evil uses, so does TPM. However, there's a very
> large gap between currently implemented solutions and what you suggest.
How can you know this? I met persons who say that it's very difficult
to mount a PKI infrastructure to make remote attestation.  would have
agreed if remote attestation would be a corner case of something and
if there was no coordination between TPMs. But none of this holds
true. Additionally some manufacturers even say explicitly that the key
is "approved" and if you reset your TPM your key will be "unaproved"
which implies that some kind of such infrastructure exists.
> Of course, someone may use TPM in a software suite that completly lock
> down your computer. However, I don't think that it's the TPM's fault;
> its just a technology.
Handcuffs are just a technology too but you probably wouldn't disagree
if I say that they are the opposite of freedom.
> I would rather consider it's the fault of
> countries with laws that tolerates these behaviours ...
Money makes goverments blind.
>
> The goal of TPM is to be used in broader security schemes. Its use is
> only to make sure that the integrity of the system was preserved. This
> would prevent an attacker from inserting a stealth PCI device which can
> leaks data using SMM.
>
Please ellaborate. Who is the attacker? What is he after in someone
else's computer? Obviously he isn't after hardware components. If he's
after the data then the owner of data should encrypt is with a decent
password.
> As an ending note, I am much more less confident in Intel's processor
> microcode that is patented than in a chip I can deactivate and live
> without it.
>
Intel microcode is an issue too but it's not hte one which is
discussed right now
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkqMKXAACgkQBV7eXqefhqgLiwCgnQf3/vAS05SaFQhFm8op44y7
> 9+oAoIzZouLxPa16A2d+L8VTFNPlZit6
> =zq07
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
>>> 2) Ethical Aspects
>>> ==================
>>>
>> Every technology has its evil uses, so does TPM. However, there's a very
>> large gap between currently implemented solutions and what you suggest.
> How can you know this? I met persons who say that it's very difficult
> to mount a PKI infrastructure to make remote attestation.  would have
> agreed if remote attestation would be a corner case of something and
> if there was no coordination between TPMs. But none of this holds
> true. Additionally some manufacturers even say explicitly that the key
> is "approved" and if you reset your TPM your key will be "unaproved"
> which implies that some kind of such infrastructure exists.
What key are you talking? The Endorsment Key Pair? Those are bound to
the TPM (and so the platform). They may only be used for AIK generation
and ownership. The result is that you can trust the medium you use to
exchange private data with the tpm after taking control of it (using
HMACs). Of course, if you reset the EKP, then the TPM is marked as
unsecure (would you trust a website if its certificate has changed? oO).
Also, most of the time, the reset operation is disabled by the TPME.
It _can't_ be used for other operations iirc.

>> Of course, someone may use TPM in a software suite that completly lock
>> down your computer. However, I don't think that it's the TPM's fault;
>> its just a technology.
> Handcuffs are just a technology too but you probably wouldn't disagree
> if I say that they are the opposite of freedom.
Hmmm, handcuffs :)
I don't think we are in a good direction, since you use different
schemes to protect material and immaterial property. I don't disagree
the fact that they are the opposite of freedom, but I won't personnaly
count this as an argument.

>> I would rather consider it's the fault of
>> countries with laws that tolerates these behaviours ...
> Money makes goverments blind.
true :/
>> The goal of TPM is to be used in broader security schemes. Its use is
>> only to make sure that the integrity of the system was preserved. This
>> would prevent an attacker from inserting a stealth PCI device which can
>> leaks data using SMM.
>>
> Please ellaborate. Who is the attacker? What is he after in someone
> else's computer? Obviously he isn't after hardware components. If he's
> after the data then the owner of data should encrypt is with a decent
> password.
The attacker is someone that wants to steal a secret from you (and not
the computer, the TPM is useless in this case). Imagine you have an
unbreakable password (that requires a lot of imagination). The attacker
will simply modify for example your bootloader with something like
Stoned. However, if you use a shared secret and the TPM is part of share
process (that means the integrity of your computer is part of the key
retrieval process), then this attack will simply fail.
Remember that you see a lot of TPM on laptops.
>> As an ending note, I am much more less confident in Intel's processor
>> microcode that is patented than in a chip I can deactivate and live
>> without it.
>>
> Intel microcode is an issue too but it's not hte one which is
> discussed right now
I was talking about trust. Who and what can you trust? A closed-source
software? A black box? Your local cyber-café?
Do you trust a TPM in being a part of a chain of trust?

I completly agree with the fact that we must be vigilant. TPM is another
brick that can be used in any cryptographic applications (like CSS).
However, I truly think that simply disregarding it is a mistake: It is
an incredible tool in hardened software. But I also agree with the fact
that it shouldn't be the goal of the Grub project.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMQMsACgkQBV7eXqefhqhFHQCguZ02qptk9RdsdJVMJvckM+ms
c2QAoK23ZiWYYKRdiPDbSY3ROYzHSEdD
=WISW
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 8:13 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>>>> 2) Ethical Aspects
>>>> ==================
>>>>
>>> Every technology has its evil uses, so does TPM. However, there's a very
>>> large gap between currently implemented solutions and what you suggest.
>> How can you know this? I met persons who say that it's very difficult
>> to mount a PKI infrastructure to make remote attestation.  would have
>> agreed if remote attestation would be a corner case of something and
>> if there was no coordination between TPMs. But none of this holds
>> true. Additionally some manufacturers even say explicitly that the key
>> is "approved" and if you reset your TPM your key will be "unaproved"
>> which implies that some kind of such infrastructure exists.
> What key are you talking? The Endorsment Key Pair? Those are bound to
> the TPM (and so the platform). They may only be used for AIK generation
> and ownership. The result is that you can trust the medium you use to
> exchange private data with the tpm after taking control of it (using
> HMACs). Of course, if you reset the EKP, then the TPM is marked as
> unsecure (would you trust a website if its certificate has changed? oO).
But why does a third instance (manufacturer) need to trust my key?
Only one: he wants a control.
> Also, most of the time, the reset operation is disabled by the TPME.
This is a problem (again): you can't make TPM to behave like you want.
> It _can't_ be used for other operations iirc.
Checking you use windows?
>
>>> Of course, someone may use TPM in a software suite that completly lock
>>> down your computer. However, I don't think that it's the TPM's fault;
>>> its just a technology.
>> Handcuffs are just a technology too but you probably wouldn't disagree
>> if I say that they are the opposite of freedom.
> Hmmm, handcuffs :)
> I don't think we are in a good direction, since you use different
> schemes to protect material and immaterial property. I don't disagree
> the fact that they are the opposite of freedom, but I won't personnaly
> count this as an argument.
>
The argument was "TPM aren't opposite of freedom".
>
>>> The goal of TPM is to be used in broader security schemes. Its use is
>>> only to make sure that the integrity of the system was preserved. This
>>> would prevent an attacker from inserting a stealth PCI device which can
>>> leaks data using SMM.
>>>
>> Please ellaborate. Who is the attacker? What is he after in someone
>> else's computer? Obviously he isn't after hardware components. If he's
>> after the data then the owner of data should encrypt is with a decent
>> password.
> The attacker is someone that wants to steal a secret from you (and not
> the computer, the TPM is useless in this case). Imagine you have an
> unbreakable password (that requires a lot of imagination). The attacker
> will simply modify for example your bootloader with something like
> Stoned. However, if you use a shared secret and the TPM is part of share
> process (that means the integrity of your computer is part of the key
> retrieval process), then this attack will simply fail.
Why wouldn't he connect a hardware keylogger (price about $100,
reusable) or change keyboard firmware. Neither is detectable by TPM.
> I was talking about trust. Who and what can you trust? A closed-source
> software?
No
> A black box? Your local cyber-café?
No
> Do you trust a TPM in being a part of a chain of trust?
No
>
> I completly agree with the fact that we must be vigilant. TPM is another
> brick that can be used in any cryptographic applications (like CSS).
> However, I truly think that simply disregarding it is a mistake: It is
> an incredible tool in hardened software.
I don't believe it to be wonderful in anything except giving
impression of security. Increase of $100 is a gain but if your data is
worth less than that your laptop will be stolen for hardware and not
data.
If this measure didn't come with the risk of losing freedom I would be
for its inclusion but with warnings in manual that it provides no real
security (I wouldn't have spend time coding it though, neither would I
have used it). But considering the price (freedom) I reject it.
You lose the freedom the moment when you go in prison cell and someone
is able to close it regardless whether he actualy closes it or not -
he has you at his mercy.

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> But why does a third instance (manufacturer) need to trust my key?
> Only one: he wants a control.

I don't see where the TPME needs to trust the EKP in the specification.

>> Also, most of the time, the reset operation is disabled by the TPME.
> This is a problem (again): you can't make TPM to behave like you want.

Yep, but why would you allow reseting the EKP? You can reset everything
else because you may need to, but it's no use reseting the EKP.

>> It _can't_ be used for other operations iirc.
> Checking you use windows?

Not the TPM, only a ***** BIOS and a ***** manufacturer (which can base
their scheme on TPM). We saw this in the past, but we didn't needed a
TPM for that, only human mind. :|

> The argument was "TPM aren't opposite of freedom".

This was the idea, not the argument.

> Why wouldn't he connect a hardware keylogger (price about $100,
> reusable) or change keyboard firmware. Neither is detectable by TPM.

Because sometimes the security isn't only reduced to a passphrase.
Sometime tokens have their uses.

> I don't believe it to be wonderful in anything except giving
> impression of security. Increase of $100 is a gain but if your data is
> worth less than that your laptop will be stolen for hardware and not
> data.

> If this measure didn't come with the risk of losing freedom I would be
> for its inclusion but with warnings in manual that it provides no real
> security (I wouldn't have spend time coding it though, neither would I
> have used it). But considering the price (freedom) I reject it.
> You lose the freedom the moment when you go in prison cell and someone
> is able to close it regardless whether he actualy closes it or not -
> he has you at his mercy.

Don't you think it isn't even worth working on?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMT4QACgkQBV7eXqefhqiQ4wCgjfVQKceHIckhfQDI2AH9iSg5
ercAn2qP5/l/TA3OnE4aL/i+uJJRbg5u
=CXEm
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 9:16 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> But why does a third instance (manufacturer) need to trust my key?
>> Only one: he wants a control.
>
> I don't see where the TPME needs to trust the EKP in the specification.
Could you please avoid using abbreviations. It's already hard to read
TPM specs because of their twisted terminology. If EKP is the key
stored in the TPM then manufacturer can keep a copy of public or
private key and nobody will notice.
>
>>> Also, most of the time, the reset operation is disabled by the TPME.
>> This is a problem (again): you can't make TPM to behave like you want.
>
> Yep, but why would you allow reseting the EKP? You can reset everything
> else because you may need to, but it's no use reseting the EKP.
>
By using this key you can prove manufacturer that you use the key he
burned in device it controls which opens the bad doors.
>>> It _can't_ be used for other operations iirc.
>> Checking you use windows?
>
> Not the TPM, only a ***** BIOS and a ***** manufacturer (which can base
> their scheme on TPM). We saw this in the past, but we didn't needed a
> TPM for that, only human mind. :|
But TPM is designed to prevent BIOS modifications.
>> Why wouldn't he connect a hardware keylogger (price about $100,
>> reusable) or change keyboard firmware. Neither is detectable by TPM.
>
> Because sometimes the security isn't only reduced to a passphrase.
> Sometime tokens have their uses.
If you have tokens why do you care if attacker has your passphrase.
And just the keyboard input can contain a lot of valuable data itself.
Why do you suppose that attacker can stole the laptop but not the token?
>
>> I don't believe it to be wonderful in anything except giving
>> impression of security. Increase of $100 is a gain but if your data is
>> worth less than that your laptop will be stolen for hardware and not
>> data.
>
>> If this measure didn't come with the risk of losing freedom I would be
>> for its inclusion but with warnings in manual that it provides no real
>> security (I wouldn't have spend time coding it though, neither would I
>> have used it). But considering the price (freedom) I reject it.
>> You lose the freedom the moment when you go in prison cell and someone
>> is able to close it regardless whether he actualy closes it or not -
>> he has you at his mercy.
>
> Don't you think it isn't even worth working on?
If not the freedom concerns it could be fun coding. But IF.

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> Could you please avoid using abbreviations. It's already hard to read
> TPM specs because of their twisted terminology. If EKP is the key
> stored in the TPM then manufacturer can keep a copy of public or
> private key and nobody will notice.

Sorry for the abbreviations. :|
According to the specs, the private endorsement key must not come out of
the TPM. Also, the pair has to be signed by the "manufacturer". If the
manufacturer is not trutworthy, he can squirt the keys and then have a
local copy of the pair. However, it's no use keeping this key since its
only use is to generate AIK (one-time key pairs that are used to
comunicate using HMAC).

>>>> Also, most of the time, the reset operation is disabled by the TPME.
>>> This is a problem (again): you can't make TPM to behave like you want.
>> Yep, but why would you allow reseting the EKP? You can reset everything
>> else because you may need to, but it's no use reseting the EKP.
>>
> By using this key you can prove manufacturer that you use the key he
> burned in device it controls which opens the bad doors.

Well, like in any security system, you suppose the system itself is
secure ... which is not always the case, intentionnaly or not.

>>>> It _can't_ be used for other operations iirc.
>>> Checking you use windows?
>> Not the TPM, only a ***** BIOS and a ***** manufacturer (which can base
>> their scheme on TPM). We saw this in the past, but we didn't needed a
>> TPM for that, only human mind. :|
> But TPM is designed to prevent BIOS modifications.

It's not against my words. I was telling that a malicious manufacturer
can use a TPM to build a system where the BIOS is less likely to be
modified. And if on top of this he uses this to protect the operating
system ... These are use cases of TPM that _we_ don't want to see.

> If you have tokens why do you care if attacker has your passphrase.
> And just the keyboard input can contain a lot of valuable data itself.
> Why do you suppose that attacker can stole the laptop but not the token?

I'm not making any supposition, I'm making all of them. And I'm trying
to reduce the different schemes an attacker could use. There is _always_
a way to steal the secret. At least let's make it less likely to happen.

>> Don't you think it isn't even worth working on?
> If not the freedom concerns it could be fun coding. But IF.
Let's hope that those who works on it are concerned, but you'll always
find someone who isn't.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMXPcACgkQBV7eXqefhqhyFACeNEV9eGIX8Dv+Me0h166yRdg4
uDYAoKLBpliNkKionXrBIOqzu+N7e/rG
=eOtB
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 10:13 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> Could you please avoid using abbreviations. It's already hard to read
>> TPM specs because of their twisted terminology. If EKP is the key
>> stored in the TPM then manufacturer can keep a copy of public or
>> private key and nobody will notice.
>
> Sorry for the abbreviations. :|
> According to the specs, the private endorsement key must not come out of
> the TPM. Also, the pair has to be signed by the "manufacturer". If the
> manufacturer is not trutworthy, he can squirt the keys and then have a
> local copy of the pair. However, it's no use keeping this key since its
> only use is to generate AIK (one-time key pairs that are used to
> comunicate using HMAC).
>
There is a point in keeping them - remote atestation. Why do I need
manufacturer to sign my key?
>> By using this key you can prove manufacturer that you use the key he
>> burned in device it controls which opens the bad doors.
>
> Well, like in any security system, you suppose the system itself is
> secure ... which is not always the case, intentionnaly or not.
Even if you're in an insecure prison you're still in a prison.
>
> It's not against my words. I was telling that a malicious manufacturer
> can use a TPM to build a system where the BIOS is less likely to be
> modified. And if on top of this he uses this to protect the operating
> system ... These are use cases of TPM that _we_ don't want to see.
Unfortunately it's the cases it's designed for.
>
>> If you have tokens why do you care if attacker has your passphrase.
>> And just the keyboard input can contain a lot of valuable data itself.
>> Why do you suppose that attacker can stole the laptop but not the token?
>
> I'm not making any supposition, I'm making all of them. And I'm trying
> to reduce the different schemes an attacker could use. There is _always_
> a way to steal the secret. At least let's make it less likely to happen.
>
Without threat model we're speaking placebo.

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> There is a point in keeping them - remote atestation. Why do I need
> manufacturer to sign my key?

No, the endorsement key pair is not used in remote attestation. Only to
generate one time key pairs for ownership operations.
The signature proves that the key was generated within the manufacturer
infrastructure, and not by someone else using a fraudulent key
generator. If the TPM is enabled to, you can reset the endorsement key
pair and generate a new one (you can also create temporary pairs iirc);
the only thing you'll be missing will be the manufacturer's signature
(but you can use yours if you wishes to).

>>> By using this key you can prove manufacturer that you use the key he
>>> burned in device it controls which opens the bad doors.
>> Well, like in any security system, you suppose the system itself is
>> secure ... which is not always the case, intentionnaly or not.
> Even if you're in an insecure prison you're still in a prison.

Where will we go if we start thinking every security system is flawed. :|

>> It's not against my words. I was telling that a malicious manufacturer
>> can use a TPM to build a system where the BIOS is less likely to be
>> modified. And if on top of this he uses this to protect the operating
>> system ... These are use cases of TPM that _we_ don't want to see.
> Unfortunately it's the cases it's designed for.

No, it was designed as an hardware-based security for data, not
exclusively for going against the end-user.

>>> If you have tokens why do you care if attacker has your passphrase.
>>> And just the keyboard input can contain a lot of valuable data itself.
>>> Why do you suppose that attacker can stole the laptop but not the token?
>> I'm not making any supposition, I'm making all of them. And I'm trying
>> to reduce the different schemes an attacker could use. There is _always_
>> a way to steal the secret. At least let's make it less likely to happen.
>>
> Without threat model we're speaking placebo.
> 

Stoned Bootkit?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMYpMACgkQBV7eXqefhqj45QCfUSyFLxjDy7ojXmjYfNCGbMyZ
eFUAn2eTg1UI/ZnSg/94m+chwFsj9VWd
=tyPM
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Michal Suchanek]

2009/8/19 Duboucher Thomas <thomas@duboucher.eu>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :

>> Without threat model we're speaking placebo.
>>
>
> Stoned Bootkit?

Coreboot can prevent that as well as TPM can.

Any threat model which shows the advantage of TPM?

Thanks

Michal

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michal Suchanek a écrit :
>>> Without threat model we're speaking placebo.
>>>
>> Stoned Bootkit?
> 
> Coreboot can prevent that as well as TPM can.
> 

Coreboot can be "stoned" as easily as your MBR since you can easily
rewrite the MBR from the software. On MB that does not support online
overwriting, you may require physical access (but since you already have
to do some dirt work to replace your RO BIOS, that is not really difficult).

> Any threat model which shows the advantage of TPM?
> 
> Thanks
> 
> Michal

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMZ04ACgkQBV7eXqefhqheswCgmq2li5PD64osiSJROj9Db1iI
ZYAAoK4bgTrOivSSjzHufIWvDlCzO/OF
=Smrd
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 10:57 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michal Suchanek a écrit :
>>>> Without threat model we're speaking placebo.
>>>>
>>> Stoned Bootkit?
>>
>> Coreboot can prevent that as well as TPM can.
>>
>
> Coreboot can be "stoned" as easily as your MBR since you can easily
> rewrite the MBR from the software. On MB that does not support online
> overwriting, you may require physical access (but since you already have
> to do some dirt work to replace your RO BIOS, that is not really difficult).
You can remove TPM too
>
>> Any threat model which shows the advantage of TPM?
>>
>> Thanks
>>
>> Michal
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkqMZ04ACgkQBV7eXqefhqheswCgmq2li5PD64osiSJROj9Db1iI
> ZYAAoK4bgTrOivSSjzHufIWvDlCzO/OF
> =Smrd
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vladimir 'phcoder' Serbinenko a écrit :
> You can remove TPM too
And if you remove the TPM, how do you retrieve the secret? oO
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqMaYQACgkQBV7eXqefhqiK3wCfUEYEv7gnOJAYVYlGimVUyPOm
4TUAoJJnHDDq0gFh246QyTstFaSX/ZL4
=IqA9
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Michal Suchanek]

2009/8/19 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> On Wed, Aug 19, 2009 at 10:57 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Michal Suchanek a écrit :
>>>>> Without threat model we're speaking placebo.
>>>>>
>>>> Stoned Bootkit?
>>>
>>> Coreboot can prevent that as well as TPM can.
>>>
>>
>> Coreboot can be "stoned" as easily as your MBR since you can easily
>> rewrite the MBR from the software. On MB that does not support online
>> overwriting, you may require physical access (but since you already have
>> to do some dirt work to replace your RO BIOS, that is not really difficult).
> You can remove TPM too

That would remove the keys, too. And the chips are designed to erase
them in this case because then you could copy your media files from
one device to other and not buy media for each device separately.

But the bios on most boards is removable and/or upgradeable in place
so you can do the same with TPM+BIOS as you could with coreboot+any
crypto you choose but you get much fewer options in the case of
TPM+BIOS.

Thanks

Michal

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Wed, Aug 19, 2009 at 10:37 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Vladimir 'phcoder' Serbinenko a écrit :
>> There is a point in keeping them - remote atestation. Why do I need
>> manufacturer to sign my key?
>
> No, the endorsement key pair is not used in remote attestation. Only to
> generate one time key pairs for ownership operations.
> The signature proves that the key was generated within the manufacturer
> infrastructure, and not by someone else using a fraudulent key
> generator. If the TPM is enabled to, you can reset the endorsement key
> pair and generate a new one (you can also create temporary pairs iirc);
> the only thing you'll be missing will be the manufacturer's signature
> (but you can use yours if you wishes to).
>
But why can't I generate my keys on first use? Or why do I need
manufacturer's signature?
>>> It's not against my words. I was telling that a malicious manufacturer
>>> can use a TPM to build a system where the BIOS is less likely to be
>>> modified. And if on top of this he uses this to protect the operating
>>> system ... These are use cases of TPM that _we_ don't want to see.
>> Unfortunately it's the cases it's designed for.
>
> No, it was designed as an hardware-based security for data, not
> exclusively for going against the end-user.
They have to propose something to make people accept it.
>> Without threat model we're speaking placebo.
>>
>
> Stoned Bootkit?
Cold boot?


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michael Gorven]

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

On Wednesday 19 August 2009 22:44:18 Vladimir 'phcoder' Serbinenko wrote:
> But why can't I generate my keys on first use? Or why do I need
> manufacturer's signature?

You don't.

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 20, 2009 at 9:40 AM, Michael Gorven<michael@gorven.za.net> wrote:
> On Wednesday 19 August 2009 22:44:18 Vladimir 'phcoder' Serbinenko wrote:
>> But why can't I generate my keys on first use? Or why do I need
>> manufacturer's signature?
>
> You don't.
Exactly. But signature is there which makes it possible to challenge
user to use TPM without owning the system. For user it doesn't matter
if key is signed or not. If TPM was supplied blank and the user could
generate keypair himself then if he doesn't want to use TPM he could
generate a keypair in GnuPG and noone would be able to distinguish it
from TPM key.
The owner would have a public key and he would know it's the key from
TPM because he himself generated and retrieved it.
But do manufacturers do it that way?
>
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michal Suchanek]

2009/8/19 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> On Wed, Aug 19, 2009 at 8:13 PM, Duboucher Thomas<thomas@duboucher.eu> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Vladimir 'phcoder' Serbinenko a écrit :
>>>>> 2) Ethical Aspects
>>>>> ==================
>>>>>
>>>> Every technology has its evil uses, so does TPM. However, there's a very
>>>> large gap between currently implemented solutions and what you suggest.
>>> How can you know this? I met persons who say that it's very difficult
>>> to mount a PKI infrastructure to make remote attestation.  would have
>>> agreed if remote attestation would be a corner case of something and
>>> if there was no coordination between TPMs. But none of this holds
>>> true. Additionally some manufacturers even say explicitly that the key
>>> is "approved" and if you reset your TPM your key will be "unaproved"
>>> which implies that some kind of such infrastructure exists.
>> What key are you talking? The Endorsment Key Pair? Those are bound to
>> the TPM (and so the platform). They may only be used for AIK generation
>> and ownership. The result is that you can trust the medium you use to
>> exchange private data with the tpm after taking control of it (using
>> HMACs). Of course, if you reset the EKP, then the TPM is marked as
>> unsecure (would you trust a website if its certificate has changed? oO).
> But why does a third instance (manufacturer) need to trust my key?
> Only one: he wants a control.
>> Also, most of the time, the reset operation is disabled by the TPME.
> This is a problem (again): you can't make TPM to behave like you want.
>> It _can't_ be used for other operations iirc.
> Checking you use windows?
>>
>>>> Of course, someone may use TPM in a software suite that completly lock
>>>> down your computer. However, I don't think that it's the TPM's fault;
>>>> its just a technology.
>>> Handcuffs are just a technology too but you probably wouldn't disagree
>>> if I say that they are the opposite of freedom.
>> Hmmm, handcuffs :)
>> I don't think we are in a good direction, since you use different
>> schemes to protect material and immaterial property. I don't disagree
>> the fact that they are the opposite of freedom, but I won't personnaly
>> count this as an argument.
>>
> The argument was "TPM aren't opposite of freedom".
>>
>>>> The goal of TPM is to be used in broader security schemes. Its use is
>>>> only to make sure that the integrity of the system was preserved. This
>>>> would prevent an attacker from inserting a stealth PCI device which can
>>>> leaks data using SMM.
>>>>
>>> Please ellaborate. Who is the attacker? What is he after in someone
>>> else's computer? Obviously he isn't after hardware components. If he's
>>> after the data then the owner of data should encrypt is with a decent
>>> password.
>> The attacker is someone that wants to steal a secret from you (and not
>> the computer, the TPM is useless in this case). Imagine you have an
>> unbreakable password (that requires a lot of imagination). The attacker
>> will simply modify for example your bootloader with something like
>> Stoned. However, if you use a shared secret and the TPM is part of share
>> process (that means the integrity of your computer is part of the key
>> retrieval process), then this attack will simply fail.
> Why wouldn't he connect a hardware keylogger (price about $100,
> reusable) or change keyboard firmware. Neither is detectable by TPM.
>> I was talking about trust. Who and what can you trust? A closed-source
>> software?
> No
>> A black box? Your local cyber-café?
> No
>> Do you trust a TPM in being a part of a chain of trust?
> No
>>
>> I completly agree with the fact that we must be vigilant. TPM is another
>> brick that can be used in any cryptographic applications (like CSS).
>> However, I truly think that simply disregarding it is a mistake: It is
>> an incredible tool in hardened software.
> I don't believe it to be wonderful in anything except giving
> impression of security. Increase of $100 is a gain but if your data is
> worth less than that your laptop will be stolen for hardware and not
> data.
> If this measure didn't come with the risk of losing freedom I would be
> for its inclusion but with warnings in manual that it provides no real
> security (I wouldn't have spend time coding it though, neither would I
> have used it). But considering the price (freedom) I reject it.
> You lose the freedom the moment when you go in prison cell and someone
> is able to close it regardless whether he actualy closes it or not -
> he has you at his mercy.
>

These TPM discussions are .. interesting.

I have a challenge for people who want TPM support:

Tell me one technical benefit of TPM over coreboot.

The disadvantage is obvious: TPM was designed for DRM schemes. However
hard these might be to implement in practice it's what they had in
mind when designing the TPM chips. When you reset the internal key of
the TPM you can still trust the chip because you can verify that next
time is still the same - nobody has reset it again. But the media and
other IP vendors using DRM schemes would only trust the manufacturer's
key. If it was not designed for DRM the device would come blank and
you would generate a key when you first use the device. This is how
many USB/SmartCard/1wire/.. devices work with the additional benefit
that you can easily remove them from the system when it is not in use
for additional protection.

So coreboot+removable crypto device >> TPM in my book.

Remember that it's the CPU what runs your system, not the TPM so you
still rely on BIOS to do the right thing while initializing the TPM.

Thanks

Michal

Re: TPM support status ?

[Michael Gorven]

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

On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
> Tell me one technical benefit of TPM over coreboot.

Coreboot doesn't provide protected storage of secrets (e.g. harddrive 
decryption keys).

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Michael Gorven <michael@gorven.za.net>:
> On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>> Tell me one technical benefit of TPM over coreboot.
>
> Coreboot doesn't provide protected storage of secrets (e.g. harddrive
> decryption keys).

TPM does not either at the time the BIOS is loaded. Remember, it's the
CPU what's running the BIOS, not the TPM chip.

Only after BIOS enables TPM or coreboot enables any crypto device you
choose you get any secrets or keys.

Thanks

Michal

Re: TPM support status ?

[Michael Gorven]

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

On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
> > On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
> >> Tell me one technical benefit of TPM over coreboot.
> >
> > Coreboot doesn't provide protected storage of secrets (e.g. harddrive
> > decryption keys).
>
> TPM does not either at the time the BIOS is loaded. Remember, it's the
> CPU what's running the BIOS, not the TPM chip.
>
> Only after BIOS enables TPM or coreboot enables any crypto device you
> choose you get any secrets or keys.

So? It's still protected storage. You can read a BIOS chip, but you can't just 
read the contents of a TPM chip.

Michael

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Michael Gorven <michael@gorven.za.net>:
> On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> > On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>> >> Tell me one technical benefit of TPM over coreboot.
>> >
>> > Coreboot doesn't provide protected storage of secrets (e.g. harddrive
>> > decryption keys).
>>
>> TPM does not either at the time the BIOS is loaded. Remember, it's the
>> CPU what's running the BIOS, not the TPM chip.
>>
>> Only after BIOS enables TPM or coreboot enables any crypto device you
>> choose you get any secrets or keys.
>
> So? It's still protected storage. You can read a BIOS chip, but you can't just
> read the contents of a TPM chip.
>

You can use decent crypto storage rather than half-broken TPM. There
is no advantage to using it.

Thanks

Michal

Re: TPM support status ?

[Michael Gorven]

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

On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
> > On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
> >> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
> >> > On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
> >> >> Tell me one technical benefit of TPM over coreboot.
> >> >
> >> > Coreboot doesn't provide protected storage of secrets (e.g. harddrive
> >> > decryption keys).
> >>
> >> TPM does not either at the time the BIOS is loaded. Remember, it's the
> >> CPU what's running the BIOS, not the TPM chip.
> >>
> >> Only after BIOS enables TPM or coreboot enables any crypto device you
> >> choose you get any secrets or keys.
> >
> > So? It's still protected storage. You can read a BIOS chip, but you can't
> > just read the contents of a TPM chip.
>
> You can use decent crypto storage rather than half-broken TPM. There
> is no advantage to using it.

Like what?

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Michael Gorven <michael@gorven.za.net>:
> On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> > On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>> >> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> >> > On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>> >> >> Tell me one technical benefit of TPM over coreboot.
>> >> >
>> >> > Coreboot doesn't provide protected storage of secrets (e.g. harddrive
>> >> > decryption keys).
>> >>
>> >> TPM does not either at the time the BIOS is loaded. Remember, it's the
>> >> CPU what's running the BIOS, not the TPM chip.
>> >>
>> >> Only after BIOS enables TPM or coreboot enables any crypto device you
>> >> choose you get any secrets or keys.
>> >
>> > So? It's still protected storage. You can read a BIOS chip, but you can't
>> > just read the contents of a TPM chip.
>>
>> You can use decent crypto storage rather than half-broken TPM. There
>> is no advantage to using it.
>
> Like what?
>

There is hardware for secure key storage which you can put into some
card slot or USB and unlike TPM you can also remove it and store
separately from the computer which greatly decreases the chance that
your data would be compromised if your computer is stolen.

I am not using such hardware so I do not know all the details of
available options. STFW should bring up something.

Thanks

Michal

Re: TPM support status ?

[Michael Gorven]

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

On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote:
> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
> > On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
> >> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
> >> > On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
> >> >> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
> >> >> > On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
> >> >> >> Tell me one technical benefit of TPM over coreboot.
> >> >> >
> >> >> > Coreboot doesn't provide protected storage of secrets (e.g.
> >> >> > harddrive decryption keys).
> >> >>
> >> >> TPM does not either at the time the BIOS is loaded. Remember, it's
> >> >> the CPU what's running the BIOS, not the TPM chip.
> >> >>
> >> >> Only after BIOS enables TPM or coreboot enables any crypto device you
> >> >> choose you get any secrets or keys.
> >> >
> >> > So? It's still protected storage. You can read a BIOS chip, but you
> >> > can't just read the contents of a TPM chip.
> >>
> >> You can use decent crypto storage rather than half-broken TPM. There
> >> is no advantage to using it.
> >
> > Like what?
>
> There is hardware for secure key storage which you can put into some
> card slot or USB and unlike TPM you can also remove it and store
> separately from the computer which greatly decreases the chance that
> your data would be compromised if your computer is stolen.

But that doesn't protect the machine (and crypto card) from being physically 
compromised, so it's not the same as TPM.

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>>
>> There is hardware for secure key storage which you can put into some
>> card slot or USB and unlike TPM you can also remove it and store
>> separately from the computer which greatly decreases the chance that
>> your data would be compromised if your computer is stolen.
>
> But that doesn't protect the machine (and crypto card) from being physically
> compromised, so it's not the same as TPM.
Oh well, smartcard is breakable but TPM isn't. As for bootchain
coreboot can do it.
>
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Michael Gorven <michael@gorven.za.net>:
> On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote:
>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> > On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
>> >> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> >> > On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>> >> >> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> >> >> > On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>> >> >> >> Tell me one technical benefit of TPM over coreboot.
>> >> >> >
>> >> >> > Coreboot doesn't provide protected storage of secrets (e.g.
>> >> >> > harddrive decryption keys).
>> >> >>
>> >> >> TPM does not either at the time the BIOS is loaded. Remember, it's
>> >> >> the CPU what's running the BIOS, not the TPM chip.
>> >> >>
>> >> >> Only after BIOS enables TPM or coreboot enables any crypto device you
>> >> >> choose you get any secrets or keys.
>> >> >
>> >> > So? It's still protected storage. You can read a BIOS chip, but you
>> >> > can't just read the contents of a TPM chip.
>> >>
>> >> You can use decent crypto storage rather than half-broken TPM. There
>> >> is no advantage to using it.
>> >
>> > Like what?
>>
>> There is hardware for secure key storage which you can put into some
>> card slot or USB and unlike TPM you can also remove it and store
>> separately from the computer which greatly decreases the chance that
>> your data would be compromised if your computer is stolen.
>
> But that doesn't protect the machine (and crypto card) from being physically
> compromised, so it's not the same as TPM.

How does TPM protest your machine from physical access? I thought it's
a small chip somewhere on the board, not a steel case around the
machine.

Thanks

Michal

Re: TPM support status ?

[Michael Gorven]

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

On Thursday 20 August 2009 12:58:50 Michal Suchanek wrote:
> How does TPM protest your machine from physical access? I thought it's
> a small chip somewhere on the board, not a steel case around the
> machine.

The TPM can be configured to only divulge the secret once it's been proven 
that only the intended software is running.

-- 
http://michael.gorven.za.net
PGP Key ID 1E016BE8
S/MIME Key ID AAF09E0E

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 827 bytes --]

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 20, 2009 at 1:15 PM, Michael Gorven<michael@gorven.za.net> wrote:
> On Thursday 20 August 2009 12:58:50 Michal Suchanek wrote:
>> How does TPM protest your machine from physical access? I thought it's
>> a small chip somewhere on the board, not a steel case around the
>> machine.
>
> The TPM can be configured to only divulge the secret once it's been proven
> that only the intended software is running.
>
Proven? As any chip it can only know what's on its pins. High-tech
electric lab equipment can fool any chip. Asking nicely at university
most students can gain access to one.
> --
> http://michael.gorven.za.net
> PGP Key ID 1E016BE8
> S/MIME Key ID AAF09E0E
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>:
> On Thu, Aug 20, 2009 at 1:15 PM, Michael Gorven<michael@gorven.za.net> wrote:
>> On Thursday 20 August 2009 12:58:50 Michal Suchanek wrote:
>>> How does TPM protest your machine from physical access? I thought it's
>>> a small chip somewhere on the board, not a steel case around the
>>> machine.
>>
>> The TPM can be configured to only divulge the secret once it's been proven
>> that only the intended software is running.
>>
> Proven? As any chip it can only know what's on its pins. High-tech
> electric lab equipment can fool any chip. Asking nicely at university
> most students can gain access to one.

I doubt this is even necessary. What's the real difference between
mounting the chip on the mainboard and plugging one into an external
port (besides the inability to use content encrypted by the chip on
different machine if you wanted to)?

Thanks

Michal

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>> Proven? As any chip it can only know what's on its pins. High-tech
>> electric lab equipment can fool any chip. Asking nicely at university
>> most students can gain access to one.
>
> I doubt this is even necessary. What's the real difference between
> mounting the chip on the mainboard and plugging one into an external
> port (besides the inability to use content encrypted by the chip on
> different machine if you wanted to)?
I also doubt that it's necessary - perhaps an adapter can be soldered
from parts without big difficulty. I just say that it's possible and
even if it's complicated it's not impossible and once it's published
exactly how to do it it will be much easier. Nothing can make
general-purpose computer tamper-resistant - it's simply not designed
this way. Smartcards can be tamper-resistant because they are designed
to be such (and even they sometimes fail this goal). Making system
tamper-resistant means that every component must be tamper-resistant
and all the connections.
As you see I deliberately avoided word "tamperproof" because I don't
believe in this being anything more as an idealisation similar to hash
being random oracle except that no real hash is one and in some cases
even the smallest difference between real hash and random oracle makes
whole system insecure.
No chip can make laptop or server tamper-resistant. I acknowledge that
tamperproveness can be an useful cryptographical property but no
realisation of it should be locked by manufacturer for consumer
devices. It's fine for e.g. medical equipment or flight guidance
system to be tamper-resistant but a consumer who bought a device has
right to use it for whatever use he likes to no matter what
manufacturer wants. No baker sells the bread with conditions like "you
can eat it only evening" or "you can't give it with your neighbour"
and so on. Why would consumer electronics manufacturer be allowed to
do so?
>
> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michal Suchanek a écrit :
> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote:
>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>> On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
>>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>>> On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>>>>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>>>>> On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>>>>>>>>> Tell me one technical benefit of TPM over coreboot.
>>>>>>>> Coreboot doesn't provide protected storage of secrets (e.g.
>>>>>>>> harddrive decryption keys).

It could emulate what a TPM does, however since it starts its job later
in the boot process, it is far, far less secure (I personnaly would
consider it useless in this case).

>>>>>>> TPM does not either at the time the BIOS is loaded. Remember, it's
>>>>>>> the CPU what's running the BIOS, not the TPM chip.

	Just to make some precisions about TPM and its uses (or at least, as
far as I understood how they works). The TPM chip is soldered on the LPC
bus, that is, the same bus where the SuperIO (keyboard controller) and
the BIOS ROM are located, under the SouthBridge. During a BootUp phase
(G2 -> G0), the Core Root of Trusted Measurement, also located on the
LPC bus, wake up and initialize the TPM. It measures itself (firmware,
configuration, ...), then it measures the BIOS ROM. When these
operations are completed, the BIOS is then executed by the processor and
the system boots up. Other elements being measured later are the
CPU/NB/SB/SuperIO microcode/configuration and the BIOS configuration. I
don't have a lot more details on these stages since I haven't acess to
the whole specifications, nor I am a PC guru. You can check this if you
have a TPM enabled computer by dumping the content of
/sys/kernel/security/tpmX/ on your securityfs.
	These steps contribute in creating what is called a "trusted platform"
composed of "trusted elements" within "trust boundary" (yep, that's a
lot of trust). This means that when the first IPL is loaded, you can
check wether the system has been tampered or not, the TPM state being
the "image" of the system (or as close as it can be).
Because trust is transitive, you end up with a complete system that you
can "trust", because the TPM can be considered as being a "trusted third
party".
	The easiest known attack on TPM is intercepting data on the LPC bus.
Because it can't be trusted (the bus), you could put some controller
(like FPGAs) between the TPM and the bus (with some dirty work). Then
using an altered boot loader (i.e. Stoned), making the system boot
normaly, except that you would intercept the measure of the malicious
boot loader and replace it by the measure of the old boot loader. You
can keep the original series of measure to make the TPM believe the
system hasn't been tampered and you'll end up discovering the shared
secret the TPM was holding without the user being able to notice the
system integrity was compromised. Well, that require a lot of dirty work
and wires, but it works. ;)
	However, later chips, like Intel's iTPM tries to integrate the BIOS ROM
and the TPM within the SouthBridge, removing the LPC bus, the untrusted
part. Also, TPM are watching closely the LPC bus (such as trying to
detect clock variations).

>>>>>>> Only after BIOS enables TPM or coreboot enables any crypto device you
>>>>>>> choose you get any secrets or keys.
>>>>>> So? It's still protected storage. You can read a BIOS chip, but you
>>>>>> can't just read the contents of a TPM chip.
>>>>> You can use decent crypto storage rather than half-broken TPM. There
>>>>> is no advantage to using it.
>>>> Like what?
>>> There is hardware for secure key storage which you can put into some
>>> card slot or USB and unlike TPM you can also remove it and store
>>> separately from the computer which greatly decreases the chance that
>>> your data would be compromised if your computer is stolen.
>> But that doesn't protect the machine (and crypto card) from being physically
>> compromised, so it's not the same as TPM.

People are mixing everything together :)
Apart from its SmartCard capabilities, the basic use of a TPM is proving
your system wasn't altered since when you set up the TPM. To make things
simple:
* a passphrase proves that you _know_ part of the shared secret
* a token proves that you _own_ part of the shared secret
* a TPM proves that your medium can be trusted
Using this, you can use security scheme that do require the medium to be
trusted, or at least doesn't require very complex operations to work on
untrusted systems.
Also, TPM can do the same operations that a SmartCard can; the only
difference being that one object is a small SmartCard, and the other is
a computer (or any device, laptop, cellphone, PPA, ...).

> How does TPM protest your machine from physical access? I thought it's
> a small chip somewhere on the board, not a steel case around the
> machine.

	You are right, it's a small chip somewhere on the board. And to give
you an answer, it doesn't protect your machine from physical access.
	The only thing it does is proving that you can "trust" your system
(because when you initialized your TPM, your system may already be
untrustworthy). And then it can hold _shared_ secrets that you may use
(for disk encryption for instance). The result is that if your system
was altered in any way, the shared secret remains hidden.

> Thanks
> 
> Michal
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqNekcACgkQBV7eXqefhqg6qwCfYkxNXpgVzmin9xM/gFVfpkZn
HFAAn1s81V6XKhCbwOqa21V6jXgJHIf7
=Cnnd
-----END PGP SIGNATURE-----

about smartcards (Re: TPM support status ?)

[Robert Millan]

On Thu, Aug 20, 2009 at 06:31:03PM +0200, Duboucher Thomas wrote:
> Also, TPM can do the same operations that a SmartCard can; the only
> difference being that one object is a small SmartCard, and the other is
> a computer (or any device, laptop, cellphone, PPA, ...).

I've been asked about this elsewhere, so just to make it clear: there's no
problem at all with SmartCards.  Even the FSF distributes some themselves.

The reason we object to TPMs is that they can be used to prevent people
from using free software in their general-purpose computers (nowadays
this includes laptops, cellphones and whatnot) to interact with the outside
world.

SmartCards are a single-purpose device.  Users don't install software in them,
and they don't have any user interface (other than a button or so) that could
be used to implement DRM, so it's not an issue if their owners can't modify
their firmware (which could even be in a ROM).

Whether SmartCards can be used for something unethical is outside our scope.
We're in the free software bussiness, not in the "free authentication" one.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: about smartcards (Re: TPM support status ?)

[decoder]

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

Robert Millan wrote:
> SmartCards are a single-purpose device.  Users don't install software in them,
>   
You don't install software in a TPM module either.
> and they don't have any user interface (other than a button or so) that could
> be used to implement DRM
This is wrong. Smartcards of course have a an interface to interact with 
them. It is even a not so small subset of what TPM provides.

And yes, you could use a Smartcard to do DRM.

> , so it's not an issue if their owners can't modify
> their firmware (which could even be in a ROM).
>   
The TPM can't modify anything either. A TPM is a _passive_ crypto module.


Best regards,



Chris

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3471 bytes --]

Re: about smartcards (Re: TPM support status ?)

[Vladimir 'phcoder' Serbinenko]

> The TPM can't modify anything either. A TPM is a _passive_ crypto module.
Even if it's so the question which was specifically discussed in
parallel thread is TCG bootpath which is a bad thing


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: about smartcards (Re: TPM support status ?)

[Robert Millan]

On Thu, Aug 20, 2009 at 08:35:34PM +0200, decoder wrote:
> Robert Millan wrote:
>> SmartCards are a single-purpose device.  Users don't install software in them,
>>   
> You don't install software in a TPM module either.
>> and they don't have any user interface (other than a button or so) that could
>> be used to implement DRM
> This is wrong. Smartcards of course have a an interface to interact with  
> them.

Yes, but it's usually just a button or similar.  It doesn't behave like a
computer.

The same happens with your oven or your fridge.  They run software and have a
user interface, but they don't work like a computer.

> And yes, you could use a Smartcard to do DRM.

No, you can't.  What you can do is use the smartcard for authentication
in a computer that has been previously rigged against its user.  In this
case it is the computer which implements DRM, not the card.

>> , so it's not an issue if their owners can't modify
>> their firmware (which could even be in a ROM).
>>   
> The TPM can't modify anything either. A TPM is a _passive_ crypto module.

What does this have to do with anything?  Being passive doesn't prevent it
from being used in coercion schemes like:

  "Either you use this TPM to certify you're running Crippleware Reader
   2.0 or you can't read this book"

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: about smartcards (Re: TPM support status ?)

[decoder]

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

Robert Millan wrote:
>> This is wrong. Smartcards of course have a an interface to interact with  
>> them.
>>     
>
> Yes, but it's usually just a button or similar.  It doesn't behave like a
> computer.
>   
What I meant is the software interface. There are crypto protocols to 
interact with a smartcard and they are similar to the TPM protocols.
> The same happens with your oven or your fridge.  They run software and have a
> user interface, but they don't work like a computer.
>
>   
>> And yes, you could use a Smartcard to do DRM.
>>     
>
> No, you can't.  What you can do is use the smartcard for authentication
> in a computer that has been previously rigged against its user.  In this
> case it is the computer which implements DRM, not the card.
>   
The TPM module itself does not implement DRM either... It provides the 
necessary crypto routines, a smartcard does so too.
> What does this have to do with anything?  Being passive doesn't prevent it
> from being used in coercion schemes like:
>
>   "Either you use this TPM to certify you're running Crippleware Reader
>    2.0 or you can't read this book"
>   
You can use a smartcard as well for that purpose. Crippleware Reader 2.0 
can cryptographically make sure that the smartcard is attached, and 
refuse to work otherwise. And you can make the Smartcard a requirement 
to read the book.

I don't really see the point why people keep bashing the TPM module for 
purposes like DRM. It's not the TPM module that is bad, but the stuff 
that people plan to do with it.


Chris


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3471 bytes --]

Re: about smartcards (Re: TPM support status ?)

[Vladimir 'phcoder' Serbinenko]

On Thu, Aug 20, 2009 at 10:11 PM, decoder<decoder@own-hero.net> wrote:
> Robert Millan wrote:
>>>
>>> This is wrong. Smartcards of course have a an interface to interact with
>>>  them.
>>>
>>
>> Yes, but it's usually just a button or similar.  It doesn't behave like a
>> computer.
>>
>
> What I meant is the software interface. There are crypto protocols to
> interact with a smartcard and they are similar to the TPM protocols.
TPM has TCG bootpath smartcards don't have.
> The TPM module itself does not implement DRM either... It provides the
> necessary crypto routines, a smartcard does so too.
But it can be made to give the key only if you use Crippleware Reader
on Cripple OS with all drivers signed.
> You can use a smartcard as well for that purpose. Crippleware Reader 2.0 can
> cryptographically make sure that the smartcard is attached, and refuse to
> work otherwise. And you can make the Smartcard a requirement to read the
> book.
>
Few hours of PrintScreen job and I have DRM-free version of book. Or I
dump the memory of Crippleware reader. Or write Good Alternative
Reader. But with TCG bootpath these ways can be disabled
> I don't really see the point why people keep bashing the TPM module for
> purposes like DRM.
TCG bootpath with cryptographical distinguishibility from an emulator
even if you aren't computer owner (the one who bought it).

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: about smartcards (Re: TPM support status ?)

[Robert Millan]

On Thu, Aug 20, 2009 at 10:11:31PM +0200, decoder wrote:
> Robert Millan wrote:
>>> This is wrong. Smartcards of course have a an interface to interact 
>>> with  them.
>>>     
>>
>> Yes, but it's usually just a button or similar.  It doesn't behave like a
>> computer.
>>   
> What I meant is the software interface. There are crypto protocols to  
> interact with a smartcard and they are similar to the TPM protocols.

Ok, I guess we're losing the big picture.  Maybe I should explain what I
have in mind.

We provide free software.  Software which comes with the freedom to modify,
among others.  We want all users to be able to enjoy this freedom.

In order for free software to be usable by everyone, we need it to be a valid
replacement for proprietary software.  For example, if proprietary software
can read a book, we want free software to be able to read this book too.

HOWEVER, when this proprietary software is being authenticated by a TPM, it
can gain ability to open files that free software cannot.  This scheme can
also be used against other proprietary programs, but it can't be used to
favour free software, simply because it would render it unmodifiable (hence
not free anymore).

So, my concern is that TPM makes it possible for certain parties to ban free
browsers, free document viewers, free media players, etc, from accessing
certain files, websites, or resources in general.

My concern is NOT about people using authentication mechanisms.  Smartcards,
fingerprints, passwords, whatever.  I don't care what they're used for.  I
just care that users can use free software and retain the freedom to
modify it.

>> No, you can't.  What you can do is use the smartcard for authentication
>> in a computer that has been previously rigged against its user.  In this
>> case it is the computer which implements DRM, not the card.
>>   
> The TPM module itself does not implement DRM either... It provides the  
> necessary crypto routines, a smartcard does so too.

It's completely different.  A smartcard can't be used by a third party to
coerce you into installing a specific program.  A TPM can be.

>>   "Either you use this TPM to certify you're running Crippleware Reader
>>    2.0 or you can't read this book"
>>   
> You can use a smartcard as well for that purpose. Crippleware Reader 2.0  
> can cryptographically make sure that the smartcard is attached, and  
> refuse to work otherwise.

I don't care if Crippleware Reader refuses to work.  It's a non-free
application, so refusing to work is not to be unexpected.

However, if I use a free reader, this reader can do everything Crippleware
can do, and more.  We can have it send data to a smartcard, have it signed,
then send it to anyone else, etc.  The smartcard has no way to tell if it's
dealing with the non-free program or not.

> And you can make the Smartcard a requirement  
> to read the book.

Without a TPM, the smartcard can be a requirement to *decrypt* the book.  Once
it's decrypted, I can do anything I like with it, like printing, modifiing,
etc, as long as I'm allowed by law (see "fair use doctrine").

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Vladimir 'phcoder' Serbinenko]

>
> It could emulate what a TPM does, however since it starts its job later
> in the boot process, it is far, far less secure (I personnaly would
> consider it useless in this case).
You have to secure something physically. What we consider here are
targetted attacks, not script kiddies. To deflect script kiddies
anything is enough. For targetted attack you can't assume attacker
can't mess with any chip
>
>>>>>>>> TPM does not either at the time the BIOS is loaded. Remember, it's
>>>>>>>> the CPU what's running the BIOS, not the TPM chip.
>
>        Just to make some precisions about TPM and its uses (or at least, as
> far as I understood how they works). The TPM chip is soldered on the LPC
> bus, that is, the same bus where the SuperIO (keyboard controller) and
> the BIOS ROM are located, under the SouthBridge. During a BootUp phase
> (G2 -> G0), the Core Root of Trusted Measurement, also located on the
> LPC bus, wake up and initialize the TPM. It measures itself (firmware,
> configuration, ...), then it measures the BIOS ROM. When these
> operations are completed, the BIOS is then executed by the processor and
> the system boots up. Other elements being measured later are the
> CPU/NB/SB/SuperIO microcode/configuration and the BIOS configuration. I
> don't have a lot more details on these stages since I haven't acess to
> the whole specifications, nor I am a PC guru. You can check this if you
> have a TPM enabled computer by dumping the content of
> /sys/kernel/security/tpmX/ on your securityfs.
>        These steps contribute in creating what is called a "trusted platform"
> composed of "trusted elements" within "trust boundary" (yep, that's a
> lot of trust). This means that when the first IPL is loaded, you can
> check wether the system has been tampered or not, the TPM state being
> the "image" of the system (or as close as it can be).
> Because trust is transitive, you end up with a complete system that you
> can "trust", because the TPM can be considered as being a "trusted third
> party".
>        The easiest known attack on TPM is intercepting data on the LPC bus.
> Because it can't be trusted (the bus), you could put some controller
> (like FPGAs) between the TPM and the bus (with some dirty work). Then
> using an altered boot loader (i.e. Stoned), making the system boot
> normaly, except that you would intercept the measure of the malicious
> boot loader and replace it by the measure of the old boot loader. You
> can keep the original series of measure to make the TPM believe the
> system hasn't been tampered and you'll end up discovering the shared
> secret the TPM was holding without the user being able to notice the
> system integrity was compromised. Well, that require a lot of dirty work
> and wires, but it works. ;)
>        However, later chips, like Intel's iTPM tries to integrate the BIOS ROM
> and the TPM within the SouthBridge, removing the LPC bus, the untrusted
> part. Also, TPM are watching closely the LPC bus (such as trying to
> detect clock variations).
>
Thanks for detailing technical details but they don't invalidate my
point. An attacker will just mess with another part. Can't mess with
LPC? Let's mess with PCI. Or RAM. Or CPU. There is a known attack of
filling the memory with jumps to your code and putting CPU into
hazardous environment (like microwave in my kitchen) and waiting till
CPU jumps to your code.
But these measures are enough to make people not consider Free
Software at all. Even now when you can't provide XYZ feature users say
free software is a crap. And making users require to put their CPU in
microwave to read .docs would effectively mean the death of free
software. Additionally TPM possesses technical and non-technical
properties which make it suitable to lock-out. If TPM came blank (no
keys whatsoever) and key was generate by calling a special function
then I would be ok with it. And it will be appropriate for every
legitimate use you mention. But as is we can't and will never support
TPM.
You can argue that GRUB will never implement a lockout (and GPLv3+
explicitly forbids it) but you need to think broadly. If even GNU
silently approves TPM it would be like watching senator Pallpatin
taking powers and applause. If we[1] raise public awareness around TPM
but use it in software it both makes our statements hipocritic and our
software useless in a free world which s our goal.
For these reasons we won't support TPM until it meets one of the
conditions that will make it ok

[1] I feel myself like a part of GNU and allowed myself to speak in
its name but I'm not an official GNU person myself and my opinion
isn't necessarily this of GNU but I hope maintainers agree with what I
say
> * a TPM proves that your medium can be trusted
Trusted by whom? We have the problem that beyond the key there is the
signature but it makes for manufacturer possible tocoerce most of
users to transfer trust to him.
It's like buying a lock without a key. You don't own such
lock.Similarly you don't completely own a general-purpose computer and
it may boil down you owning just the metal and computer being owned by
someone else's even if you bought a computer.
>        The only thing it does is proving that you can "trust" your system
> (because when you initialized your TPM, your system may already be
> untrustworthy). And then it can hold _shared_ secrets that you may use
> (for disk encryption for instance). The result is that if your system
> was altered in any way, the shared secret remains hidden.
DRM producers trust the system even more since for them targetted
attacks by skilled geeks knowing to manipulate soldering iron aren't a
problem


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: TPM support status ?

[Duboucher Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Seems that my smtp was down :|

Michal Suchanek a écrit :
> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>> On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote:
>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>> On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
>>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>>> On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>>>>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>>>>> On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>>>>>>>>> Tell me one technical benefit of TPM over coreboot.
>>>>>>>> Coreboot doesn't provide protected storage of secrets (e.g.
>>>>>>>> harddrive decryption keys).

It could emulate what a TPM does, however since it starts its job later
in the boot process, it is far, far less secure (I personnaly would
consider it useless in this case).

>>>>>>> TPM does not either at the time the BIOS is loaded. Remember, it's
>>>>>>> the CPU what's running the BIOS, not the TPM chip.

	Just to make some precisions about TPM and its uses (or at least, as
far as I understood how they works). The TPM chip is soldered on the LPC
bus, that is, the same bus where the SuperIO (keyboard controller) and
the BIOS ROM are located, under the SouthBridge. During a BootUp phase
(G2 -> G0), the Core Root of Trusted Measurement, also located on the
LPC bus, wake up and initialize the TPM. It measures itself (firmware,
configuration, ...), then it measures the BIOS ROM. When these
operations are completed, the BIOS is then executed by the processor and
the system boots up. Other elements being measured later are the
CPU/NB/SB/SuperIO microcode/configuration and the BIOS configuration. I
don't have a lot more details on these stages since I haven't acess to
the whole specifications, nor I am a PC guru. You can check this if you
have a TPM enabled computer by dumping the content of
/sys/kernel/security/tpmX/ on your securityfs.
	These steps contribute in creating what is called a "trusted platform"
composed of "trusted elements" within "trust boundary" (yep, that's a
lot of trust). This means that when the first IPL is loaded, you can
check wether the system has been tampered or not, the TPM state being
the "image" of the system (or as close as it can be).
Because trust is transitive, you end up with a complete system that you
can "trust", because the TPM can be considered as being a "trusted third
party".
	The easiest known attack on TPM is intercepting data on the LPC bus.
Because it can't be trusted (the bus), you could put some controller
(like FPGAs) between the TPM and the bus (with some dirty work). Then
using an altered boot loader (i.e. Stoned), making the system boot
normaly, except that you would intercept the measure of the malicious
boot loader and replace it by the measure of the old boot loader. You
can keep the original series of measure to make the TPM believe the
system hasn't been tampered and you'll end up discovering the shared
secret the TPM was holding without the user being able to notice the
system integrity was compromised. Well, that require a lot of dirty work
and wires, but it works. ;)
	However, later chips, like Intel's iTPM tries to integrate the BIOS ROM
and the TPM within the SouthBridge, removing the LPC bus, the untrusted
part. Also, TPM are watching closely the LPC bus (such as trying to
detect clock variations).

>>>>>>> Only after BIOS enables TPM or coreboot enables any crypto device you
>>>>>>> choose you get any secrets or keys.
>>>>>> So? It's still protected storage. You can read a BIOS chip, but you
>>>>>> can't just read the contents of a TPM chip.
>>>>> You can use decent crypto storage rather than half-broken TPM. There
>>>>> is no advantage to using it.
>>>> Like what?
>>> There is hardware for secure key storage which you can put into some
>>> card slot or USB and unlike TPM you can also remove it and store
>>> separately from the computer which greatly decreases the chance that
>>> your data would be compromised if your computer is stolen.
>> But that doesn't protect the machine (and crypto card) from being physically
>> compromised, so it's not the same as TPM.

People are mixing everything together :)
Apart from its SmartCard capabilities, the basic use of a TPM is proving
your system wasn't altered since when you set up the TPM. To make things
simple:
* a passphrase proves that you _know_ part of the shared secret
* a token proves that you _own_ part of the shared secret
* a TPM proves that your medium can be trusted
Using this, you can use security scheme that do require the medium to be
trusted, or at least doesn't require very complex operations to work on
untrusted systems.
Also, TPM can do the same operations that a SmartCard can; the only
difference being that one object is a small SmartCard, and the other is
a computer (or any device, laptop, cellphone, PPA, ...).

> How does TPM protest your machine from physical access? I thought it's
> a small chip somewhere on the board, not a steel case around the
> machine.

	You are right, it's a small chip somewhere on the board. And to give
you an answer, it doesn't protect your machine from physical access.
	The only thing it does is proving that you can "trust" your system
(because when you initialized your TPM, your system may already be
untrustworthy). And then it can hold _shared_ secrets that you may use
(for disk encryption for instance). The result is that if your system
was altered in any way, the shared secret remains hidden.

> Thanks
>
> Michal
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqNjO0ACgkQBV7eXqefhqin8QCgj/+Gd1byLFPP1RTGjMw/sAvF
KeoAn0NytVk4Z36J5PtZjfSxDPYqwFwI
=yse5
-----END PGP SIGNATURE-----

Re: TPM support status ?

[Michal Suchanek]

2009/8/20 Duboucher Thomas <thomas@duboucher.eu>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Seems that my smtp was down :|
>
> Michal Suchanek a écrit :
>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>> On Thursday 20 August 2009 10:20:02 Michal Suchanek wrote:
>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>> On Thursday 20 August 2009 09:59:42 Michal Suchanek wrote:
>>>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>>>> On Thursday 20 August 2009 09:49:06 Michal Suchanek wrote:
>>>>>>>> 2009/8/20 Michael Gorven <michael@gorven.za.net>:
>>>>>>>>> On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
>>>>>>>>>> Tell me one technical benefit of TPM over coreboot.
>>>>>>>>> Coreboot doesn't provide protected storage of secrets (e.g.
>>>>>>>>> harddrive decryption keys).
>
> It could emulate what a TPM does, however since it starts its job later
> in the boot process, it is far, far less secure (I personnaly would
> consider it useless in this case).
>
>>>>>>>> TPM does not either at the time the BIOS is loaded. Remember, it's
>>>>>>>> the CPU what's running the BIOS, not the TPM chip.
>
>        Just to make some precisions about TPM and its uses (or at least, as
> far as I understood how they works). The TPM chip is soldered on the LPC
> bus, that is, the same bus where the SuperIO (keyboard controller) and
> the BIOS ROM are located, under the SouthBridge. During a BootUp phase
> (G2 -> G0), the Core Root of Trusted Measurement, also located on the
> LPC bus, wake up and initialize the TPM. It measures itself (firmware,
> configuration, ...), then it measures the BIOS ROM. When these
> operations are completed, the BIOS is then executed by the processor and
> the system boots up. Other elements being measured later are the
> CPU/NB/SB/SuperIO microcode/configuration and the BIOS configuration. I
> don't have a lot more details on these stages since I haven't acess to
> the whole specifications, nor I am a PC guru. You can check this if you
> have a TPM enabled computer by dumping the content of
> /sys/kernel/security/tpmX/ on your securityfs.
>        These steps contribute in creating what is called a "trusted platform"
> composed of "trusted elements" within "trust boundary" (yep, that's a
> lot of trust). This means that when the first IPL is loaded, you can
> check wether the system has been tampered or not, the TPM state being
> the "image" of the system (or as close as it can be).
> Because trust is transitive, you end up with a complete system that you
> can "trust", because the TPM can be considered as being a "trusted third
> party".
>        The easiest known attack on TPM is intercepting data on the LPC bus.
> Because it can't be trusted (the bus), you could put some controller
> (like FPGAs) between the TPM and the bus (with some dirty work). Then
> using an altered boot loader (i.e. Stoned), making the system boot
> normaly, except that you would intercept the measure of the malicious
> boot loader and replace it by the measure of the old boot loader. You
> can keep the original series of measure to make the TPM believe the
> system hasn't been tampered and you'll end up discovering the shared
> secret the TPM was holding without the user being able to notice the
> system integrity was compromised. Well, that require a lot of dirty work
> and wires, but it works. ;)
>        However, later chips, like Intel's iTPM tries to integrate the BIOS ROM
> and the TPM within the SouthBridge, removing the LPC bus, the untrusted
> part. Also, TPM are watching closely the LPC bus (such as trying to
> detect clock variations).
>

Ok, thanks for clarifying this.

On platforms that integrate a TPM chip properly it should be started
before the BIOS and thus it can check the integrity of the BIOS which
is something coreboot cannot do.

The manufacturers could include any decent crypto solution in the
platform but they included a crippled chip designed for DRM schemes so
that's what we have.

Thanks

Michal

Re: TPM support status ?

[Robert Millan]

On Thu, Aug 20, 2009 at 09:41:54AM +0200, Michael Gorven wrote:
> On Wednesday 19 August 2009 21:21:28 Michal Suchanek wrote:
> > Tell me one technical benefit of TPM over coreboot.
> 
> Coreboot doesn't provide protected storage of secrets (e.g. harddrive 
> decryption keys).

Note that coreboot itself is not a complete firmware, it's a framework
that can be combined with other components, like GRUB, to produce a
bootloader-class firmware.

With your help, coreboot+GRUB may well support encrypted hard drives.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: TPM support status ?

[Robert Millan]

On Wed, Aug 19, 2009 at 06:33:52PM +0200, Duboucher Thomas wrote:
> > 2) Ethical Aspects
> > ==================
> > 
> Every technology has its evil uses, so does TPM.

TPM considers "remote attestation" is a feature.  It's not bad chance it has
evil uses, it was specifically designed with those in mind.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."