From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: lersek@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Thu, 11 Jul 2019 04:47:27 -0700 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 654A130820C9; Thu, 11 Jul 2019 11:47:26 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-231.ams2.redhat.com [10.36.117.231]) by smtp.corp.redhat.com (Postfix) with ESMTP id 88E0D5D9D5; Thu, 11 Jul 2019 11:47:24 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode To: "Zhang, Chao B" , "devel@edk2.groups.io" , "Wang, Jian J" , Derek Lin , Cinnamon Shia , Felix Poludov , Peter Jones References: <7564.1562045108414671150@groups.io> <8d43a917-2a24-9db0-548c-2774db1e52a0@redhat.com> From: "Laszlo Ersek" Message-ID: <25dbc70b-4249-7931-b232-fd1ffe5a912c@redhat.com> Date: Thu, 11 Jul 2019 13:47:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.47]); Thu, 11 Jul 2019 11:47:26 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/11/19 05:20, Zhang, Chao B wrote: > HI Laszlo: > There is a discussion over this issue in UEFI Manits https://mantis.= uefi.org/mantis/view.php?id=3D1983 > The justification lies here: > Spec perspective: > Section 8.2.2 : In SetupMode Secure Boot Policy variables shall co= nsider step 3 and 4 check to be successful. > Section 32.3.1 : If in the platform is in stepup mode, then the new= PKpub may be signed with PKpriv > Customer needs: > 1) PK update process is complex based on current implementation =E2= =80=93 self signed PK is required. 2 PK images are required > - new PK signed with the old PKprivate, to be used if system is in user= mode > - new self-sighed PK (new PK signed with new PKprivate) to be used if s= ystem is in setup mode > 2) PKpub Default can be easily updated to PK >=20 > Back to Laszlo=E2=80=99s question > (1) What is the exact failure (or spec non-conformance) scenario? > A: Please see above explanation > (2a) whether skipping step#4 in SetupMode is a bug in the spec -- = because, I think it is; > A: Please see customer needs part in above explanation > (2b) whether the edk2 code would continue enforcing self-signednes= s on > X509 certificates, if the proposed patch were applied. > A: After this patch, there is no self-encrypted PK check. Per di= scussion, we believe that is not a new security hole > Even with self-proofed PK check, attacker can easily spoof a f= aked PK attack in setup mode. Generally speaking, > PK provision should happen in Build phase or with Physical Pre= sence Asserted. Thank you for the explanation. The discussion in Mantis#1983 makes the situation clear. In Mantis#1983, it was requested that self-signedness be strictly enforced when a PK is enrolled in Setup Mode. That matches my opinion ful= ly. Mantis#1983 was ultimately revoked because "it would complicate the PK update process". Namely, platform vendors would have to provide different blobs, for enrollment in setup mode (self-signed) vs. enrollment in user mode (signed with the currently in-place PK's private half). Well, I think that said process would be exactly right. The counter-argument: it would complicate the PK update process is poor, in my opinion, when it comes to the root of trust in Secure Boot. There is no failure scenario in fact, it's just that vendors would have to provide multiple update images, and users (or the update tools) would have to download the image that would be accepted by the current state. In my opinion, that should be fine. Multiple PK update images cannot be avoided anyway, if a platform vendor releases at least two PK updates, over time. (So that we have the initial PK0, and two updates, PK1, PK2.) When PK2 is released, it must be made available to systems running in User Mode - both as signed with PK0, - and as signed with PK1, anyway. So I don't see why it's a burden to release PK2 as signed with PK2 -- i.e., with itself -- as well. Mantis#1983 also highlights that it should always be possible to revert PK to PKDefault. IMO that should not be a problem if PKDefault is self-signed, and the physically present user switches the SB mode to Setup Mode first. In that case, PKDefault can be re-enrolled -- in the firmware setup utility, at boot time only -- like any other brand new self-signed PK. The point of requiring a self-signed certificate, and not just a public key, is *not* to increase security. The point is to perform a sanity check. If the certificate is correctly self-signed, it proves that, whoever generated the certificate, had access to the counterpart private key at least at that time. Conversely, if it's just a standalone pubkey, or the signature on the cert is from some other entity, then the end-user has no evidence that a matching private key was *ever* saved by the creator. Again, the point is not to prevent spoofing, but to sanity-check that the creator of the pubkey was capable of signing *at all* with the matching private key. And so I disagree with the rejection / revocation of Mantis#1983. Regarding the edk2 patch: If the patch indeed matches the UEFI-2.8 spec, then I don't have a valid case against the proposed patch. (Again, I think it's the spec that is problematic, and that Mantis#1983 had merit.) However, can we please introduce a FeaturePCD for sticking with the present in-tree behavior? I'm OK if the default value for the new FeaturePCD is such that the new (proposed, spec-conformant) behavior becomes the default. I'd just like if platforms could opt out (i.e. if they could enforce self-signedness in SetupMode). Thanks Laszlo