From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LaBlx-0000Es-CY for mharc-grub-devel@gnu.org; Thu, 19 Feb 2009 11:29:13 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaBlu-0000EF-47 for grub-devel@gnu.org; Thu, 19 Feb 2009 11:29:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaBlt-0000Dx-9q for grub-devel@gnu.org; Thu, 19 Feb 2009 11:29:09 -0500 Received: from [199.232.76.173] (port=33770 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaBlt-0000Ds-3B for grub-devel@gnu.org; Thu, 19 Feb 2009 11:29:09 -0500 Received: from fg-out-1718.google.com ([72.14.220.159]:53697) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaBls-0000Hh-FD for grub-devel@gnu.org; Thu, 19 Feb 2009 11:29:08 -0500 Received: by fg-out-1718.google.com with SMTP id l27so1155644fgb.30 for ; Thu, 19 Feb 2009 08:29:07 -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=lfdfk+foSn9qxCjGLJGppHrhDB9RnbLM+fPhEqO/RCk=; b=PSbdbpCd8G0UTz8WaAUybue/O1a1Ioin5o7BVQri4SZm0cp+upuy/zqQqoK92QMHru kiGN5wQYexauyTsZuUKuDXOs3OIF/cBoDlbtNr59ZGYbxAgOWJS2tVl3m7rC6vZ0PDEo q8hun4LBTxSMdyBKdcHa2DKrcOmo02KunaDgU= 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=Ubg/+hpEIEFPbmM678edWYt/atbxaub59XU0HxL1uvI8UhOPi+HpNXVw+hMq1f+lHx tLKRPCcCHSW6YuCgM/qH937a3CZguWnhBA4yNQo6fmyfynxTvZU4d1VZt0ysyU9JqClm 8tXfGnXHVDj6Pzjz7G6ZCQI1Rxipjc+xRsHpU= Received: by 10.86.96.18 with SMTP id t18mr437253fgb.17.1235060947208; Thu, 19 Feb 2009 08:29:07 -0800 (PST) Received: from ?192.168.1.2? (140-13.3-85.cust.bluewin.ch [85.3.13.140]) by mx.google.com with ESMTPS id e20sm1949109fga.36.2009.02.19.08.29.06 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 08:29:06 -0800 (PST) Message-ID: <499D88D2.8090004@gmail.com> Date: Thu, 19 Feb 2009 17:29:06 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <499C7809.6030203@student.ethz.ch> <499D7526.70907@gmail.com> <20090219073836.2d532392@gibibit.com> In-Reply-To: <20090219073836.2d532392@gibibit.com> 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: Thu, 19 Feb 2009 16:29:10 -0000 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