From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LaTXc-0001KF-43 for mharc-grub-devel@gnu.org; Fri, 20 Feb 2009 06:27:36 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaTXY-0001JA-Ut for grub-devel@gnu.org; Fri, 20 Feb 2009 06:27:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaTXW-0001IR-WE for grub-devel@gnu.org; Fri, 20 Feb 2009 06:27:32 -0500 Received: from [199.232.76.173] (port=48329 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaTXW-0001IL-Rk for grub-devel@gnu.org; Fri, 20 Feb 2009 06:27:30 -0500 Received: from fg-out-1718.google.com ([72.14.220.152]:56805) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaTXV-0002QL-UQ for grub-devel@gnu.org; Fri, 20 Feb 2009 06:27:30 -0500 Received: by fg-out-1718.google.com with SMTP id l27so1387910fgb.30 for ; Fri, 20 Feb 2009 03:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=L+VdnNYT0v7Oir0scSehq3KPpdzCm+uPFDnJn167z9s=; b=le9epCzXfPvqSCxMI/UQMUbBVhZ1L4GoeEarAzEAYAQVE3T0l+ys+1b8QF2y6owaZe D+fTUvukqKhG1QHPzhfF0YMTqgJ6KVDK48MiIVYONCMxkOa8Lwr8VYe+Y1Pp18/hCck/ 6QTSvHp/kAKoafoP9Slmt1fJaKnjvd//4kqMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=IcjkRuXEswO5Fd6pznPLL9g+1dxc2wEqLUlWvZPnjoGmWN15Q0tDLMHpNkxxaXedV2 Mezzz2Vbo+oxZHESBx8GY8QHlrYDR3Om7HmBoTXHpS5aujfZJwoHnGYjuTG1+pDXeTKt IgEQKB8YmhEmwi8vYNPAcTv15Khx7R+gW+MF0= Received: by 10.86.53.8 with SMTP id b8mr991911fga.58.1235129249007; Fri, 20 Feb 2009 03:27:29 -0800 (PST) Received: from ?192.168.1.25? (184-134.62-81.cust.bluewin.ch [81.62.134.184]) by mx.google.com with ESMTPS id d6sm2069743fga.59.2009.02.20.03.27.28 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Feb 2009 03:27:28 -0800 (PST) Message-ID: <499E93A0.2090108@gmail.com> Date: Fri, 20 Feb 2009 12:27:28 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <499DF97E.1080800@student.ethz.ch> <200902200945.51426.michael@gorven.za.net> In-Reply-To: <200902200945.51426.michael@gorven.za.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: A _good_ and valid use for TPM X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 11:27:33 -0000 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