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: Fri, 20 Feb 2009 12:27:28 +0100	[thread overview]
Message-ID: <499E93A0.2090108@gmail.com> (raw)
In-Reply-To: <200902200945.51426.michael@gorven.za.net>

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




  reply	other threads:[~2009-02-20 11:27 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
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 [this message]
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=499E93A0.2090108@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.