[edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode

[Zhang, Chao B]

Hi Laszlo:
   Your investigation makes sense to me. For Keep old logic as an option will be a mild evolution.
HI Derek,
  Would you please update your patch based on Laszlo’s comments? Please don’t forget to CC Laszlo.

From: devel at edk2.groups.io [mailto:devel at edk2.groups.io] On Behalf Of Laszlo Ersek
Sent: Thursday, July 11, 2019 7:47 PM
To: Zhang, Chao B <chao.b.zhang at intel.com>; devel at edk2.groups.io; Wang, Jian J <jian.j.wang at intel.com>; Derek Lin <derek.lin2 at hpe.com>; Cinnamon Shia <cinnamon.shia at hpe.com>; Felix Poludov <Felixp at ami.com>; Peter Jones <pjones at redhat.com>
Subject: Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode

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=1983
> The justification lies here:
>   Spec perspective:
>     Section 8.2.2  : In SetupMode Secure Boot Policy variables shall consider 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 – 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 system is in setup mode
>    2) PKpub Default can be easily updated to PK
>
> Back to Laszlo’s 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-signedness on
>           X509 certificates, if the proposed patch were applied.
>       A:  After this patch, there is no self-encrypted PK check. Per discussion, we believe that is not a new security hole
>          Even with self-proofed PK check, attacker can easily spoof a faked PK attack in setup mode.   Generally speaking,
>          PK provision should happen in Build phase or with Physical Presence 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 fully.

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#43620): https://edk2.groups.io/g/devel/message/43620
Mute This Topic: https://groups.io/mt/32283314/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20190712/a64984a5/attachment.htm>