From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LZnnV-00058I-Dm for mharc-grub-devel@gnu.org; Wed, 18 Feb 2009 09:53:13 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZnnT-000579-3e for grub-devel@gnu.org; Wed, 18 Feb 2009 09:53:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZnnR-00055l-GO for grub-devel@gnu.org; Wed, 18 Feb 2009 09:53:10 -0500 Received: from [199.232.76.173] (port=42982 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZnnR-00055f-7S for grub-devel@gnu.org; Wed, 18 Feb 2009 09:53:09 -0500 Received: from arnold.marlboro.edu ([206.192.68.78]:40889) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZnnQ-0004vr-My for grub-devel@gnu.org; Wed, 18 Feb 2009 09:53:09 -0500 Received: from akbar.marlboro.edu (akbar.marlboro.edu [10.1.2.5]) by arnold.marlboro.edu (Postfix) with ESMTP id E1B601780C5; Wed, 18 Feb 2009 09:52:16 -0500 (EST) Received: from xyz.marlboro.edu (xyz.marlboro.edu [10.1.2.29]) by akbar.marlboro.edu (Postfix) with ESMTP id DB21111E558; Wed, 18 Feb 2009 09:52:16 -0500 (EST) Received: from east.localnet (mdhcp5-170.marlboro.edu [10.1.5.170]) by xyz.marlboro.edu (Postfix) with ESMTP id 21B5C3AC01C; Wed, 18 Feb 2009 09:52:12 -0500 (EST) From: Isaac Dupree To: grub-devel@gnu.org Date: Wed, 18 Feb 2009 09:52:10 -0500 User-Agent: KMail/1.10.3 (Linux/2.6.27-11-generic; KDE/4.1.3; x86_64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902180952.10351.ml@isaac.cedarswampstudios.org> X-Marlboro-MailScanner-Information: Please contact techsupport@marlboro.edu for more information X-Marlboro-MailScanner: Found to be clean, clean X-Marlboro-Information: Please contact techsupport@marlboro.edu for more information X-Marlboro-MailScanner-ID: E1B601780C5.C44B6 X-Marlboro-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-4.399, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_00 -2.60) X-Marlboro-MailScanner-From: ml@isaac.cedarswampstudios.org X-Marlboro-MailScanner-Watermark: 1235573537.47321@lmJJd2Ha62CRBOZhX4Jwig X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Cc: Alex Besogonov 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: Wed, 18 Feb 2009 14:53:11 -0000 Alex Besogonov wrote: > There's no way to break this chain of trust without hacking TPM (which > I consider very unlikely) fair to say "unlikely" > doing uber-dirty hardware tricks (like > modifying RAM on-the-fly using DMA from rogue PCI devices) yeah, it's probably technically possible, but enough work to do that it's not worth guarding against. But guess what? While your system is running, they can take out your RAM and read it (disk-encryption key and all) before the RAM forgets its contents, see e.g. http://blogs.zdnet.com/security/?p=900 > or > exploiting some local vulnerability (which is rather unlikely). maybe. But how do you patch security vulnerabilities in e.g. the GRUB install, if modification = tampering? (I guess there's a way to do it, though.) > >If you suppose that your attacker is unable to tamper the hardware then > >bios and grub password is all you need. If you suppose that he can then > >you can't even trust your ram modules. It can be tampered in many ways > >like serving hacked bootloader or just being non-volatile then an > >attacker can read the key from memory. > > I'm trying to guard against attacker who can _steal_ the server itself > and/or tamper with the hardware. which is very difficult. Why do you have to reboot, though? and is there some way you can store the key locally in those cases, without compromising it further? > PS: please, at least read the relevant specs before calling TPM > 'Treacherous'. the ones that say to keep the keys in the hands of the manufacturers?(no I haven't read the specs either, maybe Robert Millan has though) -Isaac