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:ler...@redhat.com]
Sent: Thursday, July 11, 2019 1:04 AM
To: devel@edk2.groups.io; Wang, Jian J <jian.j.w...@intel.com>; Zhang, Chao B
<chao.b.zh...@intel.com>; Derek Lin <derek.l...@hpe.com>; Cinnamon Shia
<cinnamon.s...@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.w...@intel.com<mailto:jian.j.w...@intel.com<mailto:jian.j.w...@intel.com%3cmailto:jian.j.w...@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.l...@hpe.com<mailto:derek.l...@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.zh...@intel.com<mailto:chao.b.zh...@intel.com<mailto:chao.b.zh...@intel.com%3cmailto:chao.b.zh...@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.l...@hpe.com<mailto:derek.l...@hpe.com<mailto:derek.l...@hpe.com%3cmailto:derek.l...@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.l...@hpe.com<mailto:derek.l...@hpe.com<mailto:derek.l...@hpe.com%3cmailto:derek.l...@hpe.com>>>
> Signed-off-by: cinnamon shia
> <cinnamon.s...@hpe.com<mailto:cinnamon.s...@hpe.com<mailto:cinnamon.s...@hpe.com%3cmailto:cinnamon.s...@hpe.com>>>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#43550): https://edk2.groups.io/g/devel/message/43550
Mute This Topic: https://groups.io/mt/32283314/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
