From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LaAT4-0004Lc-7H for mharc-grub-devel@gnu.org; Thu, 19 Feb 2009 10:05:38 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LaAT2-0004J0-7x for grub-devel@gnu.org; Thu, 19 Feb 2009 10:05:36 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LaAT1-0004Hz-G8 for grub-devel@gnu.org; Thu, 19 Feb 2009 10:05:35 -0500 Received: from [199.232.76.173] (port=56225 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LaAT1-0004Hd-3e for grub-devel@gnu.org; Thu, 19 Feb 2009 10:05:35 -0500 Received: from mail-bw0-f160.google.com ([209.85.218.160]:46787) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LaAT0-0004Zz-AC for grub-devel@gnu.org; Thu, 19 Feb 2009 10:05:34 -0500 Received: by bwz4 with SMTP id 4so1247653bwz.18 for ; Thu, 19 Feb 2009 07:05:31 -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=mrcAE5gC/CNvUJFNB8VcGTN0VJnGsBVfVdb4ZRx8T2w=; b=HCMV6XO+ifvjcCgFUOYlwbWyCYtGXWcWM7TMb14GkO9rcNifAbyICCWfBlvM8Z4wzf oUR7vwKB89dyA3PUhOsbtFt9FzMiBoFIFfPaLC2joYS8ww+AFcX7UoVrk8dydxfvJ3aK G7ls3KOxQwN8kOSRo2UawTueENp/LuGVW/d0Y= 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=kWqtAjbvs4OU2W+v03s13Sl7WDAIhUkjv58HG0NvYMK4vm3yeHFtdtv7mI0Jw4NCH9 xFBSNT4maXA1KFP0ubLHxPiBfN4O/pmwHMS/l47b4slh779GIlY+3Es6EnzRk4Robiv3 zqjOAMEe2yg1N/LqvTJcJBbwH1M8pBHYg4LVw= Received: by 10.223.106.71 with SMTP id w7mr389029fao.22.1235055930932; Thu, 19 Feb 2009 07:05:30 -0800 (PST) Received: from ?82.130.80.231? (hg-public-dock-231-dhcp.ethz.ch [82.130.80.231]) by mx.google.com with ESMTPS id g28sm1306217fkg.18.2009.02.19.07.05.10 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Feb 2009 07:05:10 -0800 (PST) Message-ID: <499D7526.70907@gmail.com> Date: Thu, 19 Feb 2009 16:05:10 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <499C7809.6030203@student.ethz.ch> 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: Thu, 19 Feb 2009 15:05:36 -0000 First of all your system is still totally vulnerable to emanation and power analysis or hw tampering. 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) Personally if tpm support is merged into mainline grub2 I'll stop using it. However what you request doesn't need tpm. Authenticity of modules, configuration files and so on can be verified by one of 4 methods: 1) internal signatures 2) file in signed gpg container 3) detached signatures 4) signed hash file First three goals can be achieved by adding a layer similar to gzio behaviour of checking can be controlled by environment variables and flags passed to grub_signed_file_open (filename, flags); First advantage is that you can override it manually supplying grub password When signature module isn't loaded then this function is available as a dummy (all files are unsigned/wrong signature). Public key can be embedded in signature module. When loaded signature module sets strict signing policy which can be then overriden by variable (to set such a variable you need either password or a command in signed grub.cfg) Then these modules can be embedded in core.img. In this case if core.img is untampered everything is verified. Ensuring integrity of core.img is platform-dependent. Some platforms (openfirmware, efi, ...) load core.img directly and if they have an ability to check the boot image it's straightforward. I haven't thought yet how to do it in limited space of mbr. In coreboot scenario it's even the best bet. You can put grub2 in rom and if you use rom instead of flashrom it's a wonderful solution. But even if you use flash rom your security is similar to scenario you propose since as I said at the begining modyfiing flash bios you can bypass tpm scenario Advantage of this approach is the ability to safely update over network Forth goal can be achieved with usage of first part and function similar to sha1sum or whirlpoolsum (my prefered hash) Another idea: for some partitions (e.g. system partitions) signatures or mac can be much better. btrfs supports checksumming of data and metadata. Add mac support is easy. Signatures are more delicate I'm looking for compact and fast signatures. I personally would be interested in implementing security features in grub2 as long as tpm stays away Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: > On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz wrote: >> I've recently started porting TrustedGRUB ( >> http://sourceforge.net/projects/trustedgrub ) to GRUB2. >> I didn't get too far as I don't have too much time right now, but I managed to >> complete the MBR bootloader. > Great! MBR is the most scary part :) > >> I agree with you on the usefulness of a TPM for disk encryption and have a >> similar scheme planned. >> Regardless of the outcome of the discussion on the mailing list I would be >> interested in a "trusted" GRUB2 version. Maybe we could join forces? > Absolutely. I just hate doing work that won't appear in the mainline version :( > >> BTW, the "manufacturer key" everyone is talking about is usually referred to as >> "endorsement key", which is generated during production (and whose private part >> is considered possibly in the possession of the manufacturer). I heard, that >> some newer TPM versions support reinitializing this key, but I'm not sure of >> that. > Uhm... TPM_CreateEndorsementKeyPair can be used to create the > endorsement key pair, and the spec also says that TPM chip _must_ ship > with empty endorsement key. It also can later be changed. > >> And you do loose the ability to do remote attestation with "official" >> entities, if you do it. > Well, I don't care about that. And in any case, no-one uses TPM for > 'official' purposes. > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel