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 ) id 1SgJph-0001zQ-GU for garchives@archives.gentoo.org; Sun, 17 Jun 2012 18:04:21 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 62463E087E; Sun, 17 Jun 2012 18:03:23 +0000 (UTC) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by pigeon.gentoo.org (Postfix) with ESMTP id 6D3CAE0839 for ; Sun, 17 Jun 2012 18:00:59 +0000 (UTC) Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 237B320A9F for ; Sun, 17 Jun 2012 14:00:59 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute2.internal (MEProxy); Sun, 17 Jun 2012 14:00:59 -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=SFlCdnI43zbSoNFXAAx/IxXf g+c=; b=DZRXiRbFuKhF8h9hGe34IOrBz1ty9/VJvP3hvLcUUoAVDVLZU7ElkKSM 4NZCoenZ5DIxzb0a0A8jjBk5VC4FuZfbTRxSmUCGiDT0Z16giv5UmMJoHJiPJoY3 /pVPISqmvwMSNL+vMAh+iW3pHDqphckIhijmbC+ATQjEMQTsljI= 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=SFlC dnI43zbSoNFXAAx/IxXfg+c=; b=hy3eb9L/AEdrSxXt/Kb6c2BS2azFcNbS6zk5 MpQDe7PpT+0XKkrWaUu/kEhPt/UvKoSEOUChuaM/Qz2dRjAXkg56RssgCRmSrn1H AKYiEpGzXoBaRGTgf2ZgRxjaunEJKYAYSDphgwMBonj6Iz9yLPdGZf6S82bfGi7T jpGeUvU= X-Sasl-enc: 2nZq3+87jUBWzZxOSPn/3lZe2q6aSEnpTWwrSuwSS/lH 1339956058 Received: from [192.168.5.18] (unknown [83.169.5.6]) by mail.messagingengine.com (Postfix) with ESMTPA id D31128E018E for ; Sun, 17 Jun 2012 14:00:57 -0400 (EDT) Message-ID: <4FDE1B53.3010905@binarywings.net> Date: Sun, 17 Jun 2012 20:00:51 +0200 From: Florian Philipp User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120602 Thunderbird/10.0.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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> <4FDAEA24.3010303@binarywings.net> <20120616195104.192e5abd@pomiocik.lan> <1694115.BlGnUZZYGL@mephista> In-Reply-To: <1694115.BlGnUZZYGL@mephista> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA146A666AD2597DC94AFBB12" X-Archives-Salt: 7d3fe8ae-9a0a-4b6a-bac3-af33dde6bdcb X-Archives-Hash: 78534c81e599b5753696c052977c2dfa This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA146A666AD2597DC94AFBB12 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 17.06.2012 19:34, schrieb Sascha Cunz: > [...] >=20 >> It doesn't. It's just a very long wooden fence; you just didn't find >> the hole yet. >=20 > Given the fact that the keys in the BIOS must somehow get there and it = must=20 > also be able to update them (how to revoke or add keys else?). >=20 > Unless this is completely done in hardware, there must be a software do= ing it.=20 > Software can - by design - be reverse engineered; in some countries eve= n=20 > legally without any further agreement or license. >=20 > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism= on=20 > this blob of software - at some point it must be readable from the proc= essor,=20 > so you have to provide the mechanisms to verify signs, undo encryption = etc=20 > somewhere (either in hardware or another software). >=20 > Even if you somehow manage to embed all of this in the hardware stack, = it=20 > would still require some kind of interface to get updated / revoked key= s to=20 > operate on. >=20 > It's not a matter of *if this can* be broken by someone who cares, it's= a=20 > matter of *how long does it take* for someone who cares to break it. >=20 > In the end, this is just another kind of "seems to be secure for a day = or=20 > two". Admittedly a complex one - but there will always be a "kid in a g= arage"=20 > that is able to set everyone else out of business. >=20 > SaCu >=20 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 Key Exchange Keys). Under the assumption that the implementation is correct, nothing on the operating system level can inject drivers, boot loaders or whatever else 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 for signing and verifying code are SHA-256 and RSA-2048. Good luck breaking that in "a day or two"! Second point: Secure Boot is not designed to protect against an attacker 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 can be broken. 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 should we abandon Secure Boot? Regards, Florian Philipp --------------enigA146A666AD2597DC94AFBB12 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/eG1cACgkQqs4uOUlOuU8zMQCeMdOJVcoELYlSiu8TugXVkInb MdcAn07/HH4puCRtWoZizUHEOq3Kgfga =BMys -----END PGP SIGNATURE----- --------------enigA146A666AD2597DC94AFBB12--