From: "Javier Martín" <lordhabbit@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: SHA-1 MBR
Date: Sat, 21 Feb 2009 02:21:41 +0100 [thread overview]
Message-ID: <1235179301.27212.10.camel@localhost> (raw)
In-Reply-To: <200902202002.12963.ml@isaac.cedarswampstudios.org>
[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]
El vie, 20-02-2009 a las 20:02 -0500, Isaac Dupree escribió:
> Jan Alsenz wrote:
> > Yes, that was my point. You need a trusted first step.
> > But the only thing besides a TPM, that can be used for this is the BIOS,
> > which can be flashed.
> > And even, if we assume, that we can construct a BIOS that only boots if the
> > MBR hash matches and can not be flashed prior to this point, there are
> > still two points missing:
> > - After the system has started, the BIOS could be flashed. This is a very
> > possible scenario in a multi user environment.
> > - They could take out the disk and put it in another machine, tamper with
> > the boot code and switch it on. And all your protection is gone.
> > Ok, you could try to put a needed key in the BIOS too, but then we're
> > back to problem one - and the BIOS can not check if a request for the key
> > is valid. I'm not even sure, if something in the BIOS can be read
> > protected.
>
> BIOS could be in ROM, un-flashable, including hash/keys and all! Refuse to
> boot if the hash doesn't match! Admittedly this poses some limitations on
> whether the system can be upgraded, depending how sophisticated you want to
> be.
This paranoid security talk is growing some big pink elephants which are
being conveniently ignored: you people are trying to protect a HD within
a computer that could be stolen, but you trust that the BIOS chip (in
ROM and whatever you want), which performs the systems initialization
(including RAM and the TPM) cannot be tampered with or even replaced.
When someone pointed the key-in-RAM problem the answer was "I'll just
glue it with epoxy resin"! For crying out loud! Without taking into
account that most epoxy resins take weeks to solidify under 100 ºC, if
the computer is physically stolen it could be subjected to EM-field
analysis. What will be the next madness? Will you wrap every RAM module
in tinfoil, a-la Faraday cage? Will you build a plasma shield around
them? This is going way out of proportion: with non-interactive key
initialization, if the computer is stolen, you are screwed period,
because you have a Mallory-on-steroids-holding-Alice-ransom instead of a
tame Eve. It does not take a rocket scientist (what I'm studying) nor a
cryptographer (one of my hobbies) to notice!
--
-- Lazy, Oblivious, Rational Disaster -- Habbit
[-- Attachment #2: Esta parte del mensaje está firmada digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
next prev parent reply other threads:[~2009-02-21 1:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-20 21:50 SHA-1 MBR phcoder
2009-02-20 23:06 ` Jan Alsenz
2009-02-20 23:41 ` phcoder
2009-02-21 0:32 ` Jan Alsenz
2009-02-21 1:02 ` Isaac Dupree
2009-02-21 1:21 ` Javier Martín [this message]
2009-02-21 9:43 ` phcoder
2009-02-21 8:56 ` Jan Alsenz
2009-02-21 13:27 ` phcoder
2009-02-21 14:12 ` phcoder
-- strict thread matches above, loose matches on Subject: below --
2009-02-21 2:21 Alex Besogonov
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=1235179301.27212.10.camel@localhost \
--to=lordhabbit@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.