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

["Zhang, Chao B" <chao.b.zhang@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6787 bytes --]

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.


From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Thursday, July 11, 2019 1:04 AM
To: devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Zhang, Chao B <chao.b.zhang@intel.com>; Derek Lin <derek.lin2@hpe.com>; Cinnamon Shia <cinnamon.shia@hpe.com>
Subject: Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode

Hi,

On 07/10/19 10:50, Wang, Jian J wrote:
> Hi Derek,
>
> Please file a Bugzilla for this issue. With it addressed,
>
>     Reviewed-by: Jian J Wang jian.j.wang@intel.com<mailto:jian.j.wang@intel.com<mailto:jian.j.wang@intel.com%3cmailto:jian.j.wang@intel.com>>

I saw this patch as soon as it was posted, and I've been hoping for a
deeper discussion on the list. (I didn't ask my questions immediately
because I felt they might have been somewhat naive.) So I guess I have
to ask them now :)


(1) What is the exact failure (or spec non-conformance) scenario?

Is it the problem that, currently, even if SetupMode is 1, CustomMode
also needs to be set, for enrolling a self-signed PK?

(Looking at the patch itself, it looks like the subcondition that is
*not* the CustomMode check is relaxed; so that seems to support my
question.)


(2) Can we please confirm that the code will continue to enforce
self-signedness?

I checked the spec, and I'm a bit worried about the spec language
proper. Page 246 in UEFI-2.8 says,

  3. If the variable SetupMode==1, and the variable is a secure boot
     policy variable, then the firmware implementation shall consider
     the checks in the following steps 4 and 5 to have passed, and
     proceed with updating the variable value as outlined below.

  4. Verify the signature by:
     — extracting the EFI_VARIABLE_AUTHENTICATION_2 descriptor from the
       Data buffer;
     — using the descriptor contents and other parameters to (a)
       construct the input to the digest algorithm; (b) computing the
       digest; and (c) comparing the digest with the result of applying
       the signer’s public key to the signature.

In other words, step#4 seems to stand for verifying self-signedness, and
step#3 appears to require that *not even* self-signedness be enforced,
when in SetupMode.

Honestly, I think that step#4 should never be skipped. In other words,
self-signedness should be unconditional.

A certificate is basically a signed statement that a particular public
key belongs to a particular entity (such as "FooBar"). If *not even*
FooBar signs that statement, then the statement has *zero* credibility.
So why should we accept it for any purpose at all?

Speaking in terms of "PK" (UEFI Platform Key), specifically: what good
would a platform vendor be that failed to sign its own PK?

So, I'd like to understand:

(2a) whether skipping step#4 in SetupMode is a bug in the spec --
because, I think it is;

(2b) whether the edk2 code would continue enforcing self-signedness on
X509 certificates, if the proposed patch were applied.

Thanks!
Laszlo

> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Zhang, Chao B
> Sent: Tuesday, July 09, 2019 11:39 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; derek.lin2@hpe.com<mailto:derek.lin2@hpe.com>
> Subject: Re: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode
>
> Hi Derek:
>    The patch is good to me.
>    Reviewed-by : Chao Zhang <chao.b.zhang@intel.com<mailto:chao.b.zhang@intel.com<mailto:chao.b.zhang@intel.com%3cmailto:chao.b.zhang@intel.com>>>
>
> From: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>> [mailto:devel@edk2.groups.io] On Behalf Of derek.lin2@hpe.com<mailto:derek.lin2@hpe.com<mailto:derek.lin2@hpe.com%3cmailto:derek.lin2@hpe.com>>
> Sent: Tuesday, July 2, 2019 1:25 PM
> To: devel@edk2.groups.io<mailto:devel@edk2.groups.io<mailto:devel@edk2.groups.io%3cmailto:devel@edk2.groups.io>>
> Subject: [edk2-devel] [PATCH] SecurityPkg: Don't Verify the enrolled PK in setup mode
>
> Patch is attached from group.io.
> Since ECR785, which is added UEFI 2.3.1 errata A, enrolling a PK in setup mode doesn't need to verify the PK.
> Below is the sentence about it in UEFI spec
> ```
> 3. If the firmware is in setup mode and the variable is one of:
> - The global PK variable;
> - The global KEK variable;
> - The "db" variable with GUID EFI_IMAGE_SECURITY_DATABASE_GUID; or
> - The "dbx" variable with GUID EFI_IMAGE_SECURITY_DATABASE_GUID,
> then the firmware implementation shall consider the checks in the following steps 4 and 5 to
> have passed, and proceed with updating the variable value as outlined below.
> ```
> The step 4 is to verify the signature and the step 5 is to verify the cert.
>
> After this change, when system is in Setup mode, setting a PK does not require authenticated variable descriptor.
>
> Signed-off-by: Derek Lin <derek.lin2@hpe.com<mailto:derek.lin2@hpe.com<mailto:derek.lin2@hpe.com%3cmailto:derek.lin2@hpe.com>>>
> Signed-off-by: cinnamon shia <cinnamon.shia@hpe.com<mailto:cinnamon.shia@hpe.com<mailto:cinnamon.shia@hpe.com%3cmailto:cinnamon.shia@hpe.com>>>
>
>
>
> 
>

[-- Attachment #2: Type: text/html, Size: 20338 bytes --]