Date
1 - 4 of 4
Clarification: Enrolling PK from PKDefault
Jan Bobek
Hello all,
I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).
The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:
should be required to modify it.
signed with its PKpriv counterpart -- as opposed to user mode, where the
new PKpub MUST be signed with the old PKpriv.
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.
I have two notes w.r.t. the above:
1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?
2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.
Thanks in advance for any input,
-Jan Bobek
References:
[1] https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html#firmware-os-key-exchange-creating-trust-relationships
[2] https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/AuthVariableLib/AuthService.c#L606
I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).
The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:
While no Platform Key is enrolled, the SetupMode variable shall beIn other words, when no Platform Key is enrolled, no authentication
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.
should be required to modify it.
The platform owner enrolls the public half of the Platform Key (PKpub)When the platform is in setup mode, the new PKpub MAY (but need not) be
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.
signed with its PKpriv counterpart -- as opposed to user mode, where the
new PKpub MUST be signed with the old PKpriv.
The authenticated PK variable can always be read but can only beThe authenticated PK variable can be written if the platform is in setup
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.
The platform vendor may provide a default PKpub in the PKDefaultWhen in setup mode, one can read the contents of "PKDefault" variable,
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied to
the Platform Key variable using the SetVariable() call.
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.
I have two notes w.r.t. the above:
1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?
2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.
Thanks in advance for any input,
-Jan Bobek
References:
[1] https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html#firmware-os-key-exchange-creating-trust-relationships
[2] https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/AuthVariableLib/AuthService.c#L606
Sean
Yes, I agree with your #2. Tianocore is broken and not spec compliant and if any platform used it as is then PK default workflow would not work.
We opened a bug a few years ago: 2506 – When setting a new PK in setup mode, PK should not be required to be self-signed (tianocore.org) <https://bugzilla.tianocore.org/show_bug.cgi?id=2506>
And our Project Mu contains patches/changes to fix this.
Thanks
Sean
toggle quoted message
Show quoted text
We opened a bug a few years ago: 2506 – When setting a new PK in setup mode, PK should not be required to be self-signed (tianocore.org) <https://bugzilla.tianocore.org/show_bug.cgi?id=2506>
And our Project Mu contains patches/changes to fix this.
Thanks
Sean
On 1/3/2023 3:51 PM, Jan Bobek via groups.io wrote:
Hello all,
I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).
The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:While no Platform Key is enrolled, the SetupMode variable shall beIn other words, when no Platform Key is enrolled, no authentication
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.
should be required to modify it.The platform owner enrolls the public half of the Platform Key (PKpub)When the platform is in setup mode, the new PKpub MAY (but need not) be
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.
signed with its PKpriv counterpart -- as opposed to user mode, where the
new PKpub MUST be signed with the old PKpriv.The authenticated PK variable can always be read but can only beThe authenticated PK variable can be written if the platform is in setup
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.The platform vendor may provide a default PKpub in the PKDefaultWhen in setup mode, one can read the contents of "PKDefault" variable,
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied to
the Platform Key variable using the SetVariable() call.
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.
I have two notes w.r.t. the above:
1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?
2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.
Thanks in advance for any input,
-Jan Bobek
References:
[1]https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.html#firmware-os-key-exchange-creating-trust-relationships
[2]https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/AuthVariableLib/AuthService.c#L606
Yao, Jiewen
Hello
I have read https://bugzilla.tianocore.org/show_bug.cgi?id=2506 and https://edk2.groups.io/g/devel/topic/32283314#43150. That seems make sense to me.
Would you please send out the patch set, we can continue the review process?
Thank you
Yao, Jiewen
toggle quoted message
Show quoted text
I have read https://bugzilla.tianocore.org/show_bug.cgi?id=2506 and https://edk2.groups.io/g/devel/topic/32283314#43150. That seems make sense to me.
Would you please send out the patch set, we can continue the review process?
Thank you
Yao, Jiewen
-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Sean
Sent: Saturday, January 7, 2023 6:51 AM
To: discuss@edk2.groups.io; jbobek@...
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Xu, Min M <min.m.xu@...>
Subject: Re: [edk2-discuss] Clarification: Enrolling PK from PKDefault
Yes, I agree with your #2. Tianocore is broken and not spec compliant
and if any platform used it as is then PK default workflow would not work.
We opened a bug a few years ago: 2506 – When setting a new PK in setup
mode, PK should not be required to be self-signed (tianocore.org)
<https://bugzilla.tianocore.org/show_bug.cgi?id=2506>
And our Project Mu contains patches/changes to fix this.
Thanks
Sean
On 1/3/2023 3:51 PM, Jan Bobek via groups.io wrote:Hello all,be
I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).
The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:While no Platform Key is enrolled, the SetupMode variable shall beIn other words, when no Platform Key is enrolled, no authentication
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.
should be required to modify it.The platform owner enrolls the public half of the Platform Key (PKpub)When the platform is in setup mode, the new PKpub MAY (but need not)
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.signed with its PKpriv counterpart -- as opposed to user mode, where theto
new PKpub MUST be signed with the old PKpriv.The authenticated PK variable can always be read but can only beThe authenticated PK variable can be written if the platform is in setup
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.The platform vendor may provide a default PKpub in the PKDefault
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied[1]https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.htthe Platform Key variable using the SetVariable() call.When in setup mode, one can read the contents of "PKDefault" variable,
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.
I have two notes w.r.t. the above:
1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?
2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.
Thanks in advance for any input,
-Jan Bobek
References:
ml#firmware-os-key-exchange-creating-trust-relationships
[2]https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/Aut
hVariableLib/AuthService.c#L606
Jan Bobek
It seems the change Sean was talking about is [1].
Sean, if you're too busy and it's okay with you, I am willing to put in
the effort of adaping this change for EDK2.
Thanks,
-Jan
References:
1. https://github.com/microsoft/mu_basecore/commit/c3c2e03823a1711b189e9fe94b0ac611cda908e4
toggle quoted message
Show quoted text
Sean, if you're too busy and it's okay with you, I am willing to put in
the effort of adaping this change for EDK2.
Thanks,
-Jan
References:
1. https://github.com/microsoft/mu_basecore/commit/c3c2e03823a1711b189e9fe94b0ac611cda908e4
Hello
I have read https://bugzilla.tianocore.org/show_bug.cgi?id=2506 and https://edk2.groups.io/g/devel/topic/32283314#43150. That seems make sense to me.
Would you please send out the patch set, we can continue the review process?
Thank you
Yao, Jiewen-----Original Message-----
From: discuss@edk2.groups.io <discuss@edk2.groups.io> On Behalf Of Sean
Sent: Saturday, January 7, 2023 6:51 AM
To: discuss@edk2.groups.io; jbobek@...
Cc: Yao, Jiewen <jiewen.yao@...>; Wang, Jian J
<jian.j.wang@...>; Xu, Min M <min.m.xu@...>
Subject: Re: [edk2-discuss] Clarification: Enrolling PK from PKDefault
Yes, I agree with your #2. Tianocore is broken and not spec compliant
and if any platform used it as is then PK default workflow would not work.
We opened a bug a few years ago: 2506 – When setting a new PK in setup
mode, PK should not be required to be self-signed (tianocore.org)
<https://bugzilla.tianocore.org/show_bug.cgi?id=2506>
And our Project Mu contains patches/changes to fix this.
Thanks
Sean
On 1/3/2023 3:51 PM, Jan Bobek via groups.io wrote:Hello all,be
I was wondering if I could get a clarification regarding the process of
enrolling PK (Platform Key) from the UEFI variable "PKDefault" (i.e. the
OEM's default public PK).
The following are excerpts from the UEFI spec 2.10 [1] that seem
relevant to the matter, along with my interpretation underneath:While no Platform Key is enrolled, the SetupMode variable shall beIn other words, when no Platform Key is enrolled, no authentication
equal to 1. While SetupMode == 1, the platform firmware shall not
require authentication in order to modify the Platform Key, Key
Enrollment Key, OsRecoveryOrder, OsRecovery####, and image security
databases.
should be required to modify it.The platform owner enrolls the public half of the Platform Key (PKpub)When the platform is in setup mode, the new PKpub MAY (but need not)
by calling the UEFI Boot Service SetVariable() as specified in Using
the EFI_VARIABLE_AUTHENTICATION_3 descriptor. If the platform is in
setup mode, then the new PKpub may be signed with its PKpriv
counterpart. If the platform is in user mode, then the new PKpub must
be signed with the current PKpriv. When the platform is in setup mode,
a successful enrollment of a Platform Key shall cause the platform to
immediately transition to user mode.signed with its PKpriv counterpart -- as opposed to user mode, where theto
new PKpub MUST be signed with the old PKpriv.The authenticated PK variable can always be read but can only beThe authenticated PK variable can be written if the platform is in setup
written if the platform is in setup mode, or if the platform is in
user mode and the provided PKpub is signed with the current PKpriv.
mode, period. Once again, that's opposed to user mode, where the
provided PKpub must be signed with the current PKpriv.The platform vendor may provide a default PKpub in the PKDefault
variable described in Globally Defined Variables. This variable is
formatted identically to the Platform Key variable. If present, this
key may optionally be used as the public half of the Platform Key when
transitioning from setup mode to user mode. If so, it may be read,
placed within an EFI_VARIABLE_AUTHENTICATION2 structure and copied[1]https://uefi.org/specs/UEFI/2.10/32_Secure_Boot_and_Driver_Signing.htthe Platform Key variable using the SetVariable() call.When in setup mode, one can read the contents of "PKDefault" variable,
place it into an EFI_VARIABLE_AUTHENTICATION2 structure and enroll it as
a Platform Key. Note that in this case it is (presumably) not possible
to sign the default PKpub with its PKpriv counterpart, since it is not
part of the "PKDefault" variable contents. However, that is (presumably)
not an issue, since in setup mode the signature is optional and not
required.
I have two notes w.r.t. the above:
1. The second paragraph says you need to use
EFI_VARIABLE_AUTHENTICATION3 structure in order to enroll the
Platform Key, but the last paragraph suggests using
EFI_VARIABLE_AUTHENTICATION2. Perhaps these sentences need to be
harmonized as to not oppose one another?
2. (More importantly) If my understanding of the UEFI specification is
correct, then the current code in AuthVariableLib [2] is in direct
violation of the spec; namely it _specifically_ requires the PKpub to
be signed with its PKpriv counterpart when in setup
mode. Consequently, it is impossible to use "PKDefault" to enroll the
default PK since PKpriv is not available, and one must resort to
switching to custom mode. Cc'ing maintainers of AuthVariableLib to
comment on this point.
Thanks in advance for any input,
-Jan Bobek
References:
ml#firmware-os-key-exchange-creating-trust-relationships
[2]https://github.com/tianocore/edk2/blob/master/SecurityPkg/Library/Aut
hVariableLib/AuthService.c#L606