Date
1 - 6 of 6
PKCS7 Authenticated Variable Enrollment
Guomin Jiang
Hi Divneil,
Good News, thanks for your update.
toggle quoted message
Show quoted text
Good News, thanks for your update.
-----Original Message-----
From: Wadhawan, Divneil R <divneil.r.wadhawan@...>
Sent: Tuesday, June 30, 2020 1:49 AM
To: Jiang, Guomin <guomin.jiang@...>; rfc@edk2.groups.io
Cc: Zimmer, Vincent <vincent.zimmer@...>; Wadhawan, Divneil R
<divneil.r.wadhawan@...>
Subject: RE: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
Hi Guomin,
I have moved forward from the last discussion, and the tools work okay for
RSA2048/SHA256.
Once I have the next update, I will notify it here.
Regards,
Divneil
-----Original Message-----
From: Jiang, Guomin <guomin.jiang@...>
Sent: Wednesday, May 27, 2020 4:34 PM
To: rfc@edk2.groups.io; Wadhawan, Divneil R
<divneil.r.wadhawan@...>
Subject: RE: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
I am sorry that I have not the use case, and I plan to investigating it after
August.-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of
divneil.r.wadhawan@...
Sent: Wednesday, May 27, 2020 6:54 PM
To: Jiang, Guomin <guomin.jiang@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
Hi Goumin,
I had discussion internally, and I got hold off tools from:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per
EFI_VARIABLE_AUTHENTICATION_2.
So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which
uses
PKCS7 format and PKCS7_verify works?
Regards,
Divneil
Wadhawan, Divneil R
Hi Guomin,
I have moved forward from the last discussion, and the tools work okay for RSA2048/SHA256.
Once I have the next update, I will notify it here.
Regards,
Divneil
toggle quoted message
Show quoted text
I have moved forward from the last discussion, and the tools work okay for RSA2048/SHA256.
Once I have the next update, I will notify it here.
Regards,
Divneil
-----Original Message-----
From: Jiang, Guomin <guomin.jiang@...>
Sent: Wednesday, May 27, 2020 4:34 PM
To: rfc@edk2.groups.io; Wadhawan, Divneil R <divneil.r.wadhawan@...>
Subject: RE: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
I am sorry that I have not the use case, and I plan to investigating it after August.
From: Jiang, Guomin <guomin.jiang@...>
Sent: Wednesday, May 27, 2020 4:34 PM
To: rfc@edk2.groups.io; Wadhawan, Divneil R <divneil.r.wadhawan@...>
Subject: RE: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
I am sorry that I have not the use case, and I plan to investigating it after August.
-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of
divneil.r.wadhawan@...
Sent: Wednesday, May 27, 2020 6:54 PM
To: Jiang, Guomin <guomin.jiang@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
Hi Goumin,
I had discussion internally, and I got hold off tools from:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per
EFI_VARIABLE_AUTHENTICATION_2.
So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which
uses
PKCS7 format and PKCS7_verify works?
Regards,
Divneil
Guomin Jiang
I am sorry that I have not the use case, and I plan to investigating it after August.
toggle quoted message
Show quoted text
-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of
divneil.r.wadhawan@...
Sent: Wednesday, May 27, 2020 6:54 PM
To: Jiang, Guomin <guomin.jiang@...>; rfc@edk2.groups.io
Subject: Re: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
Hi Goumin,
I had discussion internally, and I got hold off tools from:
https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per
EFI_VARIABLE_AUTHENTICATION_2.
So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses
PKCS7 format and PKCS7_verify works?
Regards,
Divneil
Wadhawan, Divneil R
Hi Goumin,
I had discussion internally, and I got hold off tools from: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per EFI_VARIABLE_AUTHENTICATION_2.
So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses PKCS7 format and PKCS7_verify works?
Regards,
Divneil
I had discussion internally, and I got hold off tools from: https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git.
It is generating the correct format as per EFI_VARIABLE_AUTHENTICATION_2.
So, I thought of first validating RSA2048 Sign verification and it is failing.
I still have to figure out that. Do you have a working use case which uses PKCS7 format and PKCS7_verify works?
Regards,
Divneil
Guomin Jiang
Hi Wadhawan,
I will check it after August because I am busy recently.
Best Regards
Guomin
toggle quoted message
Show quoted text
I will check it after August because I am busy recently.
Best Regards
Guomin
-----Original Message-----
From: rfc@edk2.groups.io <rfc@edk2.groups.io> On Behalf Of Wadhawan,
Divneil R
Sent: Friday, May 1, 2020 2:19 AM
To: rfc@edk2.groups.io
Cc: Wadhawan, Divneil R <divneil.r.wadhawan@...>
Subject: [edk2-rfc] PKCS7 Authenticated Variable Enrollment
Hi,
I am trying to test if the enrollment of Authenticated Variables is possible
with verification of signature with different key sizes.
File: AuthService.c :: Function: VerifyTimeBasedPayload() -> Pkcs7Verify() So,
to achieve that, I did the following:
a. Generate the KEK.auth
uuidgen --random > GUID.txt
openssl req -newkey rsa:3072 -nodes -keyout PK.key -new -x509 -sha384 -
days 3650 -subj "/CN=my Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
openssl req -newkey rsa:3072 -nodes -keyout KEK.key -new -x509 -sha384
-days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
b. Enroll PK.cer from BIOS menu in custom mode
c. Hack the KEK enrollment connected to BIOS Menu (HII interface) and
disable custom mode and then gRT->SetVariable() on input data
File: SecureBootConfigImpl.c :: Function: EnrollKeyExchangeKey()
I found that the KEK.auth format is rejected by VerifyTimeBasedPayload() in
(CompareMem (SigData + 13, &mSha256OidValue, sizeof
(mSha256OidValue)) != 0)) {
So, I did a hexdump of KEK.auth and could see that data is not as expected.
Here's the dump I have of KEK.auth
//EFI_Time (16 bytes)
0000000 e5 07 03 10 0e 39 00 00 00 00 00 00 00 00 00 00
// WIN_CERTIFICATE_UEFI_GUID (16bytes + 8bytes) // SigData starts at value
0x30 post WIN_CERTIFICATE_UEFI_GUID. At offset of 13 from 0x30 the code
expects sha256 OID
0000020 0e 07 00 00 00 02 f1 0e 9d d2 af 4a df 68 ee 49
0000040 8a a9 34 7d 37 56 65 a7 30 82 06 f2 06 09 2a 86
0000060 48 86 f7 0d 01 07 02 a0 82 06 e3 30 82 06 df 02
// sha256 oid starts from here: 60 86 48 01 65 03 04 02 (last 8 bytes + 1byte in
next line)
0000100 01 01 31 0f 30 0d 06 09 60 86 48 01 65 03 04 02
0000120 01 05 00 30 0b 06 09 2a 86 48 86 f7 0d 01 07 01
So, the sha256 oid is present but is at a far away offset. Can you please help
in identifying the problem component.
I also wanted to talk about the oid value of sha256 present, where as sha384
is used.
The above data dump is same in terms of offset for RSA2048/SHA256
KEK.auth I have based this method on the understanding that, if we have
some OS interface to set the variables, it will pass the KEK.auth directly into
gRT->SetVariable().
Regards,
Divneil
Wadhawan, Divneil R <divneil.r.wadhawan@...>
Hi,
I am trying to test if the enrollment of Authenticated Variables is possible with verification of signature with different key sizes.
File: AuthService.c :: Function: VerifyTimeBasedPayload() -> Pkcs7Verify()
So, to achieve that, I did the following:
a. Generate the KEK.auth
uuidgen --random > GUID.txt
openssl req -newkey rsa:3072 -nodes -keyout PK.key -new -x509 -sha384 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
openssl req -newkey rsa:3072 -nodes -keyout KEK.key -new -x509 -sha384 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
b. Enroll PK.cer from BIOS menu in custom mode
c. Hack the KEK enrollment connected to BIOS Menu (HII interface) and disable custom mode and then gRT->SetVariable() on input data
File: SecureBootConfigImpl.c :: Function: EnrollKeyExchangeKey()
I found that the KEK.auth format is rejected by VerifyTimeBasedPayload() in
(CompareMem (SigData + 13, &mSha256OidValue, sizeof (mSha256OidValue)) != 0)) {
So, I did a hexdump of KEK.auth and could see that data is not as expected. Here's the dump I have of KEK.auth
//EFI_Time (16 bytes)
0000000 e5 07 03 10 0e 39 00 00 00 00 00 00 00 00 00 00
// WIN_CERTIFICATE_UEFI_GUID (16bytes + 8bytes)
// SigData starts at value 0x30 post WIN_CERTIFICATE_UEFI_GUID. At offset of 13 from 0x30 the code expects sha256 OID
0000020 0e 07 00 00 00 02 f1 0e 9d d2 af 4a df 68 ee 49
0000040 8a a9 34 7d 37 56 65 a7 30 82 06 f2 06 09 2a 86
0000060 48 86 f7 0d 01 07 02 a0 82 06 e3 30 82 06 df 02
// sha256 oid starts from here: 60 86 48 01 65 03 04 02 (last 8 bytes + 1byte in next line)
0000100 01 01 31 0f 30 0d 06 09 60 86 48 01 65 03 04 02
0000120 01 05 00 30 0b 06 09 2a 86 48 86 f7 0d 01 07 01
So, the sha256 oid is present but is at a far away offset. Can you please help in identifying the problem component.
I also wanted to talk about the oid value of sha256 present, where as sha384 is used.
The above data dump is same in terms of offset for RSA2048/SHA256 KEK.auth
I have based this method on the understanding that, if we have some OS interface to set the variables, it will pass the KEK.auth directly into gRT->SetVariable().
Regards,
Divneil
I am trying to test if the enrollment of Authenticated Variables is possible with verification of signature with different key sizes.
File: AuthService.c :: Function: VerifyTimeBasedPayload() -> Pkcs7Verify()
So, to achieve that, I did the following:
a. Generate the KEK.auth
uuidgen --random > GUID.txt
openssl req -newkey rsa:3072 -nodes -keyout PK.key -new -x509 -sha384 -days 3650 -subj "/CN=my Platform Key/" -out PK.crt
openssl x509 -outform DER -in PK.crt -out PK.cer
openssl req -newkey rsa:3072 -nodes -keyout KEK.key -new -x509 -sha384 -days 3650 -subj "/CN=my Key Exchange Key/" -out KEK.crt
openssl x509 -outform DER -in KEK.crt -out KEK.cer
cert-to-efi-sig-list -g "$(< GUID.txt)" KEK.crt KEK.esl
sign-efi-sig-list -g "$(< GUID.txt)" -k PK.key -c PK.crt KEK KEK.esl KEK.auth
b. Enroll PK.cer from BIOS menu in custom mode
c. Hack the KEK enrollment connected to BIOS Menu (HII interface) and disable custom mode and then gRT->SetVariable() on input data
File: SecureBootConfigImpl.c :: Function: EnrollKeyExchangeKey()
I found that the KEK.auth format is rejected by VerifyTimeBasedPayload() in
(CompareMem (SigData + 13, &mSha256OidValue, sizeof (mSha256OidValue)) != 0)) {
So, I did a hexdump of KEK.auth and could see that data is not as expected. Here's the dump I have of KEK.auth
//EFI_Time (16 bytes)
0000000 e5 07 03 10 0e 39 00 00 00 00 00 00 00 00 00 00
// WIN_CERTIFICATE_UEFI_GUID (16bytes + 8bytes)
// SigData starts at value 0x30 post WIN_CERTIFICATE_UEFI_GUID. At offset of 13 from 0x30 the code expects sha256 OID
0000020 0e 07 00 00 00 02 f1 0e 9d d2 af 4a df 68 ee 49
0000040 8a a9 34 7d 37 56 65 a7 30 82 06 f2 06 09 2a 86
0000060 48 86 f7 0d 01 07 02 a0 82 06 e3 30 82 06 df 02
// sha256 oid starts from here: 60 86 48 01 65 03 04 02 (last 8 bytes + 1byte in next line)
0000100 01 01 31 0f 30 0d 06 09 60 86 48 01 65 03 04 02
0000120 01 05 00 30 0b 06 09 2a 86 48 86 f7 0d 01 07 01
So, the sha256 oid is present but is at a far away offset. Can you please help in identifying the problem component.
I also wanted to talk about the oid value of sha256 present, where as sha384 is used.
The above data dump is same in terms of offset for RSA2048/SHA256 KEK.auth
I have based this method on the understanding that, if we have some OS interface to set the variables, it will pass the KEK.auth directly into gRT->SetVariable().
Regards,
Divneil