All of lore.kernel.org
 help / color / mirror / Atom feed
From: phcoder <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: A _good_ and valid use for TPM
Date: Thu, 19 Feb 2009 17:29:06 +0100	[thread overview]
Message-ID: <499D88D2.8090004@gmail.com> (raw)
In-Reply-To: <20090219073836.2d532392@gibibit.com>

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



  reply	other threads:[~2009-02-19 16:29 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-18  9:10 A _good_ and valid use for TPM 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 [this message]
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
  -- strict thread matches above, loose matches on Subject: below --
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-19 17:43 Alex Besogonov
2009-02-19 19:30 ` phcoder
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
2009-02-21  2:27 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=499D88D2.8090004@gmail.com \
    --to=phcoder@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.