From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LavLT-0004QP-Ft for mharc-grub-devel@gnu.org; Sat, 21 Feb 2009 12:08:55 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LavLR-0004PW-Fh for grub-devel@gnu.org; Sat, 21 Feb 2009 12:08:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LavLP-0004Ox-VS for grub-devel@gnu.org; Sat, 21 Feb 2009 12:08:53 -0500 Received: from [199.232.76.173] (port=33331 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LavLP-0004Oo-PB for grub-devel@gnu.org; Sat, 21 Feb 2009 12:08:51 -0500 Received: from fg-out-1718.google.com ([72.14.220.156]:38938) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LavLM-0001H9-2b for grub-devel@gnu.org; Sat, 21 Feb 2009 12:08:50 -0500 Received: by fg-out-1718.google.com with SMTP id l27so1676904fgb.30 for ; Sat, 21 Feb 2009 09:08:47 -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=t+jW2no+/1OUutAoKgi8Xu9TCmhPnqjjJxAdf0GIAKw=; b=xEnZCUAQh+R6E5RWKcKNrENgaTkdlbOgTuMi9YAgLanw6yA/0RiVZDH+50OjFuADMR fibTbwhMkMSjPwonY6raD6/gRGqFfT3YUKky2mXHktaNErecelfYxLWVsd0C721eyjrB 4AW62EMQCB3Zv4UmePJ+ql7AtRyiDH4NwUKUo= 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=AnTyHd85NerttomkvkGBR7jASuHj+GtLzkTniDCz1y1udYBvTinvaHOqdtg5z+1YHS YtJfsotY6EkFZ5TUNgbpTCwSXE8TyKyqS3CadfpwRmOhrD7xUns687kmQoOuAb0Z0vOg OaNGIyyhUAfySadCvxv+2tGFa+AWedi5CNfhc= Received: by 10.86.4.2 with SMTP id 2mr1787330fgd.49.1235236127141; Sat, 21 Feb 2009 09:08:47 -0800 (PST) Received: from ?192.168.1.25? (166-90.62-81.cust.bluewin.ch [81.62.90.166]) by mx.google.com with ESMTPS id d4sm5998906fga.58.2009.02.21.09.08.46 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Feb 2009 09:08:46 -0800 (PST) Message-ID: <49A0351D.5000703@gmail.com> Date: Sat, 21 Feb 2009 18:08:45 +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> <200902200945.51426.michael@gorven.za.net> <20090221135142.GK16068@thorin> 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: Sat, 21 Feb 2009 17:08:53 -0000 First of all you can write anything in specifications. Real chips don't necessary follow specifications. It's even said that it's "optional". Secondly this certificate makes regenerating worthless. Companies coercing you into using they software may challenge you to use signed public key. Then you still have a choice to regenerate your key but it's simply equivalent to "but nobody's threatening your freedom: we still allow you to remove your data and not access it at all.". It's equivalent to just smashing your tpm. Regards Vladimir 'phcoder' Serbinenko Alex Besogonov wrote: > On Sat, Feb 21, 2009 at 3:51 PM, Robert Millan wrote: >> - An override button that's physically accessible from the chip can be >> used to disable "hostile mode" and make the TPM sign everything. From >> that point physical access can be managed with traditional methods (e.g. >> locks). >> But they didn't. > And actually, they did. > ================================ > New flexibility in EKs. In the 1.1b specification, endorsement keys > were fixed in the > chip at manufacture. This allowed a certificate to be provided by the > manufacturer for the > key. However, some privacy advocates are worried about the EK becoming > a nonchangeable > identifier (in spite of all the privacy controls around it, which > would make doing > this very difficult). ***As a result, the specification allows a > manufacturer to allow the key to > be removed by the end user and regenerated.*** Of course the > certificate at that point would > become worthless, and it could be very expensive for the end user to > get a new certificate. > ================================ > https://www.trustedcomputinggroup.org/specs/TSS/TSS_1_2_Errata_A-final.pdf > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel