Date
1 - 6 of 6
PKCS7 Authenticated Variable Enrollment
|
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 |
|
|
|
Guomin Jiang
Hi Wadhawan,
toggle quoted message
Show quoted text
I will check it after August because I am busy recently. Best Regards Guomin -----Original Message----- |
|
|
|
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 |
|
|
|
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----- |
|
|
|
Wadhawan, Divneil R
Hi Guomin,
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. -----Original Message----- |
|
|
|
Guomin Jiang
Hi Divneil,
toggle quoted message
Show quoted text
Good News, thanks for your update. -----Original Message----- |
|
|