From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdBs8-0003Hj-Cr for mharc-grub-devel@gnu.org; Fri, 27 Feb 2009 18:12:00 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdBs6-0003HM-Gk for grub-devel@gnu.org; Fri, 27 Feb 2009 18:11:58 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdBs4-0003HA-Qv for grub-devel@gnu.org; Fri, 27 Feb 2009 18:11:58 -0500 Received: from [199.232.76.173] (port=49167 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdBs4-0003H7-Mm for grub-devel@gnu.org; Fri, 27 Feb 2009 18:11:56 -0500 Received: from xsmtp0.ethz.ch ([82.130.70.14]:19717) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdBs4-0004MV-Fm for grub-devel@gnu.org; Fri, 27 Feb 2009 18:11:56 -0500 Received: from xfe2.d.ethz.ch ([82.130.124.42]) by XSMTP0.ethz.ch with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Feb 2009 00:11:51 +0100 Received: from [192.168.2.75] ([81.221.130.170]) by xfe2.d.ethz.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Feb 2009 00:11:52 +0100 Message-ID: <49A872D1.5010608@student.ethz.ch> Date: Sat, 28 Feb 2009 00:10:09 +0100 From: Jan Alsenz User-Agent: Thunderbird 2.0.0.19 (X11/20090104) MIME-Version: 1.0 To: The development of GRUB 2 References: <49A152BD.6010907@student.ethz.ch> <20090227204226.GI31629@thorin> <49A861A0.2000601@student.ethz.ch> <20090227222230.GA7907@thorin> <49A86F7B.8030201@gmail.com> In-Reply-To: <49A86F7B.8030201@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2CB30853E26C7CBF935F06A4" X-OriginalArrivalTime: 27 Feb 2009 23:11:52.0097 (UTC) FILETIME=[C649B910:01C99930] X-detected-operating-system: by monty-python.gnu.org: Windows 2000 SP4, XP SP1+ Subject: Re: GRUB hardened boot framework 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, 27 Feb 2009 23:11:58 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2CB30853E26C7CBF935F06A4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable phcoder wrote: >> >> I'm no crypto expert, but I was under the impression that when the >> data is >> encrypted, measurement comes "for free": if someone tampered it, you'd= be >> unable to decrypt. Is this correct? >> > It's not. Encryption is permutation > E_{key,sector} (P) -> C > Which permutes transforms plaintext P to ciphertext P. Without knowing > the key an attacker still can reuse the values he has already seen (e.g= =2E > if he has an image of FS at previous date). > He can also replace the sector with anything. He can't predict to what > it will be decrypted but not to what it originally was > Additionally most current modes subdivide sectors in 16-byte blocks. An= d > how a block is encrypted depends on previous but not next blocks in > sector. Then if attacker knows where the authentication is he can > rewrite this place with anything. It will decrypt to garbage and with > some quite high probability it won't crash and will let the attacker in= =2E > With XTS block encryptions depends neither on previous nor on next bloc= k > . So attacker doesn't even need the authenthication code to be at the > end of the sector. > In various CBC modes if an attacker replaces sector A with sector B > first block of sector B will decrypt to garbage but the rest will > decrypt just fine. It can be used for e.g. launching printk to output > the encryption keys. > In conclusion encryption doesn't check for modifications. Some > encryption systems do it additionally through separate mechanism but > encryption itself does no such thing If the code that does the authentication is loaded from the encrypted par= tition, without being checked, this is true, but we assume, that core.img is alre= ady loaded (and checked), so the authentication code is not on the encrypted partition, and can detect any tampering. Greets, Jan --------------enig2CB30853E26C7CBF935F06A4 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) iEYEARECAAYFAkmoctYACgkQfZylhtn4XveIYACgqPyyuShSBi/6kbUN4cGTU9Sm l1gAoIYs4YUISkeMkbvl2vqRuCKqb4YW =cxlg -----END PGP SIGNATURE----- --------------enig2CB30853E26C7CBF935F06A4--