-----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