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 t
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 boar
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.
>>
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.
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 TPM
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 se
2009/2/23 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/rum
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
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
On 22/02/2009, phcoder 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
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 t
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
> > > > e
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
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 l
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 modu
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 incide
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 on
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 backdo
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 s
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 as
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
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 c
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 rem
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 th
On Sat, Feb 21, 2009 at 06:58:58PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan 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 physic
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 b
On Sat, Feb 21, 2009 at 06:48:50PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan 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
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 cryptograph
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, t
On Sat, Feb 21, 2009 at 06:29:01PM +0200, Alex Besogonov wrote:
> On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan 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 simpl
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
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
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 a
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan 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).
> B
On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan 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 prin
On Sat, Feb 21, 2009 at 3:46 PM, Robert Millan 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 anyt
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 b
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:
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 keyser
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
>> wrote:
>> [skip]
>>>The TPM can proof to another party, that the PCRs have certain
>>> values (of
>>> course the communication needs to be established
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
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.
GRU
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 a
On Fri, Feb 20, 2009 at 03:03:04AM +0200, Alex Besogonov wrote:
> On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz 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
>
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
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
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 capabl
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 f
>> 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
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.
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 m
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 wit
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 pas
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 i
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 loo
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 th
On Fri, Feb 20, 2009 at 2:29 AM, Jan Alsenz 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 Besogono
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 rea
On Thu, Feb 19, 2009 at 9:30 PM, phcoder 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
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 attac
>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/pseu
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
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 t
2009/2/19 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-prote
On Thu, 19 Feb 2009 16:05:10 +0100
phcoder 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
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
On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz 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 p
On Thu, Feb 19, 2009 at 12:03 AM, Isaac Dupree
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
Alex Besogonov wrote:
> On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree
>
> 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.zdne
On Wed, Feb 18, 2009 at 4:52 PM, Isaac Dupree
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 th
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 en
>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 G
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
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 sim
74 matches
Mail list logo