From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LafoO-0006rp-Us for mharc-grub-devel@gnu.org; Fri, 20 Feb 2009 19:33:44 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LafoN-0006rk-OR for grub-devel@gnu.org; Fri, 20 Feb 2009 19:33:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LafoN-0006rY-2H for grub-devel@gnu.org; Fri, 20 Feb 2009 19:33:43 -0500 Received: from [199.232.76.173] (port=33690 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LafoM-0006rV-Vb for grub-devel@gnu.org; Fri, 20 Feb 2009 19:33:43 -0500 Received: from xsmtp0.ethz.ch ([82.130.70.14]:9335) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LafoM-0004dk-JZ for grub-devel@gnu.org; Fri, 20 Feb 2009 19:33:42 -0500 Received: from xfe1.d.ethz.ch ([82.130.124.41]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Feb 2009 01:33:39 +0100 Received: from [192.168.2.75] ([81.221.97.38]) by xfe1.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Feb 2009 01:33:39 +0100 Message-ID: <499F4B86.2000904@student.ethz.ch> Date: Sat, 21 Feb 2009 01:32:06 +0100 From: Jan Alsenz User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: The development of GRUB 2 References: <499F25B0.8000202@gmail.com> <499F376C.60906@student.ethz.ch> <499F3FB9.9070304@gmail.com> In-Reply-To: <499F3FB9.9070304@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig035891D288B0BA342B2467E6" X-OriginalArrivalTime: 21 Feb 2009 00:33:39.0731 (UTC) FILETIME=[0A92FE30:01C993BC] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ Subject: Re: SHA-1 MBR 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: Sat, 21 Feb 2009 00:33:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig035891D288B0BA342B2467E6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable phcoder wrote: >> It's not complete SHA-1, but the rest should be just a constant offset= =2E > I already said how it differs from standard one. If you feed padded > byteswapped data to it and then byteswap the rsult back you obtain > exactly normal SHA-1. But as I said if size is fixed it's compeletely > equivalent in security to normal SHA-1 (you can easily prove formally > that any successful attack on one variant immediately results in > successful attack on another variant) That's what I meant ;) >> But I'm still not sure, what you are trying to do here, is the MBR >> your root of >> trust? >=20 > I'm trying to achieve universal verification scheme which is able to do= > what is needed to support tpm ("prolonging chain of trust" in tpm > unstandard parlance) without using tpm itself. Such scheme can in futur= e > be useful in other applications as well. Okay. But I think it won't work. >> If not, who checks the MBR? > This can't be done by grub because it happens before any part of grub i= s > loaded. to verify grub you need to rely on vendor/platform-specific > mechanisms. > I personally find "tpm without tpm" more attractive because it can be > easily reused on another platform or any alternative to tpm (perhaps > anybody here or coreboot folks will come up with something). > Additionally it workarounds many bios and tpm bugs. > I will continue working on sha-1 boot. My goal is to load core.img > checked. After that point there is much more space and any signature > based solution can be used. 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 t= he 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 b= ack to problem one - and the BIOS can not check if a request for the key is vali= d. I'm not even sure, if something in the BIOS can be read protected. Greets, Jan --------------enig035891D288B0BA342B2467E6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmfS5EACgkQfZylhtn4Xvdo3QCdGyqrVjj1bIUtwiWNAUXHWsHf 4a8An123CXyohmDXN65JAzZVfX+QRWAi =Ei2M -----END PGP SIGNATURE----- --------------enig035891D288B0BA342B2467E6--