From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LZlLd-0004PE-Bb for mharc-grub-devel@gnu.org; Wed, 18 Feb 2009 07:16:17 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LZlLb-0004OM-42 for grub-devel@gnu.org; Wed, 18 Feb 2009 07:16:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LZlLa-0004Nx-BX for grub-devel@gnu.org; Wed, 18 Feb 2009 07:16:14 -0500 Received: from [199.232.76.173] (port=42323 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LZlLa-0004Ns-7U for grub-devel@gnu.org; Wed, 18 Feb 2009 07:16:14 -0500 Received: from mail-bw0-f208.google.com ([209.85.218.208]:55047) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LZlLZ-0000BY-PT for grub-devel@gnu.org; Wed, 18 Feb 2009 07:16:14 -0500 Received: by bwz4 with SMTP id 4so6196258bwz.18 for ; Wed, 18 Feb 2009 04:16:12 -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=D2z8oJ+at41AX5S1IxO1NXRZROQHaeYDWwtH1BOfxzc=; b=r/FA90Fdtolu6+iXnDARHQUWgb+V5AU75G0vN/Zk0mLB6+MMq2303mBMZQ0DerQ+Xe IhmNZa1wK1LadH1CKmGnAhpk4ARbSrpwWbFOEtiV7OshPt+ksEco1526dODZ/oaRxp4Z DajicMI4TPCIyGmMWk9MxCvHryPCexva7LZ+0= 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=nRzs3gEf70JNL/3WVdNhDr+NyqxIzz2LDnkkrn5tv5II5RpzI1wyq6qRcz/nMf0E/J aXHSKwqPe37ZENGtfCFIl5o17SxxO7biQMYaxmsZ25ugqFY5GvFRXC0api3PGhapmIZr w+Szro1zLeebugwb8zXXs+uhn2Ec3t78CInYQ= Received: by 10.223.105.140 with SMTP id t12mr1198209fao.12.1234959365950; Wed, 18 Feb 2009 04:16:05 -0800 (PST) Received: from ?82.130.79.144? (ifw-public-dock-144-dhcp.ethz.ch [82.130.79.144]) by mx.google.com with ESMTPS id 28sm6539163fkx.17.2009.02.18.04.16.05 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 04:16:05 -0800 (PST) Message-ID: <499BFC05.5050403@gmail.com> Date: Wed, 18 Feb 2009 13:16:05 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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: Wed, 18 Feb 2009 12:16:15 -0000 I don't know much about TPM but from example that I read at TreacherousGrub website actual verification is done by TreachorousGrub. I don't see how such a verification can protect against anything. 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. FSF acknowledges that treacherouscomputing may offer minor advantages but dissmisses the technology as whole and I agree with them. However, I'm neither a grub maintainer nor fsf representative. Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: > I know that TPM has been mentioned several times on this list. With > absolutely inadequate knee-jerk reactions from GRUB developers :( > > Currently I have a problem - I need to protect confidential private > data (we try to protect privacy of our customers) from the _physical_ > theft of the server. A simple full hard drive encryption should work > just fine except for one small detail - there's nobody to enter the > password when server reboots. > > I've solved this by adding an intermediate system which connects to > another server (which I consider physically secure), retrieves > decryption key and does kexec into the real OS passing this key as a > parameter. So I can just delete the key from the secure server to stop > the physically insecure sever from booting, it'll then be useless for > attackers since there's no decryption key present on it. > > However, it would be fairly trivial for attacker to steal the server > and/or make a full copy of its hard drive and then modify intermediate > system to print the decryption key. Not good. And there's no way to > solve it in software, since attacker can trivially change the > bootloader. > > So I've added another layer of security - I use TPM to remotely attest > that the bootloader and the intermediate system is not modified. It > requires chain of trust from BIOS to the intermediate system. So if > attacker tries to modify bootloader or intermediate system image - TPM > will not provide keys for communication with the secure server. > > Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed > to GNU gods then I can still retrieve all data because the main > decryption key is NOT kept in the TPM module (TPM is only used to > attest integrity of the system). Also, this is not a DRM scheme. > > So... Why not add TPM patches into the mainline GRUB2 project? GPLv3 > protects nicely against the possible DRM misuse of GRUB2 and TPM. Also > I can assist in forward-porting of 'Trusted GRUB' patch. > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel