From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LdBcf-0005nu-MB for mharc-grub-devel@gnu.org; Fri, 27 Feb 2009 17:56:01 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LdBcd-0005nF-R1 for grub-devel@gnu.org; Fri, 27 Feb 2009 17:55:59 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LdBcc-0005md-Gp for grub-devel@gnu.org; Fri, 27 Feb 2009 17:55:59 -0500 Received: from [199.232.76.173] (port=58516 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LdBcb-0005ma-S5 for grub-devel@gnu.org; Fri, 27 Feb 2009 17:55:57 -0500 Received: from fg-out-1718.google.com ([72.14.220.155]:63723) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LdBcb-0002vQ-CL for grub-devel@gnu.org; Fri, 27 Feb 2009 17:55:57 -0500 Received: by fg-out-1718.google.com with SMTP id l27so683220fgb.30 for ; Fri, 27 Feb 2009 14:55:56 -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=9FcWC0cfNRJQBjZUqXTIeVWg9OMoUf3V00KGFm4KdEM=; b=pkN76WSM5nNrvVoAlWTrXDwpL7SypWaL5kbfR+Re/lX7iYHTSDf/vft3pjrpwxTjg4 STzQsxiaZOFz6sbA7lImNPfw2LXeVrsiTEwkYmPlwP5GHeIufrB2H6sxy0CvQt7ZIkuB wqd43MiiQK6Fob4HfCp0dRKkBmJadq6S8dUNI= 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=RQCgoQMLMeETIt4T8SzVfPvd98bhKsmo5dRDViH34aTp9PU4WxRKuc0fEMX7AG+DB8 QKHLjyE32YMaVmjnSUWEyjYl7zmjlaMjMIJXq1zGAUMPAdCP9JimtkQJpwG3CZCF5Cmc pKTMPCboBiAsibDJ8jawmotIFZqcO4Fr1yQ54= Received: by 10.86.94.11 with SMTP id r11mr3789342fgb.53.1235775356434; Fri, 27 Feb 2009 14:55:56 -0800 (PST) Received: from ?192.168.1.25? (220-185.62-81.cust.bluewin.ch [81.62.185.220]) by mx.google.com with ESMTPS id 3sm5363569fge.28.2009.02.27.14.55.55 (version=SSLv3 cipher=RC4-MD5); Fri, 27 Feb 2009 14:55:56 -0800 (PST) Message-ID: <49A86F7B.8030201@gmail.com> Date: Fri, 27 Feb 2009 23:55:55 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) 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> In-Reply-To: <20090227222230.GA7907@thorin> 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: 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 22:56:00 -0000 > > 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. 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. And 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. With XTS block encryptions depends neither on previous nor on next block . 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 -- Regards Vladimir 'phcoder' Serbinenko