From: phcoder <phcoder@gmail.com>
To: Alex Besogonov <alex.besogonov@gmail.com>,
The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: A _good_ and valid use for TPM
Date: Thu, 19 Feb 2009 20:30:11 +0100 [thread overview]
Message-ID: <499DB343.9020301@gmail.com> (raw)
In-Reply-To: <f9ca530f0902190943w37b6b6d1pb28d78748607a772@mail.gmail.com>
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
next prev parent reply other threads:[~2009-02-19 19:30 UTC|newest]
Thread overview: 74+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-19 17:43 A _good_ and valid use for TPM Alex Besogonov
2009-02-19 19:30 ` phcoder [this message]
2009-02-19 21:00 ` Alex Besogonov
2009-02-20 0:29 ` Jan Alsenz
2009-02-20 1:03 ` Alex Besogonov
2009-02-20 7:47 ` Jan Alsenz
2009-02-22 1:14 ` Alex Besogonov
2009-02-27 19:59 ` Robert Millan
2009-02-21 13:46 ` Robert Millan
2009-02-21 14:20 ` Jan Alsenz
2009-02-21 14:34 ` Robert Millan
2009-02-21 15:00 ` Jan Alsenz
2009-02-21 20:08 ` Robert Millan
2009-02-22 1:21 ` Alex Besogonov
2009-02-22 9:44 ` phcoder
2009-02-22 14:49 ` Michal Suchanek
2009-02-22 15:33 ` phcoder
2009-02-23 2:34 ` step21
2009-02-23 13:35 ` Michal Suchanek
2009-02-27 20:07 ` Robert Millan
2009-02-27 20:03 ` Robert Millan
2009-02-21 16:29 ` Alex Besogonov
2009-02-21 17:03 ` phcoder
2009-02-21 20:23 ` Robert Millan
2009-02-21 20:21 ` Robert Millan
2009-02-22 1:26 ` Alex Besogonov
2009-02-27 20:13 ` Robert Millan
2009-02-20 7:45 ` Michael Gorven
2009-02-20 11:27 ` phcoder
2009-02-20 12:12 ` Michael Gorven
2009-02-20 17:31 ` Jan Alsenz
2009-02-20 18:35 ` Vesa Jääskeläinen
2009-02-20 19:35 ` Jan Alsenz
2009-02-21 13:59 ` Robert Millan
2009-02-21 13:51 ` Robert Millan
2009-02-21 15:29 ` Michael Gorven
2009-02-21 20:31 ` Robert Millan
2009-02-21 20:43 ` Michael Gorven
2009-02-21 21:04 ` Robert Millan
2009-02-21 21:17 ` Jan Alsenz
2009-02-21 21:27 ` phcoder
2009-02-21 21:32 ` Robert Millan
2009-02-21 21:57 ` Jan Alsenz
2009-02-21 23:19 ` Robert Millan
2009-02-21 21:04 ` Jan Alsenz
2009-02-21 21:27 ` Robert Millan
2009-02-22 2:10 ` Isaac Dupree
2009-02-27 20:28 ` Robert Millan
2009-02-21 16:48 ` Alex Besogonov
2009-02-21 20:39 ` Robert Millan
2009-02-22 1:02 ` Alex Besogonov
2009-02-27 20:33 ` Robert Millan
2009-02-21 16:58 ` Alex Besogonov
2009-02-21 17:08 ` phcoder
2009-02-21 20:43 ` Robert Millan
2009-02-21 13:31 ` Robert Millan
-- strict thread matches above, loose matches on Subject: below --
2009-02-21 2:27 Alex Besogonov
2009-02-18 14:10 Alex Besogonov
2009-02-18 14:52 ` Isaac Dupree
2009-02-18 15:10 ` Alex Besogonov
2009-02-18 22:03 ` Isaac Dupree
2009-02-19 9:46 ` Alex Besogonov
2009-02-18 9:10 Alex Besogonov
2009-02-18 12:16 ` phcoder
[not found] ` <499C7809.6030203@student.ethz.ch>
2009-02-19 10:21 ` Alex Besogonov
2009-02-19 15:05 ` phcoder
2009-02-19 15:38 ` Colin D Bennett
2009-02-19 16:29 ` phcoder
2009-02-21 13:38 ` Robert Millan
2009-02-21 13:43 ` phcoder
2009-02-21 14:00 ` Jan Alsenz
2009-02-19 15:44 ` Michal Suchanek
2009-02-19 16:02 ` phcoder
2009-02-21 13:22 ` Robert Millan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=499DB343.9020301@gmail.com \
--to=phcoder@gmail.com \
--cc=alex.besogonov@gmail.com \
--cc=grub-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.