From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from <gentoo-dev+bounces-52653-garchives=archives.gentoo.org@lists.gentoo.org>) id 1SgM8F-0002E8-9F for garchives@archives.gentoo.org; Sun, 17 Jun 2012 20:31:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CFB48E06F4; Sun, 17 Jun 2012 20:31:09 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by pigeon.gentoo.org (Postfix) with ESMTP id F21D1E0686 for <gentoo-dev@lists.gentoo.org>; Sun, 17 Jun 2012 20:30:23 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B03BB21323 for <gentoo-dev@lists.gentoo.org>; Sun, 17 Jun 2012 16:30:23 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Sun, 17 Jun 2012 16:30:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=binarywings.net; h=message-id:date:from:mime-version:to:subject:references :in-reply-to:content-type; s=mesmtp; bh=IkPvaR8lvx1+d19BF6TnX0Uk loE=; b=immMgyg8jJhtZXjiAbRLuWqFdFDjRZIx31xPdq6KnMwOSZqNJh9mCmlX Ih/TTfocKl710U6saeRJeh0CHQfQ0o8HsKFs5Wgi3UaruVPOOkD37PS6ofMNnw4p lSKCCXKQ8oW95vkZREggHOYlS14sGLhF9Yhbja3oadU8OtOkPvw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to :subject:references:in-reply-to:content-type; s=smtpout; bh=IkPv aR8lvx1+d19BF6TnX0UkloE=; b=SFNArYmEz71ljH6g47tJyr5q68hu/DSvTXcz bAVoCvu0TG6Nt8+R1dgT5nd1w1dsKH4QueUE9Puf3X3BiFGTq2/aMWqHof9J4nnK fDQVwmrdSBHWHdIFMwNA23v6D+eUcvJnCfmqjue2ttRSAELQnqxl6GxwMt+CNeEe XBZZuhU= X-Sasl-enc: Qm2HGT9JYarZhtIOnv1uIymjgwx/3qu9qMWU2ayOB+GT 1339965022 Received: from [192.168.5.18] (unknown [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPA id 2336F8E0204 for <gentoo-dev@lists.gentoo.org>; Sun, 17 Jun 2012 16:30:21 -0400 (EDT) Message-ID: <4FDE3E57.80509@binarywings.net> Date: Sun, 17 Jun 2012 22:30:15 +0200 From: Florian Philipp <lists@binarywings.net> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120602 Thunderbird/10.0.4 Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Re: UEFI secure boot and Gentoo References: <20120615042810.GA9480@kroah.com> <1694115.BlGnUZZYGL@mephista> <4FDE1B53.3010905@binarywings.net> <5086026.lT0ZpIOn34@mephista> In-Reply-To: <5086026.lT0ZpIOn34@mephista> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6C345E30C71826F1A8FBD7A7" X-Archives-Salt: 604bb22e-1b74-4c55-99fb-88aaa551c5b8 X-Archives-Hash: 583be9ff36beeb03e87565428b96627a This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6C345E30C71826F1A8FBD7A7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 17.06.2012 20:56, schrieb Sascha Cunz: > On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote: >> Am 17.06.2012 19:34, schrieb Sascha Cunz: >>> [...] >>> >>>> It doesn't. It's just a very long wooden fence; you just didn't find= >>>> the hole yet. >>> >>> Given the fact that the keys in the BIOS must somehow get there and i= t >>> must >>> also be able to update them (how to revoke or add keys else?). >>> >>> Unless this is completely done in hardware, there must be a software = doing >>> it. Software can - by design - be reverse engineered; in some countri= es >>> even legally without any further agreement or license. >>> >>> So, you can sign, encrypt, obfuscate or use some other foobar-mechani= sm on >>> this blob of software - at some point it must be readable from the >>> processor, so you have to provide the mechanisms to verify signs, und= o >>> encryption etc somewhere (either in hardware or another software). >>> >>> Even if you somehow manage to embed all of this in the hardware stack= , it >>> would still require some kind of interface to get updated / revoked k= eys >>> to >>> operate on. >>> >>> It's not a matter of *if this can* be broken by someone who cares, it= 's a >>> matter of *how long does it take* for someone who cares to break it. >>> >>> In the end, this is just another kind of "seems to be secure for a da= y or >>> two". Admittedly a complex one - but there will always be a "kid in a= >>> garage" that is able to set everyone else out of business. >>> >>> SaCu >> >> Okay, a few points here: >> >> First: On an abstract level, the key innovation in Secure Boot and >> driver signing is that it establishes a trust relationship between >> platform owner and platform firmware (using a so called Platform Key) = as >> well as trust between operating system and platform firmware (using Ke= y >> Exchange Keys). >=20 > You've said yourself, that "some removable media might not require sign= atures"=20 > in order to boot. Well, if that is the case, then isn't this defeating = the=20 > whole point of Secure Boot at that stage? >=20 No. If that was the case, then UEFI shouldn't allow deactivating Secure Boot, should it? Secure Boot's primary purpose is to prevent malware from installing itself into the bootloader or (by extension) the kernel image. >> Under the assumption that the implementation is correct, nothing on th= e >> operating system level can inject drivers, boot loaders or whatever el= se >> into the firmware unless it is properly signed. The platform will not >> allow anything unless it is bit-by-bit verified to come from the >> platform owner or a trusted third party. The recommended algorithms fo= r >> signing and verifying code are SHA-256 and RSA-2048. Good luck breakin= g >> that in "a day or two"! >> >> Second point: Secure Boot is not designed to protect against an attack= er >> with physical access to the machine. So you can leave your soldering >> iron and memory stick at home when you try to prove that Secure Boot c= an >> be broken. >=20 > I was under the impression that it should at least help in that scenari= o.=20 > OTOH, if it takes a compromised system or physical access to the machin= e in=20 > order to manipulate the boot sequence, then I no longer understand what= the=20 > boot sequence in such a system must be protected against (Assuming that= the=20 > primary reason for boot sequence manipulation is to later on compromise= the=20 > system). >=20 Well, it does help, especially when you also prevent changing UEFI settings with a password. However, there are so many variables and possibilities when talking about attacks on physically accessible systems, that you're usually screwed anyway. Again, the point is that malware, even if it gets temporary access to your system, even if it gets root access, cannot install itself into the boot process. It cannot persist in kernel space. >> Third point: Of course Secure Boot will be broken! A mainboard maker >> will screw up, there will be a bug in the specs or RSA will be broken.= >> And when one of these happens, it will be fixed. Plain and simple. We >> didn't abandon SSL just because version 1 and 2 were broken. Why shoul= d >> we abandon Secure Boot? >=20 > "Plain and simple" here probably means, that all (at least many) sold s= ystem=20 > up to that date are downgraded to "unsecure". Not every user out there = is=20 > reachable by any channel telling that it is just now a hard requirement= to=20 > update the system - and even getting the message to the user won't caus= e 100%=20 > of the reached users to go that upgrade path. >=20 Yes, you are right here. But ultimately, any bugs will be fixed. Even if it means waiting for the next device generation. Regards, Florian Philipp --------------enig6C345E30C71826F1A8FBD7A7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/ePlsACgkQqs4uOUlOuU/g8gCfZqa0zMTCI4b4MZbugxFjjMwC dF4An2gAlFW+DzuUAlPfFFXyMyzYiKGE =o1Fo -----END PGP SIGNATURE----- --------------enig6C345E30C71826F1A8FBD7A7--