From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LbGL2-0003l7-JU for mharc-grub-devel@gnu.org; Sun, 22 Feb 2009 10:33:52 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbGL1-0003jO-5p for grub-devel@gnu.org; Sun, 22 Feb 2009 10:33:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbGL0-0003ii-M2 for grub-devel@gnu.org; Sun, 22 Feb 2009 10:33:50 -0500 Received: from [199.232.76.173] (port=39803 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbGL0-0003iZ-GG for grub-devel@gnu.org; Sun, 22 Feb 2009 10:33:50 -0500 Received: from fg-out-1718.google.com ([72.14.220.155]:3692) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbGL0-0001Pz-0q for grub-devel@gnu.org; Sun, 22 Feb 2009 10:33:50 -0500 Received: by fg-out-1718.google.com with SMTP id l27so1799176fgb.30 for ; Sun, 22 Feb 2009 07:33:48 -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=YJq1rQHyE1T3ovElZk59gYOWS5nNOmXAFNC5Xsg8DW8=; b=AO8zg4eEFlvBCS6Yqz6vww2VKmMCFXrE5RBjP0Ck3ibb8VVw4T6kjglBGWuFIYLWxr EcS7v47iWlkDcb7+1xv2Eegggk5ZX7rHU8+DXbySvQ5syEPJ0Dq1vbhZq+yUA9qTttby iDuIE48kOpsqiJKR+I+Y7qWYcTHeyKD2TYD8A= 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=V/Ivwzq92W6T5QwrdHuvJCk+uVy6uIi50lGQxUUJPi0CPt5hmIa15HnreQH2PU39fQ 5ATcTHcf28A7RBBtyMcmQrT66QfU+Hw3Y+1LYC9/XiceVx/SQ2GeZRihRqgi31lucirZ kBnmIL72r2zeUa0TEK02YK0DtPcEO3Wbuvjfs= Received: by 10.86.4.2 with SMTP id 2mr2313280fgd.49.1235316828665; Sun, 22 Feb 2009 07:33:48 -0800 (PST) Received: from ?192.168.1.25? (112-27.1-85.cust.bluewin.ch [85.1.27.112]) by mx.google.com with ESMTPS id 4sm7281243fgg.55.2009.02.22.07.33.47 (version=SSLv3 cipher=RC4-MD5); Sun, 22 Feb 2009 07:33:48 -0800 (PST) Message-ID: <49A1705B.7030702@gmail.com> Date: Sun, 22 Feb 2009 16:33:47 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <499DF97E.1080800@student.ethz.ch> <20090221134607.GJ16068@thorin> <49A00DB7.2080003@student.ethz.ch> <20090221143440.GA16682@thorin> <49A0170E.9040908@student.ethz.ch> <20090221200844.GC18492@thorin> <49A11E82.2040909@gmail.com> 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: Sun, 22 Feb 2009 15:33:51 -0000 > For some reason he wants to store the data encrypted in multiple > locations rather than using a simple terminal to retreive the data > over network which makes things needlessly hard. He perhaps needs important amount of computing power. And in his case "all in centre" may require too much bandwidth > Now I am not sure how secure this solution is. You can usually remove > the battery to reset BIOS password, reflash the BIOS, etc. Many boards save the data in flash memory so removing power won't reset password. Second flash chip if it's dedicated can be covered with concrete too and resetting pins can be removed. Besides with coreboot everything this can be well controlled - you can embed the config to flash. > > Since manufacturers claim (or used to) that you can pry the TPM chip > off your board and it will still work the board is bootstrapped by the > main CPU, not the TPM. This makes it possible to short some pins on > the TPM chip so that is cannot be accessed during boot, boot a virtual > machine, and have the BIOS initialize the chip inside that. > It would require some modifications to virtual machine to skip some initilisation but is entirely possible and needs to be done only once to cover 99% of motherboards > There's also the possibility to remove the RAM from a running computer > given you find out what kind of RAM it uses and get a different > compatible computer. concrete :) > > Generally this shifts the attack from the realm of plain vandalism to > the realm of planned attack which is certainly a bonus. > > Still I would rather rely on a custom solution because I would know > exactly what it does. The manufacturers of PC mainboards tend to not > release exact specifications and there are often serious problems. > > Still finding the flaw in the particular mainboard would probably take > some non-trivial effort. There are only few kinds of tpm chips so it's enough that someone cracks the corresponding ship to make the attack trivial. As a matter of fact few year from now it may be easier to get a universal reader for all tpm chips then a reader for a specific flash chip > If the attacker just wants to break something there would likely be > easier targets. If you are specifically targeted you are doomed. Yes. Once an attacker has the device he is able to retrieve all the data in. Only putting physical obstacles may slow the attacker down. And I doubt that a cost of such operation can be over $10000 no matter what protection you use. > > Now to the TPM support in GRUB. > > This makes the TPM support debate seem quite pointless. > It isn't. Supporing tpm may help it becoming widespread, commonplace and acceptable, exactly what we try to avoid Regards Vladimir 'phcoder' Serbinenko