A _good_ and valid use for TPM

A _good_ and valid use for TPM

[Alex Besogonov]

I know that TPM has been mentioned several times on this list. With
absolutely inadequate knee-jerk reactions from GRUB developers :(

Currently I have a problem - I need to protect confidential private
data (we try to protect privacy of our customers) from the _physical_
theft of the server. A simple full hard drive encryption should work
just fine except for one small detail - there's nobody to enter the
password when server reboots.

I've solved this by adding an intermediate system which connects to
another server (which I consider physically secure), retrieves
decryption key and does kexec into the real OS passing this key as a
parameter. So I can just delete the key from the secure server to stop
the physically insecure sever from booting, it'll then be useless for
attackers since there's no decryption key present on it.

However, it would be fairly trivial for attacker to steal the server
and/or make a full copy of its hard drive and then modify intermediate
system to print the decryption key. Not good. And there's no way to
solve it in software, since attacker can trivially change the
bootloader.

So I've added another layer of security - I use TPM to remotely attest
that the bootloader and the intermediate system is not modified. It
requires chain of trust from BIOS to the intermediate system. So if
attacker tries to modify bootloader or intermediate system image - TPM
will not provide keys for communication with the secure server.

Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed
to GNU gods then I can still retrieve all data because the main
decryption key is NOT kept in the TPM module (TPM is only used to
attest integrity of the system). Also, this is not a DRM scheme.

So... Why not add TPM patches into the mainline GRUB2 project? GPLv3
protects nicely against the possible DRM misuse of GRUB2 and TPM. Also
I can assist in forward-porting of 'Trusted GRUB' patch.

Re: A _good_ and valid use for TPM

[phcoder]

I don't know much about TPM but from example that I read at 
TreacherousGrub website actual verification is done by TreachorousGrub. 
I don't see how such a verification can protect against anything.
If you suppose that your attacker is unable to tamper the hardware then 
bios and grub password is all you need. If you suppose that he can then 
you can't even trust your ram modules. It can be tampered in many ways 
like serving hacked bootloader or just being non-volatile then an 
attacker can read the key from memory.
FSF acknowledges that treacherouscomputing may offer minor advantages 
but dissmisses the technology as whole and I agree with them.
However, I'm neither a grub maintainer nor fsf representative.
Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> I know that TPM has been mentioned several times on this list. With
> absolutely inadequate knee-jerk reactions from GRUB developers :(
> 
> Currently I have a problem - I need to protect confidential private
> data (we try to protect privacy of our customers) from the _physical_
> theft of the server. A simple full hard drive encryption should work
> just fine except for one small detail - there's nobody to enter the
> password when server reboots.
> 
> I've solved this by adding an intermediate system which connects to
> another server (which I consider physically secure), retrieves
> decryption key and does kexec into the real OS passing this key as a
> parameter. So I can just delete the key from the secure server to stop
> the physically insecure sever from booting, it'll then be useless for
> attackers since there's no decryption key present on it.
> 
> However, it would be fairly trivial for attacker to steal the server
> and/or make a full copy of its hard drive and then modify intermediate
> system to print the decryption key. Not good. And there's no way to
> solve it in software, since attacker can trivially change the
> bootloader.
> 
> So I've added another layer of security - I use TPM to remotely attest
> that the bootloader and the intermediate system is not modified. It
> requires chain of trust from BIOS to the intermediate system. So if
> attacker tries to modify bootloader or intermediate system image - TPM
> will not provide keys for communication with the secure server.
> 
> Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed
> to GNU gods then I can still retrieve all data because the main
> decryption key is NOT kept in the TPM module (TPM is only used to
> attest integrity of the system). Also, this is not a DRM scheme.
> 
> So... Why not add TPM patches into the mainline GRUB2 project? GPLv3
> protects nicely against the possible DRM misuse of GRUB2 and TPM. Also
> I can assist in forward-porting of 'Trusted GRUB' patch.
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: A _good_ and valid use for TPM

[Alex Besogonov]

On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz <janalsenz@student.ethz.ch> wrote:
> I've recently started porting TrustedGRUB (
> http://sourceforge.net/projects/trustedgrub ) to GRUB2.
> I didn't get too far as I don't have too much time right now, but I managed to
> complete the MBR bootloader.
Great! MBR is the most scary part :)

> I agree with you on the usefulness of a TPM for disk encryption and have a
> similar scheme planned.
> Regardless of the outcome of the discussion on the mailing list I would be
> interested in a "trusted" GRUB2 version. Maybe we could join forces?
Absolutely. I just hate doing work that won't appear in the mainline version :(

> BTW, the "manufacturer key" everyone is talking about is usually referred to as
> "endorsement key", which is generated during production (and whose private part
> is considered possibly in the possession of the manufacturer). I heard, that
> some newer TPM versions support reinitializing this key, but I'm not sure of
> that.
Uhm... TPM_CreateEndorsementKeyPair can be used to create the
endorsement key pair, and the spec also says that TPM chip _must_ ship
with empty endorsement key. It also can later be changed.

> And you do loose the ability to do remote attestation with "official"
> entities, if you do it.
Well, I don't care about that. And in any case, no-one uses TPM for
'official' purposes.

Re: A _good_ and valid use for TPM

[phcoder]

First of all your system is still totally vulnerable to emanation and 
power analysis or hw tampering. By reflashing bios one can bypass all 
tpm protections (don't say it's difficult because it's closed source and 
so on. Look at all closed source obfuscations/pseudo-protections that 
get cracked every day)
Personally if tpm support is merged into mainline grub2 I'll stop using 
it. However what you request doesn't need tpm. Authenticity of modules, 
configuration files and so on can be verified by one of 4 methods:
1) internal signatures
2) file in signed gpg container
3) detached signatures
4) signed hash file
First three goals can be achieved by adding a layer similar to gzio
behaviour of checking can be controlled by environment variables and 
flags passed to
grub_signed_file_open (filename, flags);
First advantage is that you can override it manually supplying grub password
When signature module isn't loaded then this function is available as a 
dummy (all files are unsigned/wrong signature).
Public key can be embedded in signature module. When loaded signature 
module sets strict signing policy which can be then overriden by 
variable (to set such a variable you need either password or a command 
in signed grub.cfg)
Then these modules can be embedded in core.img. In this case if core.img 
is untampered everything is verified. Ensuring integrity of core.img is 
platform-dependent. Some platforms (openfirmware, efi, ...) load 
core.img directly and if they have an ability to check the boot image 
it's straightforward. I haven't thought yet how to do it in limited 
space of mbr. In coreboot scenario it's even the best bet. You can put 
grub2 in rom and if you use rom instead of flashrom it's a wonderful 
solution. But even if you use flash rom your security is similar to 
scenario you propose  since as I said at the begining modyfiing flash 
bios you can bypass tpm scenario
Advantage of this approach is the ability to safely update over network
Forth goal can be achieved with usage of first part and function similar 
to sha1sum or whirlpoolsum (my prefered hash)
Another idea: for some partitions (e.g. system partitions) signatures or 
mac can be much better. btrfs supports checksumming of data and 
metadata. Add mac support is easy. Signatures are more delicate I'm 
looking for compact and fast signatures.
I personally would be interested in implementing security features in 
grub2 as long as tpm stays away

Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz <janalsenz@student.ethz.ch> wrote:
>> I've recently started porting TrustedGRUB (
>> http://sourceforge.net/projects/trustedgrub ) to GRUB2.
>> I didn't get too far as I don't have too much time right now, but I managed to
>> complete the MBR bootloader.
> Great! MBR is the most scary part :)
> 
>> I agree with you on the usefulness of a TPM for disk encryption and have a
>> similar scheme planned.
>> Regardless of the outcome of the discussion on the mailing list I would be
>> interested in a "trusted" GRUB2 version. Maybe we could join forces?
> Absolutely. I just hate doing work that won't appear in the mainline version :(
> 
>> BTW, the "manufacturer key" everyone is talking about is usually referred to as
>> "endorsement key", which is generated during production (and whose private part
>> is considered possibly in the possession of the manufacturer). I heard, that
>> some newer TPM versions support reinitializing this key, but I'm not sure of
>> that.
> Uhm... TPM_CreateEndorsementKeyPair can be used to create the
> endorsement key pair, and the spec also says that TPM chip _must_ ship
> with empty endorsement key. It also can later be changed.
> 
>> And you do loose the ability to do remote attestation with "official"
>> entities, if you do it.
> Well, I don't care about that. And in any case, no-one uses TPM for
> 'official' purposes.
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: A _good_ and valid use for TPM

[Colin D Bennett]

On Thu, 19 Feb 2009 16:05:10 +0100
phcoder <phcoder@gmail.com> wrote:

> Personally if tpm support is merged into mainline grub2 I'll stop using 
> it. However what you request doesn't need tpm. Authenticity of modules, 
> configuration files and so on can be verified by one of 4 methods:
> 1) internal signatures
> 2) file in signed gpg container
> 3) detached signatures
> 4) signed hash file

While TPM may open a door for corporations to prevent machine owners
from having control over their machines, in this instance I do not see
another way to solve Alex's problem.

To restate the problem:

1. The disk must be encrypted.
2. The system must be able to boot without human interaction.  That is,
   a user cannot be prompted for a passphrase or key.

The solution using TPM, as I understand it, essentially puts the
encryption key into tamper-resistant memory in the TPM module, and
supports integrity verification of the system, including the software
on the hard disk, at load time.

It sounds like any solution to problem points (1) and (2) would require
some sort of tamper-resistant module to store the key and handle the
first level of verification (to verify the initial code loaded from
disk).  From that point on, the verified boot sector code can read the
encryption key and verify the next-higher level of software, and so on.

The evil part of TPM seems to be when a person buys a computer but the
computer is locked down with a key not provided to the buyer.

Regards,
Colin

Re: A _good_ and valid use for TPM

[phcoder]

As I understand from his letters and from a quick look at tgrub all he 
needs is to ensure the chain of verification. It seems that tgrub never 
reads tpm key. Even if we one finds tpm acceptable way to check OS 
integrity I don't see why we would rely on it if more universal approach 
is possible
I outlined how it can be checked that if core.img is untampered then OS 
isn't tampered with. I also think I might have a way to extend this 
chain back to mbr by using following ideas:
1) padding in sha1 isn't necessarry in this case since we always load 
fixed amount of sectors.
2) BPB blocks can be reclaimed. If grub boot is in partition then mbr 
may haven't checked it
3) only one read is necessary in first sector. All real reading function 
can be moved to loaded sector. So only sha1 implementation is really 
needed to be done in mbr.
4) I find it very important that the verification can be overriden by 
manually giving password. This probably won't be possible so I propose 
to make 2 mbrs: one with all features current mbr has (the default one) 
and another basic one (e.g. no chs) but with sha1 in it. Default to use 
is the first one but a user may explicitely override it

> 1. The disk must be encrypted.
> 2. The system must be able to boot without human interaction.  That is,
>    a user cannot be prompted for a passphrase or key.
The both goals together are theoretically unachievable technics like 
replacing ram (or gpu memory) with non-volatile storage is always 
available or the method of additional energy. All tpm does is to store 
it in obfuscated way and providing access to it in clear way if some 
conditions are met.
Ideally this condition is B="my system is untampered"
BIOS has the duty to verify the condition A="mbr is untampered"

So actually what he needs is that grub ensures (A=>B)
Intermediary condition is "core.img" is untampered. I already outlined 
how to ensure C=>B without any sacrifices. Ensuring A=>C may require 
some sacrifices that's why I propose to have two versions of mbr sector.
I find that the feature A=>B / C=>B is useful also in many ways not 
limited to tpm scenarios. Look at the following case:
One has installed grub locally on small disk or in flash memory (e.g. 
coreboot) in otherwise lightweight terminal. Now he wants to boot the OS 
from remote server over unsecure network.

In the same time he can always choose to boot unsigned OS by providing 
his password
Regards
Vladimir 'phcoder' Serbinenko

Re: A _good_ and valid use for TPM

[Robert Millan]

On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote:
> 
> While TPM may open a door for corporations to prevent machine owners
> from having control over their machines, in this instance I do not see
> another way to solve Alex's problem.

There's an easy way out of this.  Simply verify data integrity from the
flash chip, and make sure nobody can write to the flash chip.

You can archieve the first by e.g. installing coreboot/GRUB there and
add some crypto support to it.

You can archieve the second by cutting the WE wire, or by dumping lots of
concrete over your board.  Yes, this is a gazillon times more secure than
a TPM.  TPMs are vulnerable to reverse engineering.

> The evil part of TPM seems to be when a person buys a computer but the
> computer is locked down with a key not provided to the buyer.

Precisely.  If it came with a key that is known to the buyer (e.g. printed
on paper), or with an override mechanism that is only accessible to its
legitimate buyer, there would be no problem with it.

But AFAICT there are no TPMs that do this.  It probably even violates the
spec.

-- 
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: A _good_ and valid use for TPM

[phcoder]

And in this scenario the encryption key would also be in flash. Since 
you can't boot unchecked software and normal linux security wouldn't 
allow you to read flash unless you have the root password you can't 
recover the key
Regards
Vladimir 'phcoder' Serbinenko
Robert Millan wrote:
> On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote:
>> While TPM may open a door for corporations to prevent machine owners
>> from having control over their machines, in this instance I do not see
>> another way to solve Alex's problem.
> 
> There's an easy way out of this.  Simply verify data integrity from the
> flash chip, and make sure nobody can write to the flash chip.
> 
> You can archieve the first by e.g. installing coreboot/GRUB there and
> add some crypto support to it.
> 
> You can archieve the second by cutting the WE wire, or by dumping lots of
> concrete over your board.  Yes, this is a gazillon times more secure than
> a TPM.  TPMs are vulnerable to reverse engineering.
> 
>> The evil part of TPM seems to be when a person buys a computer but the
>> computer is locked down with a key not provided to the buyer.
> 
> Precisely.  If it came with a key that is known to the buyer (e.g. printed
> on paper), or with an override mechanism that is only accessible to its
> legitimate buyer, there would be no problem with it.
> 
> But AFAICT there are no TPMs that do this.  It probably even violates the
> spec.
> 

Re: A _good_ and valid use for TPM

[Jan Alsenz]

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

Robert Millan wrote:
> On Thu, Feb 19, 2009 at 07:38:36AM -0800, Colin D Bennett wrote:
>> While TPM may open a door for corporations to prevent machine owners
>> from having control over their machines, in this instance I do not see
>> another way to solve Alex's problem.
> 
> There's an easy way out of this.  Simply verify data integrity from the
> flash chip, and make sure nobody can write to the flash chip.
> 
> You can archieve the first by e.g. installing coreboot/GRUB there and
> add some crypto support to it.
> 
> You can archieve the second by cutting the WE wire, or by dumping lots of
> concrete over your board.  Yes, this is a gazillon times more secure than
> a TPM.  TPMs are vulnerable to reverse engineering.
Everything is vulnerable to reverse engineering.
The problem with a TPM is not, that it uses bad/proprietary crypto, but as you
state, that you can't own it completely.

>> The evil part of TPM seems to be when a person buys a computer but the
>> computer is locked down with a key not provided to the buyer.
> 
> Precisely.  If it came with a key that is known to the buyer (e.g. printed
> on paper), or with an override mechanism that is only accessible to its
> legitimate buyer, there would be no problem with it.
> 
> But AFAICT there are no TPMs that do this.  It probably even violates the
> spec.
I also haven't seen a TPM that does it, but it is in the specs - called a
revocable endorsement key - as an optional feature...

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Michal Suchanek]

2009/2/19 phcoder <phcoder@gmail.com>:
> First of all your system is still totally vulnerable to emanation and power
> analysis or hw tampering. By reflashing bios one can bypass all tpm
> protections (don't say it's difficult because it's closed source and so on.
> Look at all closed source obfuscations/pseudo-protections that get cracked
> every day)

This is interesting. I have not thought about the way the BIOS is
protected from tampering. You can probably read the BIOS and verify
the signature with the TPM chip but there is nothing that can attest
the machine actually used this BIOS for booting.

Since the BIOS is not stored in the TPM chip and must be able to reset
the TPM  chip into a good state at least when the power is removed
from the board it must be possible to not use the BIOS at all and
leave the TPM chip in good or resettable state.

The hard part is initializing the hardware without the use of the
original BIOS - the specifics of initializing various chips are not
public, and probably depend on companion hardware and/or trace length
on the particular board as well.


Thanks

Michal

Re: A _good_ and valid use for TPM

[phcoder]

> The hard part is initializing the hardware without the use of the
> original BIOS - the specifics of initializing various chips are not
> public, and probably depend on companion hardware and/or trace length
> on the particular board as well.
It's not actually needed. If one can nop tpm code in bios then he can 
boot from anything and read tpm keys. You don't need to understand the 
whole bios to do it. Of course it's obfuscated but obfuscation isn't a 
security in any way. Also if you write completely different code to 
flash bios you don't need to be able to initialise the whole hardware 
all you need is being able to read tpm and write to serial port. Then 
you can simply read the key at your serial console. Actually bios isn't 
protected. It's just obfuscated.
Regards
Vladimir 'phcoder' Serbinenko

Re: A _good_ and valid use for TPM

[Robert Millan]

On Wed, Feb 18, 2009 at 11:10:22AM +0200, Alex Besogonov wrote:
> I know that TPM has been mentioned several times on this list. With
> absolutely inadequate knee-jerk reactions from GRUB developers :(

As far as I can recall, I think all my replies explaining why TPMs are a
serious threat to our freedom were polite and respectful.  Please think
twice before labeling a reply you disagree with as
"inadequate knee-jerk reaction", or it will be impossible to have a
reasonable discussion over this issue.

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

>I don't know much about TPM but from example that I read at
>TreacherousGrub website actual verification is done by TreachorousGrub.
>I don't see how such a verification can protect against anything.
Wrong. The main concept in TPM is "chain of trust".

First, BIOS attests that the first stage of GRUB is not tampered with.
If it's somehow modified then the chain of trust is broken and keys in
the TPM are locked. Then the first stage (which is by now checked to
be real and unmodified) loads and checks the second stage. And so
on...

There's no way to break this chain of trust without hacking TPM (which
I consider very unlikely), doing uber-dirty hardware tricks (like
modifying RAM on-the-fly using DMA from rogue PCI devices) or
exploiting some local vulnerability (which is rather unlikely).

>If you suppose that your attacker is unable to tamper the hardware then
>bios and grub password is all you need. If you suppose that he can then
>you can't even trust your ram modules. It can be tampered in many ways
>like serving hacked bootloader or just being non-volatile then an
>attacker can read the key from memory.
I'm trying to guard against attacker who can _steal_ the server itself
and/or tamper with the hardware.

PS: please, at least read the relevant specs before calling TPM 'Treacherous'.

Re: A _good_ and valid use for TPM

[Isaac Dupree]

Alex Besogonov wrote:
> There's no way to break this chain of trust without hacking TPM (which
> I consider very unlikely)

fair to say "unlikely"

> doing uber-dirty hardware tricks (like
> modifying RAM on-the-fly using DMA from rogue PCI devices)

yeah, it's probably technically possible, but enough work to do that it's not 
worth guarding against.

But guess what?  While your system is running, they can take out your RAM and 
read it (disk-encryption key and all) before the RAM forgets its contents, see 
e.g.
http://blogs.zdnet.com/security/?p=900

> or
> exploiting some local vulnerability (which is rather unlikely).

maybe.  But how do you patch security vulnerabilities in e.g. the GRUB 
install, if modification = tampering?  (I guess there's a way to do it, 
though.)

> >If you suppose that your attacker is unable to tamper the hardware then
> >bios and grub password is all you need. If you suppose that he can then
> >you can't even trust your ram modules. It can be tampered in many ways
> >like serving hacked bootloader or just being non-volatile then an
> >attacker can read the key from memory.
>
> I'm trying to guard against attacker who can _steal_ the server itself
> and/or tamper with the hardware.

which is very difficult.  Why do you have to reboot, though? and is there some 
way you can store the key locally in those cases, without compromising it 
further?

> PS: please, at least read the relevant specs before calling TPM
> 'Treacherous'.

the ones that say to keep the keys in the hands of the manufacturers?(no I 
haven't read the specs either, maybe Robert Millan has though)

-Isaac

Re: A _good_ and valid use for TPM

[Alex Besogonov]

On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree
<ml@isaac.cedarswampstudios.org> wrote:
> Alex Besogonov wrote:
> But guess what?  While your system is running, they can take out your RAM and
> read it (disk-encryption key and all) before the RAM forgets its contents, see
> e.g. http://blogs.zdnet.com/security/?p=900
I know. But there's no way to guard against this attack, so there's no
sense fretting over it for now.

>> or
>> exploiting some local vulnerability (which is rather unlikely).
> maybe.  But how do you patch security vulnerabilities in e.g. the GRUB
> install, if modification = tampering?  (I guess there's a way to do it,
> though.)
Yes, there are ways to do this. They require additional credentials
(which won't be available for attackers), of course.

>> I'm trying to guard against attacker who can _steal_ the server itself
>> and/or tamper with the hardware.
> which is very difficult.  Why do you have to reboot, though?
Power failure, kernel panic, someone accidentally kicking the power cord, etc.

10-15 minutes of downtime for reboot are acceptable, but several
hours, required to dispatch administrator with enough access rights to
boot the server, are not.

> and is there someway you can store the key locally in those cases, without
> compromising it further?
I can't think of one. I'm open to suggestions, though :)

>> PS: please, at least read the relevant specs before calling TPM
>> 'Treacherous'.
> the ones that say to keep the keys in the hands of the manufacturers?(no I
> haven't read the specs either, maybe Robert Millan has though)
So far every TPM I tried can be fully controlled by me. I also don't
remember bits of specs saying about keeping keys in the hands of
manufacturers.

Of course, TPM in theory can be used to lock down your computer, but I
doubt that in this case DRM Mafiaa is going to consider using GRUB to
do this. Also, projects like SELinux can then be used to lock down
your computer even further, but somehow we don't see Richard Stallman
battling SELinux folks.

Maybe we can just rename TPM to 'Secure Key Storage'?

Re: A _good_ and valid use for TPM

[Isaac Dupree]

Alex Besogonov wrote:
> On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree
>
> <ml@isaac.cedarswampstudios.org> wrote:
> > Alex Besogonov wrote:
> > But guess what?  While your system is running, they can take out your RAM
> > and read it (disk-encryption key and all) before the RAM forgets its
> > contents, see e.g. http://blogs.zdnet.com/security/?p=900
>
> I know. But there's no way to guard against this attack, so there's no
> sense fretting over it for now.

well, it's relatively straightforward for an attacker who knows what they're 
doing, so perhaps you should assume that *privacy* is at least partly 
compromised.

but the most that attack can achieve is observing?  Can that attack make it so 
that, when the system starts running again, it will be in a compromised state?
- they can steal all crypto identity keys and try to run a completely different 
computer with different software there, if not for TPM
- I don't know how the magic of TPM knowing everything about the state of your 
computer works, maybe they can modify what's in memory and put it back and 
confuse things?

Also why does GRUB need to do any explicit interaction with TPM?  (I'm 
ignorant and unimportant here, but maybe it will edify people, to have this 
conversation.)

-Isaac

Re: A _good_ and valid use for TPM

[Alex Besogonov]

On Thu, Feb 19, 2009 at 12:03 AM, Isaac Dupree
<ml@isaac.cedarswampstudios.org> wrote:
>> I know. But there's no way to guard against this attack, so there's no
>> sense fretting over it for now.
> well, it's relatively straightforward for an attacker who knows what they're
> doing, so perhaps you should assume that *privacy* is at least partly
> compromised.
I think there are ways to guard against this attack. There's 'freeze
CPU cache' method and I'm also thinking about using GPU to perform
decryption - this way decryption keys won't be in the main memory.

For now, I'm just planning to glue memory chips to the mainboard using
epoxy resin. It'll make life much harder for the attacker.

> but the most that attack can achieve is observing?  Can that attack make it so
> that, when the system starts running again, it will be in a compromised state?
Attackers can steal decryption keys, connect hard drives from my
computer to their computer and then copy everything.

> - they can steal all crypto identity keys and try to run a completely different
> computer with different software there, if not for TPM
> - I don't know how the magic of TPM knowing everything about the state of your
> computer works, maybe they can modify what's in memory and put it back and
> confuse things?
No. TPM is a passive chip.

It might be possible to use TPM as a hardware decryptor, but it's too
slow to handle full-disk encryption.

> Also why does GRUB need to do any explicit interaction with TPM?  (I'm
> ignorant and unimportant here, but maybe it will edify people, to have this
> conversation.)
BIOS is only able to attest that the first stage of GRUB (512-byte
MBR) is not compromized. First stage then has to check the second
stage and so on. So unmodified GRUB will happily load a compromised
second stage even if the first stage is attested to be not modified.

Re: A _good_ and valid use for TPM

[Alex Besogonov]

>First of all your system is still totally vulnerable to emanation and
>power analysis or hw tampering.
Yes, but that's way too hard.

>By reflashing bios one can bypass all
>tpm protections (don't say it's difficult because it's closed source and
>so on. Look at all closed source obfuscations/pseudo-protections that
>get cracked every day)
That's possible, but again I consider this not critical. BIOS itself
is checksummed and checked by the root of trust.

>Personally if tpm support is merged into mainline grub2 I'll stop using
>it.
Why?

>However what you request doesn't need tpm. Authenticity of modules,
>configuration files and so on can be verified by one of 4 methods:
>1) internal signatures
>2) file in signed gpg container
>3) detached signatures
>4) signed hash file
Won't work.

For example, attacker can run everything inside a hypervisor and then
just dump memory and extract decryption keys. You have no reliable
ways to detect hypervisor from inside the running OS. You can pile
layers upon layers of integrity checks, but they are useless if
hardware itself is not trusted.  TPM allows me to establish this
trust.

Actually, I can probably even formally prove this assumption.

>First advantage is that you can override it manually supplying grub password
Administrator can manually override TPM by supplying the decryption
key directly instead of fetching them from my key server.

[skipped because this scheme just won't work]

>I personally would be interested in implementing security features in
>grub2 as long as tpm stays away
Then that's a religion, not engineering.

PS: please, can you CC me when you answer my posts?

Re: A _good_ and valid use for TPM

[phcoder]

Alex Besogonov wrote:
>> First of all your system is still totally vulnerable to emanation and
>> power analysis or hw tampering.
> Yes, but that's way too hard.

Sure? There was a demonstration when rsa key was recovered just by 
plotting variations on powerline of usb port
And what about cache attack?

>> By reflashing bios one can bypass all
>> tpm protections (don't say it's difficult because it's closed source and
>> so on. Look at all closed source obfuscations/pseudo-protections that
>> get cracked every day)
> That's possible, but again I consider this not critical. BIOS itself
> is checksummed and checked by the root of trust.
Isn't bios (or part of it) the root of "trust"
> 
>> Personally if tpm support is merged into mainline grub2 I'll stop using
>> it.
> Why?
Because I don't want support this technology. 
TPM=obfuscation=unsecurity. And as an opensource and open security fan I 
can't claim to have solved an impossible problem. But if you want to use 
obfuscation schemes it's your right
> Won't work.
> 
> For example, attacker can run everything inside a hypervisor and then
> just dump memory and extract decryption keys. You have no reliable
> ways to detect hypervisor from inside the running OS. You can pile
> layers upon layers of integrity checks, but they are useless if
> hardware itself is not trusted.  TPM allows me to establish this
> trust.
You assume that noone will develop hypervisor able to fool tpm bios. One 
could powercut the tpm chip (similar to how a resistor is remove to 
avoid burning efuses in xbox) then power would be reestablished to it 
and bios would be executed on hypervisor which will retrieve the keys. 
Actually you can trust tpm only as much as you trust in obfuscation 
power of bios. Only obfuscation prevents attacker from disconnecting tpm 
and reading keys from it. And there are only few types of tpm. Sooner or 
later someone will figure their interface. Then it can be read by 
special usb adapter
> 
> Actually, I can probably even formally prove this assumption.
> 
I really don't see you point. With my proposition mbr still can be 
verified by tpm but grub2 needs to know nothing about tpm as long as it 
ensures it doesn't load any unsigned modules. This approach is more 
versatile. It can be used also for e.g. checking that debian install is 
really from debian. And having experience with manufacturers supplying 
buggy hw and sw  tend to avoid solutions directly relying on hardware 
when another implementation is possible
Which collaboration other than not loading anything unchecked does your 
scheme need from grub?
 From readme of trustedgrub the only thing it does is checking integrity
>> First advantage is that you can override it manually supplying grub password
> Administrator can manually override TPM by supplying the decryption
> key directly instead of fetching them from my key server.
> 
> [skipped because this scheme just won't work]
> 
>> I personally would be interested in implementing security features in
>> grub2 as long as tpm stays away
> Then that's a religion, not engineering.
Tell it what you want but I don't trust code that I can't verify. And 
tpm is root of obfuscation.
> 
> PS: please, can you CC me when you answer my posts?
Could you come to irc channel or meet me at jabber/gtalk?
Regards
Vladimir 'phcoder' Serbinenko

Re: A _good_ and valid use for TPM

[Alex Besogonov]

On Thu, Feb 19, 2009 at 9:30 PM, phcoder <phcoder@gmail.com> wrote:
>> Yes, but that's way too hard.
> Sure? There was a demonstration when rsa key was recovered just by plotting
> variations on powerline of usb port
TPM performs encoding/decoding, and I consider it secure.

I don't think it's possible to recover the symmetric key used later
during normal system operation.

> And what about cache attack?
You mean frozen memory chip attack?

>> That's possible, but again I consider this not critical. BIOS itself
>> is checksummed and checked by the root of trust.
> Isn't bios (or part of it) the root of "trust"
As far as I understand - no.

>> Why?
> Because I don't want support this technology. TPM=obfuscation=unsecurity.
No. TPM is just a secure way to store keys, nothing more. It can be
used for good and bad.

> And as an opensource and open security fan I can't claim to have solved an
> impossible problem. But if you want to use obfuscation schemes it's your
> right
I want a reasonably secure scheme that DOESN'T use obfuscation.

> You assume that noone will develop hypervisor able to fool tpm bios. One
> could powercut the tpm chip (similar to how a resistor is remove to avoid
> burning efuses in xbox) then power would be reestablished to it and bios
> would be executed on hypervisor which will retrieve the keys.
Would not work. Or rather it'll require uber-precise timing, a lot of
soldering and access to private data of the mainboard developer.

> Actually you
> can trust tpm only as much as you trust in obfuscation power of bios. Only
> obfuscation prevents attacker from disconnecting tpm and reading keys from
> it. And there are only few types of tpm. Sooner or later someone will figure
> their interface. Then it can be read by special usb adapter
TPMs are fairly well engineered, it requires several magnitudes more
time to crack it than any pure software security system.

>> Actually, I can probably even formally prove this assumption.
> I really don't see you point. With my proposition mbr still can be verified
> by tpm but grub2 needs to know nothing about tpm as long as it ensures it
> doesn't load any unsigned modules.
First, I don't think it's possible to implement SHA-1 hashing in MBR -
there's probably just not enough space left in 512-byte code segment
for that.

Second, the only safe action non TPM-aware MBR can perform if it
detects tampering is just shutting down hard. Everything else is
dangerous.

Third, it would be nice to be able to measure (attest integrity) of
other files, but that's just nice and not really necessary.

> This approach is more versatile. It can
> be used also for e.g. checking that debian install is really from debian.
> And having experience with manufacturers supplying buggy hw and sw  tend to
> avoid solutions directly relying on hardware when another implementation is
> possible
TPM will be used in the most minimalistic way possible. I'll even add
pure software signature checking support (which can be useful for
another purposes like checking that kernel is not damaged, etc.).

> Which collaboration other than not loading anything unchecked does your
> scheme need from grub?
Mainly, communicating with TPM in MBR to tell it that the next stage
has passed checks.

> From readme of trustedgrub the only thing it does is checking integrity
Yes.

>> PS: please, can you CC me when you answer my posts?
> Could you come to irc channel or meet me at jabber/gtalk?
Feel free to contact me on Alex.Besogonov _atttttttt___ gmail.com in Jabber.

Re: A _good_ and valid use for TPM

[Jan Alsenz]

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

Hi!

Alright, lets try to make sure everyone is talking about the same things here.

First of all a TPM is not just some kind of secure memory only accessible from
early BIOS, it basically is a small computer. You can only send it commands, and
it can "decide" to reject them, e.g. if you try to read out the endorsement
private key.
(Of course there is always the chance that the TPM has hidden commands to do
that, or the manufacturer already has the keys anyway)

Next, we need to keep in mind, what kind of attack and attacker we're trying to
defend against.
As I see it we have an attacker with relatively low-tech abilities (he cannot
replace chips, break the TPM physically, or knows it's "dark secrets"), who gets
physical access to the machine. So he is basically limited to flashing the BIOS,
 replacing anything, that is written on a disk, controling the network, etc.
I excluded a higher grade attacker, because, if we have one of these, there is
nothing we can do. Any solution, TPM or not, can be broken under these assumptions.

Now for, what the TPM can do and is SUPPOSED to do according to the specification.
First there is nothing it can do actively, like interrupt or change anything in
the system. It is pretty passive and only acts on request.
The TPM has a number of PCRs (Platform Configuration Registers), where it can
store and concatenate hash values - this is what every stage of a trusted boot
chain has to do.
Every stage has to get a hash of the next one, before it executes it. (The
assumption here is, that the PCRs cannot be tampered with and the stages to it
correctly)
So in the end (after boot) you have a bunch of PCR values, that represent all
the code and data, that was used to boot the system. If you have this and are
sure, that the current configuration is correct, you have a reference value of
the expected system state, which you can use for the following:
- seal a key:
	You can create a key with the TPM and "bind" it to specific values of the PCRs,
so it only en/decrypts with it, if these values match.
	You can encrypt any kind of data with this, but the only useful thing for boot
is to encrypt a cryptographic key needed to further start the system.
- remote attestation:
	The TPM can proof to another party, that the PCRs have certain values (of
course the communication needs to be established by normal software running on
the machine)

The TPM has a few more functions, but I think they are not relevant here.

And now for the ongoing discussion:
(things I didn't comment on should have been answered above)

Alex Besogonov wrote:
> On Thu, Feb 19, 2009 at 9:30 PM, phcoder <phcoder@gmail.com> wrote:
>>> Yes, but that's way too hard.
>> Sure? There was a demonstration when rsa key was recovered just by plotting
>> variations on powerline of usb port
> TPM performs encoding/decoding, and I consider it secure.
> 
> I don't think it's possible to recover the symmetric key used later
> during normal system operation.
It could possibly be done, but that is out of scope here.
Regardless of what you use to establish your trust, if someone can extract the
key for your disk encryption from the running system your screwed.

>> And what about cache attack?
> You mean frozen memory chip attack?
No, cache timing. (search for "aes cache timing")

>>> That's possible, but again I consider this not critical. BIOS itself
>>> is checksummed and checked by the root of trust.
>> Isn't bios (or part of it) the root of "trust"
> As far as I understand - no.
Actually - it is.
Check the "TCG PC Client Specific Implementation Specification for Conventional
Bios" or "TCG PC Specific Implementation Specification" at
https://www.trustedcomputinggroup.org/specs/PCClient/
and look for CRTM (Core Root of Trust for Measurement)

>>> Why?
>> Because I don't want support this technology. TPM=obfuscation=unsecurity.
> No. TPM is just a secure way to store keys, nothing more. It can be
> used for good and bad.
Well, it is a bit more, but it's definitely not just obfuscation. Actually it's
pretty well documented what it's supposed to do (all the specification is
available, there is an open-source emulation implementation of it).
What you are referring to, is that you don't trust it to have ONLY this
functionality, but you can make the same argument for every part of your PC! Are
you sure, there is nothing in your network card, CPU or hard drive, that can be
used against you?

>> And as an opensource and open security fan I can't claim to have solved an
>> impossible problem. But if you want to use obfuscation schemes it's your
>> right
> I want a reasonably secure scheme that DOESN'T use obfuscation.
> 
>> You assume that noone will develop hypervisor able to fool tpm bios. One
>> could powercut the tpm chip (similar to how a resistor is remove to avoid
>> burning efuses in xbox) then power would be reestablished to it and bios
>> would be executed on hypervisor which will retrieve the keys.
> Would not work. Or rather it'll require uber-precise timing, a lot of
> soldering and access to private data of the mainboard developer.
> 
>> Actually you
>> can trust tpm only as much as you trust in obfuscation power of bios. Only
>> obfuscation prevents attacker from disconnecting tpm and reading keys from
>> it. And there are only few types of tpm. Sooner or later someone will figure
>> their interface. Then it can be read by special usb adapter
> TPMs are fairly well engineered, it requires several magnitudes more
> time to crack it than any pure software security system.
> 
>>> Actually, I can probably even formally prove this assumption.
>> I really don't see you point. With my proposition mbr still can be verified
>> by tpm but grub2 needs to know nothing about tpm as long as it ensures it
>> doesn't load any unsigned modules.
> First, I don't think it's possible to implement SHA-1 hashing in MBR -
> there's probably just not enough space left in 512-byte code segment
> for that.
I am very sure of that.

> Second, the only safe action non TPM-aware MBR can perform if it
> detects tampering is just shutting down hard. Everything else is
> dangerous.
Yeah, but an attacker could patch that out too.

> Third, it would be nice to be able to measure (attest integrity) of
> other files, but that's just nice and not really necessary.
> 
>> This approach is more versatile. It can
>> be used also for e.g. checking that debian install is really from debian.
>> And having experience with manufacturers supplying buggy hw and sw  tend to
>> avoid solutions directly relying on hardware when another implementation is
>> possible
> TPM will be used in the most minimalistic way possible. I'll even add
> pure software signature checking support (which can be useful for
> another purposes like checking that kernel is not damaged, etc.).
> 
>> Which collaboration other than not loading anything unchecked does your
>> scheme need from grub?
> Mainly, communicating with TPM in MBR to tell it that the next stage
> has passed checks.
> 
>> From readme of trustedgrub the only thing it does is checking integrity
> Yes.
> 
>>> PS: please, can you CC me when you answer my posts?
>> Could you come to irc channel or meet me at jabber/gtalk?
> Feel free to contact me on Alex.Besogonov _atttttttt___ gmail.com in Jabber.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Alex Besogonov]

On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz <janalsenz@student.ethz.ch> wrote:
[skip]
>        The TPM can proof to another party, that the PCRs have certain values (of
> course the communication needs to be established by normal software running on
> the machine)
Yes, I'm trying to do remote attestation.

> Alex Besogonov wrote:
>> I don't think it's possible to recover the symmetric key used later
>> during normal system operation.
> It could possibly be done, but that is out of scope here.
> Regardless of what you use to establish your trust, if someone can extract the
> key for your disk encryption from the running system your screwed.
Yes, of course.

>>> And what about cache attack?
>> You mean frozen memory chip attack?
> No, cache timing. (search for "aes cache timing")
I don't think it's applicable here.

>> As far as I understand - no.
> Actually - it is.
> Check the "TCG PC Client Specific Implementation Specification for Conventional
> Bios" or "TCG PC Specific Implementation Specification" at
> https://www.trustedcomputinggroup.org/specs/PCClient/
> and look for CRTM (Core Root of Trust for Measurement)
Yes, BIOS is a root of trust, but not the Core Root. BIOS itself is
checked before execution (pages 20 and onwards in the "TCG PC Client
Specific Implementation Specification for Conventional Bios" spec),
even before dynamic memory is initialized.

> What you are referring to, is that you don't trust it to have ONLY this
> functionality, but you can make the same argument for every part of your PC! Are
> you sure, there is nothing in your network card, CPU or hard drive, that can be
> used against you?
Frankly, I don't care. I'm not trying to protect data against NSA or
other three-letter agencies. There should be a limit to paranoia, and
my paranoia ends at the hardware level.

>> First, I don't think it's possible to implement SHA-1 hashing in MBR -
>> there's probably just not enough space left in 512-byte code segment
>> for that.
> I am very sure of that.
Well, I spoke phcoder on Jabber - there might be a way to do this.
He's going to investigate it.

>> Second, the only safe action non TPM-aware MBR can perform if it
>> detects tampering is just shutting down hard. Everything else is
>> dangerous.
> Yeah, but an attacker could patch that out too.
Not if we first measure the MBR. It can be done without any
TPM-specific code in the MBR if I'm not very mistaken.

PS: thanks for detailed explanation!

Re: A _good_ and valid use for TPM

[Jan Alsenz]

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

Alex Besogonov wrote:
[skip]
>>> As far as I understand - no.
>> Actually - it is.
>> Check the "TCG PC Client Specific Implementation Specification for Conventional
>> Bios" or "TCG PC Specific Implementation Specification" at
>> https://www.trustedcomputinggroup.org/specs/PCClient/
>> and look for CRTM (Core Root of Trust for Measurement)
> Yes, BIOS is a root of trust, but not the Core Root. BIOS itself is
> checked before execution (pages 20 and onwards in the "TCG PC Client
> Specific Implementation Specification for Conventional Bios" spec),
> even before dynamic memory is initialized.
Well on page 32 they list two options, how to implement the CRTM:
BIOS Boot Block or entire BIOS
Since the BIOS is usually updateable, it seems that most manufacturers opt for
BIOS Boot Block, which I assume will be something like: "lets put the first
sector of the BIOS in ROM"
(of course it might be something else completely, but I doubt it)

>>> First, I don't think it's possible to implement SHA-1 hashing in MBR -
>>> there's probably just not enough space left in 512-byte code segment
>>> for that.
>> I am very sure of that.
> Well, I spoke phcoder on Jabber - there might be a way to do this.
> He's going to investigate it.
Sounds interesting.

>>> Second, the only safe action non TPM-aware MBR can perform if it
>>> detects tampering is just shutting down hard. Everything else is
>>> dangerous.
>> Yeah, but an attacker could patch that out too.
> Not if we first measure the MBR. It can be done without any
> TPM-specific code in the MBR if I'm not very mistaken.
Could you elaborate on that?
E.g. where do you measure the MBR from?

> PS: thanks for detailed explanation!
Sure, glad I could help!

Greets,

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Alex Besogonov]

Jan Alsenz wrote:
>>> Yeah, but an attacker could patch that out too.
>> Not if we first measure the MBR. It can be done without any
>> TPM-specific code in the MBR if I'm not very mistaken.
> Could you elaborate on that?
> E.g. where do you measure the MBR from?
MBR is automatically measured by the TPM module, it requires no 
intervention from GRUB.

-- 
With respect,
             Alex Besogonov (cyberax@staffdirector.net)

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sun, Feb 22, 2009 at 03:14:07AM +0200, Alex Besogonov wrote:
> Jan Alsenz wrote:
>>>> Yeah, but an attacker could patch that out too.
>>> Not if we first measure the MBR. It can be done without any
>>> TPM-specific code in the MBR if I'm not very mistaken.
>> Could you elaborate on that?
>> E.g. where do you measure the MBR from?
> MBR is automatically measured by the TPM module, it requires no  
> intervention from GRUB.

Well, that is true, but for GRUB to measure all of its own stages
it gets quite complicated.  Overall, from a technical POV it looks
like a lousy approach.  It makes a lot more sense to simply have the
firmware load GRUB as an executable image and measure that IMO.

You can do that easily when you're in a legacy-free environment.

-- 
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: A _good_ and valid use for TPM

[Robert Millan]

On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote:
> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz <janalsenz@student.ethz.ch> wrote:
> [skip]
> >        The TPM can proof to another party, that the PCRs have certain values (of
> > course the communication needs to be established by normal software running on
> > the machine)
> Yes, I'm trying to do remote attestation.

You're confusing things.  I think you simply want to ensure data integrity, and
the TPM doesn't even do that: it simply puts the problem in hands of a third
party.

"remote attestation" is only useful when you want to coerce others into
running your (generaly proprietary) software.  I hope this is not what you
want to do.

> >> First, I don't think it's possible to implement SHA-1 hashing in MBR -
> >> there's probably just not enough space left in 512-byte code segment
> >> for that.
> > I am very sure of that.
> Well, I spoke phcoder on Jabber - there might be a way to do this.
> He's going to investigate it.

This is unnecessary.  Once GRUB supports crypto, it can simply load
itself from an encrypted filesystem on disk.  An image can be of
arbitrary size.

-- 
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: A _good_ and valid use for TPM

[Jan Alsenz]

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

Robert Millan wrote:
> On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote:
>> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz <janalsenz@student.ethz.ch> wrote:
>> [skip]
>>>        The TPM can proof to another party, that the PCRs have certain values (of
>>> course the communication needs to be established by normal software running on
>>> the machine)
>> Yes, I'm trying to do remote attestation.
> 
> You're confusing things.  I think you simply want to ensure data integrity, and
> the TPM doesn't even do that: it simply puts the problem in hands of a third
> party.
> 
> "remote attestation" is only useful when you want to coerce others into
> running your (generaly proprietary) software.  I hope this is not what you
> want to do.
Yes, this is exactly what he tries do to: convince his keyserver, that the
requesting server runs, what it's supposed to.

Which is exactly remote attestation, just in this case he controls both sides,
which I think makes it an interesting use of the technology.


>>>> First, I don't think it's possible to implement SHA-1 hashing in MBR -
>>>> there's probably just not enough space left in 512-byte code segment
>>>> for that.
>>> I am very sure of that.
>> Well, I spoke phcoder on Jabber - there might be a way to do this.
>> He's going to investigate it.
> 
> This is unnecessary.  Once GRUB supports crypto, it can simply load
> itself from an encrypted filesystem on disk.  An image can be of
> arbitrary size.
Ok, but where does it get the key from?
And how can wherever the key comes from be sure that it's talking to GRUB?

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote:
> > 
> > "remote attestation" is only useful when you want to coerce others into
> > running your (generaly proprietary) software.  I hope this is not what you
> > want to do.
> Yes, this is exactly what he tries do to: convince his keyserver, that the
> requesting server runs, what it's supposed to.
> 
> Which is exactly remote attestation, just in this case he controls both sides,
> which I think makes it an interesting use of the technology.

That would be like trying to rob yourself by threatening yourself with a gun,
instead of simply drawing money from your wallet.

If you just want to ensure noone is tampering your box, simply make your box
tamper-proof.  You don't need a protocol to allow third parties to check
anything.

> > This is unnecessary.  Once GRUB supports crypto, it can simply load
> > itself from an encrypted filesystem on disk.  An image can be of
> > arbitrary size.
> Ok, but where does it get the key from?

The public key (or just a hash) can be embedded in GRUB itself.  In the
instance of GRUB that goes to the flash chip, that is.

> And how can wherever the key comes from be sure that it's talking to GRUB?

Because you put it there, and made sure noone can overwrite it afterwards.

-- 
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: A _good_ and valid use for TPM

[Jan Alsenz]

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

Robert Millan wrote:
> On Sat, Feb 21, 2009 at 03:20:39PM +0100, Jan Alsenz wrote:
>>> "remote attestation" is only useful when you want to coerce others into
>>> running your (generaly proprietary) software.  I hope this is not what you
>>> want to do.
>> Yes, this is exactly what he tries do to: convince his keyserver, that the
>> requesting server runs, what it's supposed to.
>>
>> Which is exactly remote attestation, just in this case he controls both sides,
>> which I think makes it an interesting use of the technology.
> 
> That would be like trying to rob yourself by threatening yourself with a gun,
> instead of simply drawing money from your wallet.

Sorry, I don't get that analogy...

> If you just want to ensure noone is tampering your box, simply make your box
> tamper-proof.  You don't need a protocol to allow third parties to check
> anything.

Ok, but if you have such a protocol, only use it for yourself and do trust the
manufacturer, you only have to secure one of your boxes instead of them all,
which is usually much easier.

>>> This is unnecessary.  Once GRUB supports crypto, it can simply load
>>> itself from an encrypted filesystem on disk.  An image can be of
>>> arbitrary size.
>> Ok, but where does it get the key from?
> 
> The public key (or just a hash) can be embedded in GRUB itself.  In the
> instance of GRUB that goes to the flash chip, that is.
> 
>> And how can wherever the key comes from be sure that it's talking to GRUB?
> 
> Because you put it there, and made sure noone can overwrite it afterwards.

Making sure, that noone can override it, can be awfully difficult, especially
under a physical attacker. A hardware that is at least a bit designed to
withstand such an attack can help a lot.

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 04:00:30PM +0100, Jan Alsenz wrote:
> > If you just want to ensure noone is tampering your box, simply make your box
> > tamper-proof.  You don't need a protocol to allow third parties to check
> > anything.
> 
> Ok, but if you have such a protocol, only use it for yourself and do trust the
> manufacturer, you only have to secure one of your boxes instead of them all,
> which is usually much easier.

You only have to secure those boxes you need to be secure.  The method you use
to secure them is irrelevant to that.

> >> And how can wherever the key comes from be sure that it's talking to GRUB?
> > 
> > Because you put it there, and made sure noone can overwrite it afterwards.
> 
> Making sure, that noone can override it, can be awfully difficult, especially
> under a physical attacker. A hardware that is at least a bit designed to
> withstand such an attack can help a lot.

I'm not sure why is physical security so awfully difficult for you (can't you
use locks, tamper-proof seals, cameras and alarms?), but most people who're in
the bussiness of protecting physical goods manage to sort it out.

In any case, if your attacker is that much determined to archieve their goal,
reverse engineering a small chip isn't going to stop them.

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

Robert Millan wrote:
>> Making sure, that noone can override it, can be awfully difficult, especially
>> under a physical attacker. A hardware that is at least a bit designed to
>> withstand such an attack can help a lot.
> I'm not sure why is physical security so awfully difficult for you (can't you
> use locks, tamper-proof seals, cameras and alarms?), but most people who're in
> the bussiness of protecting physical goods manage to sort it out.
My devices will be installed at clients' locations. It's impossible to 
guarantee that all devices will be physically secure.

If you live in the USA then one day such device might contain your 
private data. Would you like it to be stolen?

I'm trying to design them so that data can't be stolen easily. Even by 
me, if someday I become insane because of flame-wars in mailing lists.

> In any case, if your attacker is that much determined to archieve their goal,
> reverse engineering a small chip isn't going to stop them.
Reverse engineering the TPM chip is very costly. And I'm not going to 
try to protect data from NSA or CIA or another three-letter agency.

-- 
With respect,
             Alex Besogonov (cyberax@staffdirector.net)

Re: A _good_ and valid use for TPM

[phcoder]

>> In any case, if your attacker is that much determined to archieve 
>> their goal,
>> reverse engineering a small chip isn't going to stop them.
> Reverse engineering the TPM chip is very costly. And I'm not going to 
> try to protect data from NSA or CIA or another three-letter agency.
On this you have to trust the manufacturer. Actually you can't know how 
difficult reverse-engineering is before you do. And it's only a matter 
of time before some crypto-hardware geek reverse-engineers it because he 
was bored or a crypto-student does it because it gives him an excellent 
diploma. This is quite possible because universities often have the 
necessary equipment and diploma works are supposed to be long and 
difficult. At this point reading a publication and using its results is 
trivial. And look at reverse-engineered opensource drivers. It's just a 
matter of obfuscation and we already know that it brings no security. If 
you want to protect your keys the only ways is to physically protect 
them like putting concrete around the flash chip
Regards
Vladimir 'phcoder' Serbinenko

Re: A _good_ and valid use for TPM

[Michal Suchanek]

On 22/02/2009, phcoder <phcoder@gmail.com> wrote:
> >
> > > In any case, if your attacker is that much determined to archieve their
> goal,
> > > reverse engineering a small chip isn't going to stop them.
> > >
> > Reverse engineering the TPM chip is very costly. And I'm not going to try
> to protect data from NSA or CIA or another three-letter agency.
> >
>  On this you have to trust the manufacturer. Actually you can't know how
> difficult reverse-engineering is before you do. And it's only a matter of
> time before some crypto-hardware geek reverse-engineers it because he was
> bored or a crypto-student does it because it gives him an excellent diploma.
> This is quite possible because universities often have the necessary
> equipment and diploma works are supposed to be long and difficult. At this
> point reading a publication and using its results is trivial. And look at
> reverse-engineered opensource drivers. It's just a matter of obfuscation and
> we already know that it brings no security. If you want to protect your keys
> the only ways is to physically protect them like putting concrete around the
> flash chip

Hmm, so let me collect the data from this discussion:

There is somebody who wants to lock his own computer in software so
that his data is not easily accessible.

For some reason he wants to store the data encrypted in multiple
locations rather than using a simple terminal to retreive the data
over network which makes things needlessly hard.

He can have a custom solution developed for the purpose (like take an
ALIX board and have the BIOS on it customized and have the flash chip
covered with concrete ;-)

He can also use a ready made solution - a board with a TPM chip.

Now I am not sure how secure this solution is. You can usually remove
the battery to reset BIOS password, reflash the BIOS, etc.

Since manufacturers claim (or used to) that you can pry the TPM chip
off your board and it will still work the board is bootstrapped by the
main CPU, not the TPM. This makes it possible to short some pins on
the TPM chip so that is cannot be accessed during boot, boot a virtual
machine, and have the BIOS initialize the chip inside that.

There's also the possibility to remove the RAM from a running computer
given you find out what kind of RAM it uses and get a different
compatible computer.

Generally this shifts the attack from the realm of plain vandalism to
the realm of planned attack which is certainly a bonus.

Still I would rather rely on a custom solution because I would know
exactly what it does. The manufacturers of PC mainboards tend to not
release exact specifications and there are often serious problems.

Still finding the flaw in the particular mainboard would probably take
some non-trivial effort.
If the attacker just wants to break something there would likely be
easier targets. If you are specifically targeted you are doomed. Hire
a security agency to guard your computers so that you can blame them
when the data is stolen.

Now to the TPM support in GRUB.

It appears that if grub supports *any* integrity check of the loaded
software, and the BIOS can make the TPM check GRUB you are set, the
GRUB itself needs not talk to the TPM diractly, it's just a nice
bonus.

And if somebody wanted to lock your computer from you they would ship
it with software that does it, they would not have to rely on GRUB.
Most likely GRUB would not be able to load their system anyway.

This makes the TPM support debate seem quite pointless.

Well, enjoy the flames ;-)

MS

Re: A _good_ and valid use for TPM

[phcoder]

> For some reason he wants to store the data encrypted in multiple
> locations rather than using a simple terminal to retreive the data
> over network which makes things needlessly hard.
He perhaps needs important amount of computing power. And in his case 
"all in centre" may require too much bandwidth
> Now I am not sure how secure this solution is. You can usually remove
> the battery to reset BIOS password, reflash the BIOS, etc.
Many boards save the data in flash memory so removing power won't reset 
password. Second flash chip if it's dedicated can be covered with 
concrete too and resetting pins can be removed. Besides with coreboot 
everything this can be well controlled - you can embed the config to flash.
> 
> Since manufacturers claim (or used to) that you can pry the TPM chip
> off your board and it will still work the board is bootstrapped by the
> main CPU, not the TPM. This makes it possible to short some pins on
> the TPM chip so that is cannot be accessed during boot, boot a virtual
> machine, and have the BIOS initialize the chip inside that.
> 
It would require some modifications to virtual machine to skip some 
initilisation but is entirely possible and needs to be done only once to 
cover 99% of motherboards
> There's also the possibility to remove the RAM from a running computer
> given you find out what kind of RAM it uses and get a different
> compatible computer.
concrete :)
> 
> Generally this shifts the attack from the realm of plain vandalism to
> the realm of planned attack which is certainly a bonus.
> 
> Still I would rather rely on a custom solution because I would know
> exactly what it does. The manufacturers of PC mainboards tend to not
> release exact specifications and there are often serious problems.
> 
> Still finding the flaw in the particular mainboard would probably take
> some non-trivial effort.
There are only few kinds of tpm chips so it's enough that someone cracks 
  the corresponding ship to make the attack trivial. As a matter of fact 
few year from now it may be easier to get a universal reader for all tpm 
chips then a reader for a specific flash chip
> If the attacker just wants to break something there would likely be
> easier targets. If you are specifically targeted you are doomed.
Yes. Once an attacker has the device he is able to retrieve all the data 
in. Only putting physical obstacles may slow the attacker down. And I 
doubt that a cost of such operation can be over $10000 no matter what 
protection you use.
> 
> Now to the TPM support in GRUB.
> 
> This makes the TPM support debate seem quite pointless.
> 
It isn't. Supporing tpm may help it becoming widespread, commonplace and 
acceptable, exactly what we try to avoid

Regards
Vladimir 'phcoder' Serbinenko

Re: A _good_ and valid use for TPM

[step21]

This whole debate made read up a little bit on TPM, for example I
checked http://www.osxbook.com/book/bonus/chapter10/tpm/
(osx book is a very nice resource for mac/os x system internals)
regarding tpms on apple hardware.
Now contrary to what some outdated resources/rumours say, at least all
newer intel mac don't include any tpm at all, the only thing that
definitely did contain one were the developer boxes that were shipped
to apple developer connection subscribers when the transition from ppc
to intel started. Also, I can confirm this for my macbook air, neither
the device tree inside os x or logic board photos from ifixit give any
indication of a tpm chip, also all sources that don't rely on rumours
confirm that apart from developer boxes intel macs don't contain one.
You might say, now, how is that important? Well, I don't know about
current i386/bios boards, for once because there are so many and
because I don't intend to buy one in the near future, but how
widespread is the use of tpm chips nowadays, especially considering
the thing hardly counts as a new development any more? I think this is
important to include in those ideologic discussions, especially cause
if  there is one company that I think would try to lock their hardware
down as much as possible using something like a tpm, it's apple, but
they don't. Also, all the annoying things like drm or this copy
protection thing for displays (don't know what it's called atm, where
all possible without a tpm.
So, how widespread are builtin tpms for normal pc boards?
As for osx86, they have a really old wiki page about tpm, but a
current comment I found said more or less to patch a current version
of os x to run on normal hardware you just have to "patch out efi with
1-2 nops and hardocde the fsb with another 1-2 nops"
http://www.insanelymac.com/forum/index.php?showtopic=65786
Just found this interesting ...

On Sun, Feb 22, 2009 at 4:33 PM, phcoder <phcoder@gmail.com> wrote:
>> For some reason he wants to store the data encrypted in multiple
>> locations rather than using a simple terminal to retreive the data
>> over network which makes things needlessly hard.
>
> He perhaps needs important amount of computing power. And in his case "all
> in centre" may require too much bandwidth
>>
>> Now I am not sure how secure this solution is. You can usually remove
>> the battery to reset BIOS password, reflash the BIOS, etc.
>
> Many boards save the data in flash memory so removing power won't reset
> password. Second flash chip if it's dedicated can be covered with concrete
> too and resetting pins can be removed. Besides with coreboot everything this
> can be well controlled - you can embed the config to flash.
>>
>> Since manufacturers claim (or used to) that you can pry the TPM chip
>> off your board and it will still work the board is bootstrapped by the
>> main CPU, not the TPM. This makes it possible to short some pins on
>> the TPM chip so that is cannot be accessed during boot, boot a virtual
>> machine, and have the BIOS initialize the chip inside that.
>>
> It would require some modifications to virtual machine to skip some
> initilisation but is entirely possible and needs to be done only once to
> cover 99% of motherboards
>>
>> There's also the possibility to remove the RAM from a running computer
>> given you find out what kind of RAM it uses and get a different
>> compatible computer.
>
> concrete :)
>>
>> Generally this shifts the attack from the realm of plain vandalism to
>> the realm of planned attack which is certainly a bonus.
>>
>> Still I would rather rely on a custom solution because I would know
>> exactly what it does. The manufacturers of PC mainboards tend to not
>> release exact specifications and there are often serious problems.
>>
>> Still finding the flaw in the particular mainboard would probably take
>> some non-trivial effort.
>
> There are only few kinds of tpm chips so it's enough that someone cracks
>  the corresponding ship to make the attack trivial. As a matter of fact few
> year from now it may be easier to get a universal reader for all tpm chips
> then a reader for a specific flash chip
>>
>> If the attacker just wants to break something there would likely be
>> easier targets. If you are specifically targeted you are doomed.
>
> Yes. Once an attacker has the device he is able to retrieve all the data in.
> Only putting physical obstacles may slow the attacker down. And I doubt that
> a cost of such operation can be over $10000 no matter what protection you
> use.
>>
>> Now to the TPM support in GRUB.
>>
>> This makes the TPM support debate seem quite pointless.
>>
> It isn't. Supporing tpm may help it becoming widespread, commonplace and
> acceptable, exactly what we try to avoid
>
> Regards
> Vladimir 'phcoder' Serbinenko
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>

Re: A _good_ and valid use for TPM

[Michal Suchanek]

2009/2/23 step21 <flo@terrorpop.de>:
> This whole debate made read up a little bit on TPM, for example I
> checked http://www.osxbook.com/book/bonus/chapter10/tpm/
> (osx book is a very nice resource for mac/os x system internals)
> regarding tpms on apple hardware.
> Now contrary to what some outdated resources/rumours say, at least all
> newer intel mac don't include any tpm at all, the only thing that
> definitely did contain one were the developer boxes that were shipped
> to apple developer connection subscribers when the transition from ppc
> to intel started. Also, I can confirm this for my macbook air, neither
> the device tree inside os x or logic board photos from ifixit give any
> indication of a tpm chip, also all sources that don't rely on rumours
> confirm that apart from developer boxes intel macs don't contain one.
> You might say, now, how is that important? Well, I don't know about
> current i386/bios boards, for once because there are so many and
> because I don't intend to buy one in the near future, but how
> widespread is the use of tpm chips nowadays, especially considering
> the thing hardly counts as a new development any more? I think this is
> important to include in those ideologic discussions, especially cause
> if  there is one company that I think would try to lock their hardware
> down as much as possible using something like a tpm, it's apple, but
> they don't. Also, all the annoying things like drm or this copy
> protection thing for displays (don't know what it's called atm, where
> all possible without a tpm.
> So, how widespread are builtin tpms for normal pc boards?
> As for osx86, they have a really old wiki page about tpm, but a
> current comment I found said more or less to patch a current version
> of os x to run on normal hardware you just have to "patch out efi with
> 1-2 nops and hardocde the fsb with another 1-2 nops"
> http://www.insanelymac.com/forum/index.php?showtopic=65786
> Just found this interesting ...

For PC boards it's easy to find ones that do include the chip and ones
that do not.

I cannot tell if the ratio is like 70:30 or 50:50 but both are common.
It seems the TPMs are used more by system integrators that build
complete PC systems than bulk part manufacturers (possibly because of
budget limits and low demand for the chips).

Most PC notebooks include a fingerprint sensor that is tied to a TPM
chip. At least the Windows drivers for the sensor usually require the
TPM drivers installed although I guess the sensor could be used on its
own. There are still many notebooks without a sensor but I have no
idea how many of them do include a TPM chip.

I have no idea why boards with TPM chips are shipped at all or if
anybody uses them for anything but the fingerprint readers.

Thanks

Michal

Re: A _good_ and valid use for TPM

[Robert Millan]

On Mon, Feb 23, 2009 at 03:34:56AM +0100, step21 wrote:
> if  there is one company that I think would try to lock their hardware
> down as much as possible using something like a tpm, it's apple, but
> they don't.

You're looking at the wrong place.  Check the iphone.

Anyway, it's nice to hear TPMs are disappearing from desktops.  I hope it's
true.

-- 
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: A _good_ and valid use for TPM

[Robert Millan]

On Sun, Feb 22, 2009 at 03:21:21AM +0200, Alex Besogonov wrote:
> Robert Millan wrote:
>>> Making sure, that noone can override it, can be awfully difficult, especially
>>> under a physical attacker. A hardware that is at least a bit designed to
>>> withstand such an attack can help a lot.
>> I'm not sure why is physical security so awfully difficult for you (can't you
>> use locks, tamper-proof seals, cameras and alarms?), but most people who're in
>> the bussiness of protecting physical goods manage to sort it out.
> My devices will be installed at clients' locations. It's impossible to  
> guarantee that all devices will be physically secure.
>
> If you live in the USA then one day such device might contain your  
> private data. Would you like it to be stolen?

My private data is safely stored.  The stuff Google reads from my Gmail
account is *not* private data.

If you send your private stuff elsewhere and trust noone can read it because
a small chip that's not even under your control told you so, you're being
naive...

> Reverse engineering the TPM chip is very costly. And I'm not going to  
> try to protect data from NSA or CIA or another three-letter agency.

...but thankfully, not as much as I thought.

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan <rmh@aybabtu.com> wrote:
>> Yes, I'm trying to do remote attestation.
> You're confusing things.  I think you simply want to ensure data integrity, and
> the TPM doesn't even do that: it simply puts the problem in hands of a third
> party.
No, I'm not confusing anything.

> "remote attestation" is only useful when you want to coerce others into
> running your (generaly proprietary) software.  I hope this is not what you
> want to do.
It's exactly what I want to do (minus the 'coercing' part). I want to
ensure that devices run only my unmodified software (which I consider
secure) and only in this case provide decryption keys for sensitive
data. Of course, it done not for DRM purposes, but rather to protect
sensitive data from theft (real theft, not copyright infringement).

>> Well, I spoke phcoder on Jabber - there might be a way to do this.
>> He's going to investigate it.
> This is unnecessary.  Once GRUB supports crypto, it can simply load
> itself from an encrypted filesystem on disk.  An image can be of
> arbitrary size.
Nope. Still no way to test system integrity.

Re: A _good_ and valid use for TPM

[phcoder]

Well I don't understand you. When someone speaks about an attack on tpm 
you always consider it not-applicable in your environment. Most of them 
actually are. Like power analysis is able to recover keys in $1000 
margin. With firewire attack you can do it with $10. You can't seriously 
assume an attacker which has less then $100 budget in any application. 
Reading directly from tpm in its current state is just a matter of time. 
However you consider any attack on the scheme coreboot+grub+boot or boot 
virus protection+sha-1+grub+boot with the encryption key in flash memory 
relevant. In both of these scenarios an attacker is unable to read the 
key without a hardware tampering level comparable to the one required to 
recover the key from tpm.
TPM is dangerous and once we use it it's difficult to come back. If it 
could provide something over the two mentioned schemes then I would say 
that it's worth investigating. But as it isn't I say smash you tpm chip.

The only thing that tpm offers over other possibilities is a claim to 
achieve something that is theoretically impossible. Such claims are 
often the case in computer industry. I call it "marketing security". I 
suppose companies and engineers know that their claims are false still 
say it because their salaries depend on how well their product is sold
Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan <rmh@aybabtu.com> wrote:
>>> Yes, I'm trying to do remote attestation.
>> You're confusing things.  I think you simply want to ensure data integrity, and
>> the TPM doesn't even do that: it simply puts the problem in hands of a third
>> party.
> No, I'm not confusing anything.
> 
>> "remote attestation" is only useful when you want to coerce others into
>> running your (generaly proprietary) software.  I hope this is not what you
>> want to do.
> It's exactly what I want to do (minus the 'coercing' part). I want to
> ensure that devices run only my unmodified software (which I consider
> secure) and only in this case provide decryption keys for sensitive
> data. Of course, it done not for DRM purposes, but rather to protect
> sensitive data from theft (real theft, not copyright infringement).
> 
>>> Well, I spoke phcoder on Jabber - there might be a way to do this.
>>> He's going to investigate it.
>> This is unnecessary.  Once GRUB supports crypto, it can simply load
>> itself from an encrypted filesystem on disk.  An image can be of
>> arbitrary size.
> Nope. Still no way to test system integrity.
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 06:03:30PM +0100, phcoder wrote:
>
> The only thing that tpm offers over other possibilities is a claim to  
> achieve something that is theoretically impossible. Such claims are  
> often the case in computer industry. I call it "marketing security".

And I have to admit, they got really good at it.

-- 
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: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 06:29:01PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan <rmh@aybabtu.com> wrote:
> >> Yes, I'm trying to do remote attestation.
> > You're confusing things.  I think you simply want to ensure data integrity, and
> > the TPM doesn't even do that: it simply puts the problem in hands of a third
> > party.
> No, I'm not confusing anything.
> 
> > "remote attestation" is only useful when you want to coerce others into
> > running your (generaly proprietary) software.  I hope this is not what you
> > want to do.
> It's exactly what I want to do (minus the 'coercing' part). I want to
> ensure that devices run only my unmodified software (which I consider
> secure) and only in this case provide decryption keys for sensitive
> data. Of course, it done not for DRM purposes, but rather to protect
> sensitive data from theft (real theft, not copyright infringement).

There's no fundamental difference between hardening a device and using that
as your root of trust and using someone else's hardened device and using
that as your root of trust.  The only differences are:

  - One more link in the trust chain (irrelevant).

  - Because it's _someone else's_ computer (the TPM), you're irrationally
    assuming that its security is flawless.

  - Because it's someone else's computer, this helps them get their foot in
    your door.  Next time you notice, each PC will be verified by one of
    these, and then you can kiss all your freedom goodbye.

> >> Well, I spoke phcoder on Jabber - there might be a way to do this.
> >> He's going to investigate it.
> > This is unnecessary.  Once GRUB supports crypto, it can simply load
> > itself from an encrypted filesystem on disk.  An image can be of
> > arbitrary size.
> Nope. Still no way to test system integrity.

I was repliing to the idea of implementing sha-1 checks in the MBR.  Please
don't bring it out of context.

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

Robert Millan wrote:
>> It's exactly what I want to do (minus the 'coercing' part). I want to
>> ensure that devices run only my unmodified software (which I consider
>> secure) and only in this case provide decryption keys for sensitive
>> data. Of course, it done not for DRM purposes, but rather to protect
>> sensitive data from theft (real theft, not copyright infringement).
> There's no fundamental difference between hardening a device and using that
> as your root of trust and using someone else's hardened device and using
> that as your root of trust.  
There's a difference. It's impossible to create the root-of-trust 
without some hardware/firmware support.

> The only differences are:
>   - One more link in the trust chain (irrelevant).
>   - Because it's _someone else's_ computer (the TPM), you're irrationally
>     assuming that its security is flawless.
Security of TPM vendors is audited by a third party. For most practical 
purposes it can be considered quite adequate.

>   - Because it's someone else's computer, this helps them get their foot in
>     your door.  Next time you notice, each PC will be verified by one of
>     these, and then you can kiss all your freedom goodbye.
And how does not supporting this functionality in GRUB affect this?

>> > This is unnecessary.  Once GRUB supports crypto, it can simply load
>> > itself from an encrypted filesystem on disk.  An image can be of
>> > arbitrary size.
>> Nope. Still no way to test system integrity.
> I was repliing to the idea of implementing sha-1 checks in the MBR.  Please
> don't bring it out of context.
Sorry, I didn't mean to.

-- 
With respect,
             Alex Besogonov (cyberax@staffdirector.net)

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sun, Feb 22, 2009 at 03:26:32AM +0200, Alex Besogonov wrote:
> Robert Millan wrote:
>>> It's exactly what I want to do (minus the 'coercing' part). I want to
>>> ensure that devices run only my unmodified software (which I consider
>>> secure) and only in this case provide decryption keys for sensitive
>>> data. Of course, it done not for DRM purposes, but rather to protect
>>> sensitive data from theft (real theft, not copyright infringement).
>> There's no fundamental difference between hardening a device and using that
>> as your root of trust and using someone else's hardened device and using
>> that as your root of trust.  
> There's a difference. It's impossible to create the root-of-trust  
> without some hardware/firmware support.

I assume you mean a root of trust that's not vulnerable to physical
attack.  Sure, you need firmware support, but you don't need to blindly
trust someone else's firmware when you can use coreboot with GRUB as
your firmware.

>> The only differences are:
>>   - One more link in the trust chain (irrelevant).
>>   - Because it's _someone else's_ computer (the TPM), you're irrationally
>>     assuming that its security is flawless.
> Security of TPM vendors is audited by a third party. For most practical  
> purposes it can be considered quite adequate.

Adequate maybe, not flawless.  And using your own concrete is still cheaper
and more trustworthy than someone else's silicon :-)

-- 
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: A _good_ and valid use for TPM

[Michael Gorven]

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

On Friday 20 February 2009 02:29:50 Jan Alsenz wrote:
> So in the end (after boot) you have a bunch of PCR values, that represent
> all the code and data, that was used to boot the system. If you have this
> and are sure, that the current configuration is correct, you have a
> reference value of the expected system state, which you can use for the
> following:
> - seal a key:
> 	You can create a key with the TPM and "bind" it to specific values of the
> PCRs, so it only en/decrypts with it, if these values match.
> 	You can encrypt any kind of data with this, but the only useful thing for
> boot is to encrypt a cryptographic key needed to further start the system.

Last year I implemented support for encrypted partitions in GRUB2 [1], which 
means that it can load kernels and ramdisks off encrypted partitions. TPM 
support in GRUB2 would allow the key to be stored in the TPM and only 
provided to GRUB once the system has checked that GRUB hasn't been tampered 
with.

TPM can be used for good or for bad, but this is the case for everything 
involving cryptography. We don't refuse to use encryption algorithms because 
they could be used for DRM, so why should we refuse to use TPM? TPM has the 
potential to make Linux even more secure.

Regards
Michael

[1] My work is yet to be merged into GRUB2.

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

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

Re: A _good_ and valid use for TPM

[phcoder]

Free software is about freedom of choice. I think we should have 
possibility to have multiple authentication and key sources. Then one 
could e.g. not save password as md5 somewhere in configfile or embedded 
in module but check that this password opens luks. Or that it's a 
password of somebody in wheel group basing on /etc/passwd, /etc/shadow 
and /etc/group. In this case tpm-keyretrieve module may be developed 
outside of main trunk and if someone wants it he can download it
Regards
Vladimir 'phcoder' Serbinenko
Michael Gorven wrote:
> On Friday 20 February 2009 02:29:50 Jan Alsenz wrote:
>> So in the end (after boot) you have a bunch of PCR values, that represent
>> all the code and data, that was used to boot the system. If you have this
>> and are sure, that the current configuration is correct, you have a
>> reference value of the expected system state, which you can use for the
>> following:
>> - seal a key:
>> 	You can create a key with the TPM and "bind" it to specific values of the
>> PCRs, so it only en/decrypts with it, if these values match.
>> 	You can encrypt any kind of data with this, but the only useful thing for
>> boot is to encrypt a cryptographic key needed to further start the system.
> 
> Last year I implemented support for encrypted partitions in GRUB2 [1], which 
> means that it can load kernels and ramdisks off encrypted partitions. TPM 
> support in GRUB2 would allow the key to be stored in the TPM and only 
> provided to GRUB once the system has checked that GRUB hasn't been tampered 
> with.
> 
> TPM can be used for good or for bad, but this is the case for everything 
> involving cryptography. We don't refuse to use encryption algorithms because 
> they could be used for DRM, so why should we refuse to use TPM? TPM has the 
> potential to make Linux even more secure.
> 
> Regards
> Michael
> 
> [1] My work is yet to be merged into GRUB2.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: A _good_ and valid use for TPM

[Michael Gorven]

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

On Friday 20 February 2009 13:27:28 phcoder wrote:
> Free software is about freedom of choice. I think we should have
> possibility to have multiple authentication and key sources. Then one
> could e.g. not save password as md5 somewhere in configfile or embedded
> in module but check that this password opens luks. Or that it's a
> password of somebody in wheel group basing on /etc/passwd, /etc/shadow
> and /etc/group. In this case tpm-keyretrieve module may be developed
> outside of main trunk and if someone wants it he can download it

Yes, I agree that there should be multiple methods, but I don't see why the 
TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB 
users in any way -- we would just be giving them the option to use it. They 
would have to explicitly enable and set it up. As Jan said, the TPM is a 
passive device which can be used in any way we wish, and I don't see why 
using some of its features to create a more secure system is wrong.

Regards
Michael

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

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

Re: A _good_ and valid use for TPM

[Jan Alsenz]

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

I agree too!

Multiple methods are interesting and everything that can be, should be placed in
 modules.
But some parts of a trusted boot chain need to be in the MBR, etc. which is
mainline code (regardless of how how you build it).

The way I have implemented my version of the MBR right now is with compile flags:
If you don't want/need TPM code it won't be on your system! If you compile it
with TPM support, it won't boot if there is no TPM (I don't like silent failures).

Greets,

Jan


Michael Gorven schrieb:
> On Friday 20 February 2009 13:27:28 phcoder wrote:
>> Free software is about freedom of choice. I think we should have
>> possibility to have multiple authentication and key sources. Then one
>> could e.g. not save password as md5 somewhere in configfile or embedded
>> in module but check that this password opens luks. Or that it's a
>> password of somebody in wheel group basing on /etc/passwd, /etc/shadow
>> and /etc/group. In this case tpm-keyretrieve module may be developed
>> outside of main trunk and if someone wants it he can download it
> 
> Yes, I agree that there should be multiple methods, but I don't see why the 
> TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB 
> users in any way -- we would just be giving them the option to use it. They 
> would have to explicitly enable and set it up. As Jan said, the TPM is a 
> passive device which can be used in any way we wish, and I don't see why 
> using some of its features to create a more secure system is wrong.
> 
> Regards
> Michael


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Vesa Jääskeläinen]

Jan Alsenz wrote:
> I agree too!
> 
> Multiple methods are interesting and everything that can be, should be placed in
>  modules.
> But some parts of a trusted boot chain need to be in the MBR, etc. which is
> mainline code (regardless of how how you build it).
> 
> The way I have implemented my version of the MBR right now is with compile flags:
> If you don't want/need TPM code it won't be on your system! If you compile it
> with TPM support, it won't boot if there is no TPM (I don't like silent failures).

In case it will get some day in. I would propose that you make own MBR
code like that gets compiled to own img file like tpmboot.img (512
bytes). Then you can just provide img file for tool chain. You are
probably throwing code away anyway from normal mbr boot code.

Re: A _good_ and valid use for TPM

[Jan Alsenz]

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

Vesa Jääskeläinen wrote:
> In case it will get some day in. I would propose that you make own MBR
> code like that gets compiled to own img file like tpmboot.img (512
> bytes). Then you can just provide img file for tool chain. You are
> probably throwing code away anyway from normal mbr boot code.
That should be possible I guess.

And I have multiple versions, using different TPM commands.
One of the versions keeps all the existing functionality!
I had to squeeze the existing code a bit though. It should still work as
expected, but I didn't have the time to test it yet. (If someone wants to
volunteer, I could send the code).

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Robert Millan]

On Fri, Feb 20, 2009 at 02:12:01PM +0200, Michael Gorven wrote:
> 
> Yes, I agree that there should be multiple methods, but I don't see why the 
> TPM module shouldn't be in the main trunk. It wouldn't be forced on GRUB 
> users in any way -- we would just be giving them the option to use it.

GRUB is free software.  You can do anything you want with it.  We can't really
force our users to either use TPMs or not to use them.

However, we can choose not to endorse a feature if we think it's ill-intended.
We can also try to raise awareness of the problem, which is what I'm doing
right now.

-- 
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: A _good_ and valid use for TPM

[Robert Millan]

On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> 
> TPM can be used for good or for bad, but this is the case for everything 
> involving cryptography. We don't refuse to use encryption algorithms because 
> they could be used for DRM, so why should we refuse to use TPM?

I don't agree with this analogy.  Unlike cryptography, TPMs have been designed
from the ground up to serve an evil purpose.  They *could* have designed
them with good intent, for example either of these could apply:

  - Buyer gets a printed copy of the TPM's private key when they buy a board.

  - An override button that's physically accessible from the chip can be
    used to disable "hostile mode" and make the TPM sign everything.  From
    that point physical access can be managed with traditional methods (e.g.
    locks).

But they didn't.

-- 
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: A _good_ and valid use for TPM

[Michael Gorven]

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

On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > TPM can be used for good or for bad, but this is the case for everything
> > involving cryptography. We don't refuse to use encryption algorithms
> > because they could be used for DRM, so why should we refuse to use TPM?
>
> I don't agree with this analogy.  Unlike cryptography, TPMs have been
> designed from the ground up to serve an evil purpose.  They *could* have
> designed them with good intent, for example either of these could apply:
>
>   - Buyer gets a printed copy of the TPM's private key when they buy a
> board.
>
>   - An override button that's physically accessible from the chip can be
>     used to disable "hostile mode" and make the TPM sign everything.  From
>     that point physical access can be managed with traditional methods
> (e.g. locks).
>
> But they didn't.

Just to clarify, are you objecting to the use of TPM on principle and because 
you don't want to encourage use of it, or because you think this specific use 
(trusted boot path) is dangerous?

Michael

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

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

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > TPM can be used for good or for bad, but this is the case for everything
> > > involving cryptography. We don't refuse to use encryption algorithms
> > > because they could be used for DRM, so why should we refuse to use TPM?
> >
> > I don't agree with this analogy.  Unlike cryptography, TPMs have been
> > designed from the ground up to serve an evil purpose.  They *could* have
> > designed them with good intent, for example either of these could apply:
> >
> >   - Buyer gets a printed copy of the TPM's private key when they buy a
> > board.
> >
> >   - An override button that's physically accessible from the chip can be
> >     used to disable "hostile mode" and make the TPM sign everything.  From
> >     that point physical access can be managed with traditional methods
> > (e.g. locks).
> >
> > But they didn't.
> 
> Just to clarify, are you objecting to the use of TPM on principle and because 
> you don't want to encourage use of it, or because you think this specific use 
> (trusted boot path) is dangerous?

I can't reply to this question, because it's not just a specific use, it's
part of the design, of its purpose.  One of the design goals is remote
attestation, which is a threat to our freedom and is unethical.

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.

-- 
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: A _good_ and valid use for TPM

[Michael Gorven]

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

On Saturday 21 February 2009 22:31:36 Robert Millan wrote:
> On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> > On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > > TPM can be used for good or for bad, but this is the case for
> > > > everything involving cryptography. We don't refuse to use encryption
> > > > algorithms because they could be used for DRM, so why should we
> > > > refuse to use TPM?
> > >
> > > I don't agree with this analogy.  Unlike cryptography, TPMs have been
> > > designed from the ground up to serve an evil purpose.  They *could*
> > > have designed them with good intent, for example either of these could
> > > apply:
> > >
> > >   - Buyer gets a printed copy of the TPM's private key when they buy a
> > > board.
> > >
> > >   - An override button that's physically accessible from the chip can
> > > be used to disable "hostile mode" and make the TPM sign everything. 
> > > From that point physical access can be managed with traditional methods
> > > (e.g. locks).
> > >
> > > But they didn't.
> >
> > Just to clarify, are you objecting to the use of TPM on principle and
> > because you don't want to encourage use of it, or because you think this
> > specific use (trusted boot path) is dangerous?
>
> I can't reply to this question, because it's not just a specific use, it's
> part of the design, of its purpose.  One of the design goals is remote
> attestation, which is a threat to our freedom and is unethical.
>
> 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.

I wasn't actually referring to the remote attestation. Just using the TPM to 
store a disk encryption key sealed with PCR registers, so that it would only 
be provided once it's been verified that GRUB hasn't been changed. 
(Personally I wouldn't want to use remote attestation at all.)

Michael

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

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

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote:
> > > Just to clarify, are you objecting to the use of TPM on principle and
> > > because you don't want to encourage use of it, or because you think this
> > > specific use (trusted boot path) is dangerous?
> >
> > I can't reply to this question, because it's not just a specific use, it's
> > part of the design, of its purpose.  One of the design goals is remote
> > attestation, which is a threat to our freedom and is unethical.
> >
> > 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.
> 
> I wasn't actually referring to the remote attestation. Just using the TPM to 
> store a disk encryption key sealed with PCR registers, so that it would only 
> be provided once it's been verified that GRUB hasn't been changed. 
> (Personally I wouldn't want to use remote attestation at all.)

First of all, I think it's a poor approach, because there's no way to garantee
the TPM is doing what it's supposed to (can you read its source code?  how do
you know for sure there are no backdoors?).

But the important here is not whether there's something wrong with the use case
you described or not.  The important is that this use case is lumped together
with something seriously nasty, and that its promoters are acting
irresponsibly by not allowing us to make the distinction.

-- 
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: A _good_ and valid use for TPM

[Jan Alsenz]

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

Robert Millan wrote:
> On Sat, Feb 21, 2009 at 10:43:16PM +0200, Michael Gorven wrote:
>>>> Just to clarify, are you objecting to the use of TPM on principle and
>>>> because you don't want to encourage use of it, or because you think this
>>>> specific use (trusted boot path) is dangerous?
>>> I can't reply to this question, because it's not just a specific use, it's
>>> part of the design, of its purpose.  One of the design goals is remote
>>> attestation, which is a threat to our freedom and is unethical.
>>>
>>> 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.
>> I wasn't actually referring to the remote attestation. Just using the TPM to 
>> store a disk encryption key sealed with PCR registers, so that it would only 
>> be provided once it's been verified that GRUB hasn't been changed. 
>> (Personally I wouldn't want to use remote attestation at all.)
> 
> First of all, I think it's a poor approach, because there's no way to garantee
> the TPM is doing what it's supposed to (can you read its source code?  how do
> you know for sure there are no backdoors?).

As I said before: you can make the very same argument for every single part of
your PC.
Why do you trust Intel or AMD with your CPU? They are also involved in the TCG!


Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[phcoder]

> 
> As I said before: you can make the very same argument for every single part of
> your PC.
> Why do you trust Intel or AMD with your CPU? They are also involved in the TCG!

We can't verify that it doesn't do such things. Unfortunately we also 
don't have resources to build alternative chips. However it doesn't mean 
we should support any anti-freedom devices

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote:
> > 
> > First of all, I think it's a poor approach, because there's no way to garantee
> > the TPM is doing what it's supposed to (can you read its source code?  how do
> > you know for sure there are no backdoors?).
> 
> As I said before: you can make the very same argument for every single part of
> your PC.
> Why do you trust Intel or AMD with your CPU? They are also involved in the TCG!

You took the least relevant part of my argument, and assumed this is the reason
I object to TPMs.  Please check the rest of my previous mail.

Anyway, it's obvious that I trust my CPU because I have no other choice.  The
context in which I said this, is different: there are better choices there.

-- 
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: A _good_ and valid use for TPM

[Jan Alsenz]

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

Robert Millan wrote:
> On Sat, Feb 21, 2009 at 10:17:02PM +0100, Jan Alsenz wrote:
>>> First of all, I think it's a poor approach, because there's no way to garantee
>>> the TPM is doing what it's supposed to (can you read its source code?  how do
>>> you know for sure there are no backdoors?).
>> As I said before: you can make the very same argument for every single part of
>> your PC.
>> Why do you trust Intel or AMD with your CPU? They are also involved in the TCG!
> 
> You took the least relevant part of my argument, and assumed this is the reason
> I object to TPMs.  Please check the rest of my previous mail.

I didn't assume that. And I picked this argument because it is the only one I
object!
Because I think it is not an argument...

> Anyway, it's obvious that I trust my CPU because I have no other choice.  The
> context in which I said this, is different: there are better choices there.

... and since you seem to agree, please don't use it.


You seem to assume, that I really like the idea of a TPM, or something like that.
I can assure you, that this is not the case. My only goal is to keep the
discussion based on facts and reason. Which way too often get lost in this kind
of discussion (and I want to stress that this is not an accusation to anyone here).

Greets,

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 10:57:50PM +0100, Jan Alsenz wrote:
> > 
> > You took the least relevant part of my argument, and assumed this is the reason
> > I object to TPMs.  Please check the rest of my previous mail.
> 
> I didn't assume that. And I picked this argument because it is the only one I
> object!
> Because I think it is not an argument...
> 
> > Anyway, it's obvious that I trust my CPU because I have no other choice.  The
> > context in which I said this, is different: there are better choices there.
> 
> ... and since you seem to agree, please don't use it.
> 
> 
> You seem to assume, that I really like the idea of a TPM, or something like that.
> I can assure you, that this is not the case. My only goal is to keep the
> discussion based on facts and reason. Which way too often get lost in this kind
> of discussion (and I want to stress that this is not an accusation to anyone here).

Thanks for clarifiing, I appreciate your response.

-- 
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: A _good_ and valid use for TPM

[Jan Alsenz]

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

Hi!

I don't want to be picky here, but you know that remote attestation is simply
sending signed hash values?
The important thing is that the receiver has trust in the protection of the
private key.

So if you build me a coreboot/GRUB version with a trusted boot chain I can
happily implement a remote attestation scheme with it and ship it to my customers.

Greets,

Jan


Robert Millan wrote:
> On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
>> On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
>>> On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
>>>> TPM can be used for good or for bad, but this is the case for everything
>>>> involving cryptography. We don't refuse to use encryption algorithms
>>>> because they could be used for DRM, so why should we refuse to use TPM?
>>> I don't agree with this analogy.  Unlike cryptography, TPMs have been
>>> designed from the ground up to serve an evil purpose.  They *could* have
>>> designed them with good intent, for example either of these could apply:
>>>
>>>   - Buyer gets a printed copy of the TPM's private key when they buy a
>>> board.
>>>
>>>   - An override button that's physically accessible from the chip can be
>>>     used to disable "hostile mode" and make the TPM sign everything.  From
>>>     that point physical access can be managed with traditional methods
>>> (e.g. locks).
>>>
>>> But they didn't.
>> Just to clarify, are you objecting to the use of TPM on principle and because 
>> you don't want to encourage use of it, or because you think this specific use 
>> (trusted boot path) is dangerous?
> 
> I can't reply to this question, because it's not just a specific use, it's
> part of the design, of its purpose.  One of the design goals is remote
> attestation, which is a threat to our freedom and is unethical.
> 
> 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.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 10:04:22PM +0100, Jan Alsenz wrote:
> Hi!
> 
> I don't want to be picky here, but you know that remote attestation is simply
> sending signed hash values?

Sure.  The tricky part is that your computer generates those, but you're not
really in control of them.  You need to ask your TPM to obtain them, like a
beggar.

> So if you build me a coreboot/GRUB version with a trusted boot chain I can
> happily implement a remote attestation scheme with it and ship it to my customers.

That's the beauty of free software; you can do anything you like with it, even
nasty things.  Just don't expect us to help you get there.

-- 
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: A _good_ and valid use for TPM

[Isaac Dupree]

Robert Millan wrote:
> On Sat, Feb 21, 2009 at 05:29:34PM +0200, Michael Gorven wrote:
> > On Saturday 21 February 2009 15:51:42 Robert Millan wrote:
> > > On Fri, Feb 20, 2009 at 09:45:28AM +0200, Michael Gorven wrote:
> > > > TPM can be used for good or for bad, but this is the case for
> > > > everything involving cryptography. We don't refuse to use encryption
> > > > algorithms because they could be used for DRM, so why should we
> > > > refuse to use TPM?
> > >
> > > I don't agree with this analogy.  Unlike cryptography, TPMs have been
> > > designed from the ground up to serve an evil purpose.  They *could*
> > > have designed them with good intent, for example either of these could
> > > apply:
> > >
> > >   - Buyer gets a printed copy of the TPM's private key when they buy a
> > > board.
> > >
> > >   - An override button that's physically accessible from the chip can
> > > be used to disable "hostile mode" and make the TPM sign everything. 
> > > From that point physical access can be managed with traditional methods
> > > (e.g. locks).
> > >
> > > But they didn't.
> >
> > Just to clarify, are you objecting to the use of TPM on principle and
> > because you don't want to encourage use of it, or because you think this
> > specific use (trusted boot path) is dangerous?
>
> I can't reply to this question, because it's not just a specific use, it's
> part of the design, of its purpose.  One of the design goals is remote
> attestation, which is a threat to our freedom and is unethical.
>
> 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.

(warning, I accidentally wrote a long essay exploring when these TPM-like 
things are evil)

Okay, suppose we use this means to make them not-so-evil: "Buyer gets a 
printed copy of the TPM's private key when they buy a board."  I'll call them 
"(pseudo)TPMs" when they meet GNU demands.  (They could be built with Free 
software, openly specified hardware designs, etc... why not throw in a bonus 
:-))

Alex Besogonov's use case is still possible.  Which should make us suspicious 
of whether our moral problem is solved.  Here's how it's possible:

Assume he has access to computer A, which is physically secured.

He buys computer B, which he wants to be able to wander around in the world 
without much effort put into physical security.  He accepts that the hard drive 
contents can be tampered with, but he's willing to pay for a smaller 
cryptographic unit that guards its secrets jealously -- the (pseudo)TPM -- in 
order to "prove" to computer A that computer B hasn't been changed.  Alex is 
the buyer, so he received the printed copy of the private key, and (for 
example) stashes it where computer A is, or burns it.

How does that make computer B free?  Computer A and its buddies (if any) will 
still refuse to communicate with B if B runs different software than what Alex 
had put on it.  Unless there are laws in place, Alex can go on to sell (or 
lease) computer B to someone else, without giving *them* the printed private 
key.  Or in the case of the "override button" and securing the (pseudo)TPM 
with physical locks, Alex could secure it with a lock, and then sell computer 
B without giving the lock's key to person who buys the computer from him.

This look at (pseudo)TPM makes them look to me as a weak way of asserting at-
a-distance your legal/political ownership of a computer.  Even if 
manufacturers cooperate with GNU demands, resulting (pseudo)TPMs are only 
useful for a purpose that is arguably evil... although the political arguments 
might be different between an end-user, a small non-computer-focused 
corporation, a large one, and a computer-manufacturer, asserting ownership.  
And it depends on whether they share such information (with police, public 
internets or other networks) in an attempt to detect fugitive computers.

I think, in the U.S. we can make laws that coerce corporations pretty 
effectively, and individuals don't have much power (most people buy their 
computing devices from mass marketers, large corporations, not people on the 
streets), so -- if we chose -- we could make laws that ensured that 
(pseudo)TPM technology was not used for its most serious moral transgressions.  
(I'm not sure though, because the Internet is so strange.)  Also because most 
software is made by big corporations that can be sued (e.g. Microsoft, Apple), 
and most Free non-corporate software isn't evil.  But I suspect that in a part 
of the world where people know their immediate oppressors more intimately, 
where the mass market (the "free market"?) isn't trusted as much, the TPM 
(well, like any other piece of software or hardware, only worse) could be 
abused to control people.  I could spin that argument one way to say that U.S. 
capitalism is to be desired (at least once we can make the legislators do what 
we want, rather than what big rich corporations want).

I think my question is: how essential is it that individual people should 
(always? usually?) have an easy time taking apart their computers, putting 
them back together, and changing them, and having them behave as "black boxes" 
to the outside world.  How much is physical security acceptable, when you have 
a thing you can lock up and yet still use (until the object decides to stop 
cooperating with you)?  Cryptography simply makes clear that any one piece of 
hardware can be uncooperative (not share everything it knows) and this has big 
consequences.  The big manufacturers have a lot of control here...

Back to Alex's circumstance, you can just make the computer hardware and 
software make it more difficult to (without the right password) install different 
software.  The BIOS could be unwilling to boot unrecognized software -- and 
since the BIOS is harder to remove/replace, therefore an attacker can't flash 
the BIOS if they don't have the password, either.  The BIOS could store the 
secret key we use to identify ourselves to third parties (or that we use to 
encrypt the disk -- not stored on-disk because hard disks are usually too easy 
to remove and read), but the BIOS will reveal it happily to a running system.  
And we've already determined that (in Alex's case) we're not trying to protect 
against people who can spy on our RAM or install other treacherous hardware 
(in a non-TPM sense, simply that it does something not quite equivalent to its 
normal expected function), because that already compromises everything.

FSF argument is that in our specific political circumstance, end-user can be 
defined legally and has a history of being used effectively to protect 
consumers, and TPM specifically is an attempt by manufacturers (and whoever 
pressures them) to take some control without putting out the expense, lack of 
modularity/interoperability/etc. to make their hardware actually hard to 
modify and put free software on.  Actually it's also an attempt to be 
deceptive because they're not banning end-user software freedom outright, so 
people and governments don't look as askance at the monopolies that could soon 
be imposed on the end-users, perhaps?

I think that we can understand these issues better when we actually have 
access to Free software (including BIOS) that implements a crypto stack to 
lock down a computer, on relatively Free hardware designed with some physical 
security (which is obviously possible, just as the mini-computers called TPMs 
are designed with some physical security).  Whole computer becomes analogous 
to TPM in its ability to hide keys etc. -- except that it can be unlocked.  
Then the issues go back to ones we've been dealing with for centuries, such as 
whether you should hide a spare key under the doormat in case something 
happens to the one you normally carry.  Ugh, alright, at least we're back in 
the physical.

-Isaac

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 09:10:11PM -0500, Isaac Dupree wrote:
> 
> (warning, I accidentally wrote a long essay exploring when these TPM-like 
> things are evil)
> 
> Okay, suppose we use this means to make them not-so-evil: "Buyer gets a 
> printed copy of the TPM's private key when they buy a board."  I'll call them 
> "(pseudo)TPMs" when they meet GNU demands.  (They could be built with Free 
> software, openly specified hardware designs, etc... why not throw in a bonus 
> :-))
> 
> Alex Besogonov's use case is still possible.  Which should make us suspicious 
> of whether our moral problem is solved.

I don't think there's anything morally wrong with Alex' use case, although
it's not technically unreplaceable either.

> I think my question is: how essential is it that individual people should 
> (always? usually?) have an easy time taking apart their computers, putting 
> them back together, and changing them, and having them behave as "black boxes" 
> to the outside world.

Note that our concern is software, not hardware.  Your microwave oven is
probably a computer too, and it's not a serious problem that it's locked
down and you can't change its software (that would be really dangerous!).

However, if your free programs, which you run on unlocked hardware, suddenly
stop working because they have to interact with third parties (e.g. a web
server) who now demand you use the "Trusted" version, you lose the ability to
modify them, which is one of your basic freedoms.

> I think that we can understand these issues better when we actually have 
> access to Free software (including BIOS) that implements a crypto stack to 
> lock down a computer, on relatively Free hardware designed with some physical 
> security (which is obviously possible, just as the mini-computers called TPMs 
> are designed with some physical security).  Whole computer becomes analogous 
> to TPM in its ability to hide keys etc. -- except that it can be unlocked.  
> Then the issues go back to ones we've been dealing with for centuries, such as 
> whether you should hide a spare key under the doormat in case something 
> happens to the one you normally carry.  Ugh, alright, at least we're back in 
> the physical.

Another interesting example are crypto cards.  They are designed to hide keys,
but they don't do any more than that.  They serve their purpose of
authenticating you to a third party, but can't spy on your memory, and
can't coerce you into running a certain program.

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan <rmh@aybabtu.com> wrote:
> I don't agree with this analogy.  Unlike cryptography, TPMs have been designed
> from the ground up to serve an evil purpose.  They *could* have designed
> them with good intent, for example either of these could apply:
>  - Buyer gets a printed copy of the TPM's private key when they buy a board.
Private part of the endorsement key _never_ leaves the device (if
manufacturer uses the recommended TPM_CreateEndorsementKeyPair
method). Even device manufacturer doesn't know it. Public key is then
signed by manufacturer's certificate. This ensures that the private
key can't be compromised. Besides, you can _disable_ endorsement key
(TPM_DisablePubekRead) to protect your privacy.

TPM also has a notion of "ownership", and it supports ownership change
(which requires physical presence of operator).

>  - An override button that's physically accessible from the chip can be
>    used to disable "hostile mode" and make the TPM sign everything.  From
>    that point physical access can be managed with traditional methods (e.g.
>    locks).
That's not a very good idea.

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 06:48:50PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan <rmh@aybabtu.com> wrote:
> > I don't agree with this analogy.  Unlike cryptography, TPMs have been designed
> > from the ground up to serve an evil purpose.  They *could* have designed
> > them with good intent, for example either of these could apply:
> >  - Buyer gets a printed copy of the TPM's private key when they buy a board.
> Private part of the endorsement key _never_ leaves the device (if
> manufacturer uses the recommended TPM_CreateEndorsementKeyPair
> method). Even device manufacturer doesn't know it.

Even if that is true (which I doubt), it's merely incidental, because...

> Public key is then
> signed by manufacturer's certificate. This ensures that the private
> key can't be compromised.

...this ensures that $evil_bob can challenge you to prove you're running
his proprietary anti-user software.

>Besides, you can _disable_ endorsement key
> (TPM_DisablePubekRead) to protect your privacy.

Of course.  And if you're serious about privacy, you can even trash your
computer or unplug it from the internet.

The question is, will it be practical for you to do disable the TPM a few
years from now?

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

Robert Millan wrote:
>> Private part of the endorsement key _never_ leaves the device (if
>> manufacturer uses the recommended TPM_CreateEndorsementKeyPair
>> method). Even device manufacturer doesn't know it.
> Even if that is true (which I doubt), it's merely incidental, because...
It's not really incidental. TCG was initially started as a group to 
develop trusted computing platform. MS later tried to hijack it to 
realize their wet dream of locked-down computer.

>> Public key is then
>> signed by manufacturer's certificate. This ensures that the private
>> key can't be compromised.
> ...this ensures that $evil_bob can challenge you to prove you're running
> his proprietary anti-user software.
So I won't be able to answer $evil_bob challenge in any case, since I'm 
mostly running Linux now.

> The question is, will it be practical for you to do disable the TPM a few
> years from now?
(I think yes, but that's not the point)

-- 
With respect,
             Alex Besogonov (cyberax@staffdirector.net)

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sun, Feb 22, 2009 at 03:02:43AM +0200, Alex Besogonov wrote:
> Robert Millan wrote:
>>> Private part of the endorsement key _never_ leaves the device (if
>>> manufacturer uses the recommended TPM_CreateEndorsementKeyPair
>>> method). Even device manufacturer doesn't know it.
>> Even if that is true (which I doubt), it's merely incidental, because...
> It's not really incidental. TCG was initially started as a group to  
> develop trusted computing platform. MS later tried to hijack it to  
> realize their wet dream of locked-down computer.

Well, sounds like either the hijack was succesful, or the wet dream was
shared.

>>> Public key is then
>>> signed by manufacturer's certificate. This ensures that the private
>>> key can't be compromised.
>> ...this ensures that $evil_bob can challenge you to prove you're running
>> his proprietary anti-user software.
> So I won't be able to answer $evil_bob challenge in any case, since I'm  
> mostly running Linux now.

That depends on what he considers trusted.  The capabilities are there and
got merged in Linux tree.  And who's scared of Vista anyways? ;-)

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan <rmh@aybabtu.com> wrote:
>  - An override button that's physically accessible from the chip can be
>    used to disable "hostile mode" and make the TPM sign everything.  From
>    that point physical access can be managed with traditional methods (e.g.
>    locks).
> But they didn't.
And actually, they did.
================================
New flexibility in EKs. In the 1.1b specification, endorsement keys
were fixed in the
chip at manufacture. This allowed a certificate to be provided by the
manufacturer for the
key. However, some privacy advocates are worried about the EK becoming
a nonchangeable
identifier (in spite of all the privacy controls around it, which
would make doing
this very difficult). ***As a result, the specification allows a
manufacturer to allow the key to
be removed by the end user and regenerated.*** Of course the
certificate at that point would
become worthless, and it could be very expensive for the end user to
get a new certificate.
================================
https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf

Re: A _good_ and valid use for TPM

[phcoder]

First of all you can write anything in specifications. Real chips don't 
necessary follow specifications. It's even said that it's "optional". 
Secondly this certificate makes regenerating worthless. Companies 
coercing you into using they software may challenge you to use signed 
public key. Then you still have a choice to regenerate your key but it's 
simply equivalent to "but nobody's threatening your freedom: we
   still allow you to remove your data and not access it at all.". It's 
equivalent to just smashing your tpm.
Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan <rmh@aybabtu.com> wrote:
>>  - An override button that's physically accessible from the chip can be
>>    used to disable "hostile mode" and make the TPM sign everything.  From
>>    that point physical access can be managed with traditional methods (e.g.
>>    locks).
>> But they didn't.
> And actually, they did.
> ================================
> New flexibility in EKs. In the 1.1b specification, endorsement keys
> were fixed in the
> chip at manufacture. This allowed a certificate to be provided by the
> manufacturer for the
> key. However, some privacy advocates are worried about the EK becoming
> a nonchangeable
> identifier (in spite of all the privacy controls around it, which
> would make doing
> this very difficult). ***As a result, the specification allows a
> manufacturer to allow the key to
> be removed by the end user and regenerated.*** Of course the
> certificate at that point would
> become worthless, and it could be very expensive for the end user to
> get a new certificate.
> ================================
> https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel

Re: A _good_ and valid use for TPM

[Robert Millan]

On Sat, Feb 21, 2009 at 06:58:58PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan <rmh@aybabtu.com> wrote:
> >  - An override button that's physically accessible from the chip can be
> >    used to disable "hostile mode" and make the TPM sign everything.  From
> >    that point physical access can be managed with traditional methods (e.g.
> >    locks).
> > But they didn't.
> And actually, they did.
> ================================
> New flexibility in EKs. In the 1.1b specification, endorsement keys
> were fixed in the
> chip at manufacture. This allowed a certificate to be provided by the
> manufacturer for the
> key. However, some privacy advocates are worried about the EK becoming
> a nonchangeable
> identifier (in spite of all the privacy controls around it, which
> would make doing
> this very difficult). ***As a result, the specification allows a
> manufacturer to allow the key to
> be removed by the end user and regenerated.*** Of course the
> certificate at that point would
> become worthless, and it could be very expensive for the end user to
> get a new certificate.
> ================================
> https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf

I would have to study this in detail, but I don't see the text saying that
remote attestation is no longer supported.

What this probably amounts to is that the coercion process can now be made
anonymously, which I already knew:

  http://en.wikipedia.org/wiki/Direct_anonymous_attestation

and which is not the core of the problem.

-- 
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: A _good_ and valid use for TPM

[Robert Millan]

On Fri, Feb 20, 2009 at 01:29:50AM +0100, Jan Alsenz wrote:
> First of all a TPM is not just some kind of secure memory only accessible from
> early BIOS, it basically is a small computer.

The thing is, we have many of these "small computers" in any standard PC.
Many of them are technically capable of performing crypto checks and validating
your memory.

What makes the TPM different is not what it is, but what is _designed for_.

When you get one, it comes with an hostile setup.  If this computer was a
crypto card, this would be no trouble, since the crypto card can't coerce you
into using proprietary software.  However, the TPM device is capable of
deciding for you when your computer is "clean" and when it isn't.  This
empowers third parties to figure out if you're "clean" or not.

To get the picture, imagine this situation:

  - Youtube demands you run approved version of Adobe Flash.

  - You don't want to use Adobe's proprietary program, you'd rather use
    Gnash instead.

  - Youtube can challenge you to use your TPM to prove you're running Flash.

Then you're forced into either bowing to your TPM or not watching any videos.

Such kind of submission to a small piece of silicon is not acceptable.

-- 
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: A _good_ and valid use for TPM

[Alex Besogonov]

>> The hard part is initializing the hardware without the use of the
>> original BIOS - the specifics of initializing various chips are not
>> public, and probably depend on companion hardware and/or trace length
>> on the particular board as well.
>It's not actually needed. If one can nop tpm code in bios then he can
>boot from anything and read tpm keys. You don't need to understand the
>whole bios to do it. Of course it's obfuscated but obfuscation isn't a
>security in any way. Also if you write completely different code to
>flash bios you don't need to be able to initialise the whole hardware
>all you need is being able to read tpm and write to serial port. Then
>you can simply read the key at your serial console. Actually bios isn't
>protected. It's just obfuscated.
It won't work. BIOS itself is checksummed by the TPM. And TPM by
design gains control even _before_ BIOS.