From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LaEbC-000257-B6 for mharc-grub-devel@gnu.org; Thu, 19 Feb 2009 14:30:18 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaEbA-00024Z-M8 for grub-devel@gnu.org; Thu, 19 Feb 2009 14:30:16 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaEb8-00023d-Ko for grub-devel@gnu.org; Thu, 19 Feb 2009 14:30:16 -0500 Received: from [199.232.76.173] (port=59546 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaEb8-00023O-9Z for grub-devel@gnu.org; Thu, 19 Feb 2009 14:30:14 -0500 Received: from mail-fx0-f174.google.com ([209.85.220.174]:36105) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaEb7-0004e3-Qj for grub-devel@gnu.org; Thu, 19 Feb 2009 14:30:14 -0500 Received: by fxm22 with SMTP id 22so100620fxm.18 for ; Thu, 19 Feb 2009 11:30: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=9OBFfa6ECI/YcawPhUZStpRd3aKyzTDTZwNnFvkYsGI=; b=cVu2xKPZfnrS40qdCTUjFeI/7OrbcLHM2MJDd76Y1MQUr619J505+J/J7TGT9kk8sd l28pEL5veP9hDkhc7lqwSTR9nNPOBMdX/LE44p2D6a7hNeVi6zrldOIK/J6Mlb+Cx1tv 9pyd+VidhAsjRQKEyYh/HDRnKa8mM13jVEFfk= 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=hDcNFQuBWaQlcCz688Vs/hL5wKt2VQ2iOfABLl38NptAHkMiQ+DINYW+YwfONyUXl6 tU5syJf+BOD99EkhxvBXIsmX+Grei/7SuOpzJOOu9iesDkZ0kcRZRUteGXVDoBPrkKqR J6OW2DY8Tqu5fi2x1mVb1TYs6vIUtFony5Q8s= Received: by 10.223.113.200 with SMTP id b8mr1108552faq.84.1235071812741; Thu, 19 Feb 2009 11:30:12 -0800 (PST) Received: from ?129.132.210.85? (vpn-global-dhcp3-085.ethz.ch [129.132.210.85]) by mx.google.com with ESMTPS id d13sm3048400fka.20.2009.02.19.11.30.11 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 11:30:12 -0800 (PST) Message-ID: <499DB343.9020301@gmail.com> Date: Thu, 19 Feb 2009 20:30:11 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Alex Besogonov , 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) Cc: 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: Thu, 19 Feb 2009 19:30:16 -0000 Alex Besogonov wrote: >> First of all your system is still totally vulnerable to emanation and >> power analysis or hw tampering. > Yes, but that's way too hard. Sure? There was a demonstration when rsa key was recovered just by plotting variations on powerline of usb port And what about cache attack? >> By reflashing bios one can bypass all >> tpm protections (don't say it's difficult because it's closed source and >> so on. Look at all closed source obfuscations/pseudo-protections that >> get cracked every day) > That's possible, but again I consider this not critical. BIOS itself > is checksummed and checked by the root of trust. Isn't bios (or part of it) the root of "trust" > >> Personally if tpm support is merged into mainline grub2 I'll stop using >> it. > Why? Because I don't want support this technology. TPM=obfuscation=unsecurity. And as an opensource and open security fan I can't claim to have solved an impossible problem. But if you want to use obfuscation schemes it's your right > Won't work. > > For example, attacker can run everything inside a hypervisor and then > just dump memory and extract decryption keys. You have no reliable > ways to detect hypervisor from inside the running OS. You can pile > layers upon layers of integrity checks, but they are useless if > hardware itself is not trusted. TPM allows me to establish this > trust. You assume that noone will develop hypervisor able to fool tpm bios. One could powercut the tpm chip (similar to how a resistor is remove to avoid burning efuses in xbox) then power would be reestablished to it and bios would be executed on hypervisor which will retrieve the keys. Actually you can trust tpm only as much as you trust in obfuscation power of bios. Only obfuscation prevents attacker from disconnecting tpm and reading keys from it. And there are only few types of tpm. Sooner or later someone will figure their interface. Then it can be read by special usb adapter > > Actually, I can probably even formally prove this assumption. > I really don't see you point. With my proposition mbr still can be verified by tpm but grub2 needs to know nothing about tpm as long as it ensures it doesn't load any unsigned modules. This approach is more versatile. It can be used also for e.g. checking that debian install is really from debian. And having experience with manufacturers supplying buggy hw and sw tend to avoid solutions directly relying on hardware when another implementation is possible Which collaboration other than not loading anything unchecked does your scheme need from grub? From readme of trustedgrub the only thing it does is checking integrity >> First advantage is that you can override it manually supplying grub password > Administrator can manually override TPM by supplying the decryption > key directly instead of fetching them from my key server. > > [skipped because this scheme just won't work] > >> I personally would be interested in implementing security features in >> grub2 as long as tpm stays away > Then that's a religion, not engineering. Tell it what you want but I don't trust code that I can't verify. And tpm is root of obfuscation. > > PS: please, can you CC me when you answer my posts? Could you come to irc channel or meet me at jabber/gtalk? Regards Vladimir 'phcoder' Serbinenko