- 
                Notifications
    
You must be signed in to change notification settings  - Fork 104
 
Description
I believe the data set for this test should be updated as it's not compatible with more recent versions of OpenSSL due to negative Serial #'s
Explanation is provided below:
Am referring to "mAuthVarDERCreateKey0" from thhe test listed above.
It consists of the following:
EFI_VARIABLE_AUTHENTICATION_2 header
      16 bytes     EFI_TIME
      8 bytes       WIN_CERTIFICATE
      16 bytes    EFI_GUID
Cert Data
763 Bytes
Data Payload
       10 bytes
             813 bytes
The first 40 bytes are basically used to encapsulate the Cert indicating it contains the EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS attribute set.
If you take the plain Cert, which starts at offset 40 and is 763 bytes (as the last 10 bytes of mAuthVarDERCreateKey0) is just the data payload , converting to a DER file and just dump that:
cat PlainCert.txt
308202F7020101310F300D06096086480165030402010500300B06092A864886F70D010701A08201FD308201F930820162A0030201020210B7E3A93A53E3CD834CD731DBA746379E300D06092A864886F70D01010B05003015311330110603550403130A54657374526F6F743031301E170D3132313131333038313531335A170D3339313233313233353935395A3015311330110603550403130A54657374526F6F74303130819F300D06092A864886F70D010101050003818D0030818902818100B132DAE7BEB8EB171560F6BC45458A209DAE944A36DE5E11924A3FB995B2154E08B1BCB8B9CEAD44E52FFD943EA420509312E35BA031DBCD7A34D800E3D24ADB82095C343F888B830D57B4C84D37E166B11250A8446BF9AEF332663C98BFCA57313B1677E63D33F793661926FE18D3F804F9A1922F8618EC806E7165CAEA99370203010001A34A304830460603551D01043F303D80100AC7C3AE1FB92E5A03235E35F603D6D7A1173015311330110603550403130A54657374526F6F7430318210B7E3A93A53E3CD834CD731DBA746379E300D06092A864886F70D01010B0500038181009044CC26DFBCA5B176A1AB3C020C605178CF5A16454731181A4836B0C2C5C1663FF5352DF8A975A4FFBE88EDA688F178C68C3705C47873D9D43BB80F79FF76E0FA671985D5A4D4253608786F0793571D769DFB55CC13FC6857322B643403799ECBBD4F06E866E87C9A1BA35FB8C00311A81E95298685C532D4871A943954DD5A3181D23081CF02010130293015311330110603550403130A54657374526F6F7430310210B7E3A93A53E3CD834CD731DBA746379E300D06096086480165030402010500300D06092A864886F70D01010105000481805DBE2B6E804BB2D654732DFB0A6A5E09A3E753FA5FF46125D07BE1455DEA4D371602A5FF085504D3CCC6D30B0F1D535B8401C9485C85FF354CC60940825DD57B03A3D5C0A9EDCD347AAF00613914C32B93F14B6A4D288BE7C89AD31BD13E18F68EA25B4872AA3BA9D03B32ABC1F80F427298622F548375D5C11ADEAC49FEC9A
Convert that to its hex representation:
xxd -r -ps PlainCert.txt PlainCert.der
Now if I Asn1Parse PlainCert.der (which is now 763 bytes)
dumpasn1 PlainCert | grep Error
:           Error: Integer is encoded as a negative value.
:             Error: Time value cannot be represented in a 32-bit time_t.
1 warning, 3 errors.
:           Error: Integer is encoded as a negative value.
OR use openssl
openssl asn1parse -inform DER -in PlainText.der
and you will see the negative numbers mentioned above.
============================================================================================================
Now later in the test, using the  Cert above, it gets prepended with a 19 byte ContentInfo struct,  which they call "Wrapping the PKCS7 data".
So we are wrapping, the above cert and that results in a PKCS7 blob of 782 bytes:
cat SignedPkcs7Blob.txt
3082030A06092A864886F70D010702A08202FB308202F7020101310F300D06096086480165030402010500300B06092A864886F70D010701A08201FD308201F930820162A0030201020210B7E3A93A53E3CD834CD731DBA746379E300D06092A864886F70D01010B05003015311330110603550403130A54657374526F6F743031301E170D3132313131333038313531335A170D3339313233313233353935395A3015311330110603550403130A54657374526F6F74303130819F300D06092A864886F70D010101050003818D0030818902818100B132DAE7BEB8EB171560F6BC45458A209DAE944A36DE5E11924A3FB995B2154E08B1BCB8B9CEAD44E52FFD943EA420509312E35BA031DBCD7A34D800E3D24ADB82095C343F888B830D57B4C84D37E166B11250A8446BF9AEF332663C98BFCA57313B1677E63D33F793661926FE18D3F804F9A1922F8618EC806E7165CAEA99370203010001A34A304830460603551D01043F303D80100AC7C3AE1FB92E5A03235E35F603D6D7A1173015311330110603550403130A54657374526F6F7430318210B7E3A93A53E3CD834CD731DBA746379E300D06092A864886F70D01010B0500038181009044CC26DFBCA5B176A1AB3C020C605178CF5A16454731181A4836B0C2C5C1663FF5352DF8A975A4FFBE88EDA688F178C68C3705C47873D9D43BB80F79FF76E0FA671985D5A4D4253608786F0793571D769DFB55CC13FC6857322B643403799ECBBD4F06E866E87C9A1BA35FB8C00311A81E95298685C532D4871A943954DD5A3181D23081CF02010130293015311330110603550403130A54657374526F6F7430310210B7E3A93A53E3CD834CD731DBA746379E300D06096086480165030402010500300D06092A864886F70D01010105000481805DBE2B6E804BB2D654732DFB0A6A5E09A3E753FA5FF46125D07BE1455DEA4D371602A5FF085504D3CCC6D30B0F1D535B8401C9485C85FF354CC60940825DD57B03A3D5C0A9EDCD347AAF00613914C32B93F14B6A4D288BE7C89AD31BD13E18F68EA25B4872AA3BA9D03B32ABC1F80F427298622F548375D5C11ADEAC49FEC9AB
The bold above is the prepended 19 byte Content Info struct, followed by the original 763 bytes of PKCS7 data (original Cert in mAuthVarDERCreateKey0).
Convert that to its hex representation:
xxd -r -ps SignedPkcs7Blob.txt SignedPkcs7Blob.der
Now dump that PKCS7 blob: (cms below is also known as PKCS7)
openssl cms -cmsout -print -noout -inform der -in
You will again see the negative serial #'s.
After the PKCS7 blob is built above, the openssl conversion function d2i_PKCS7() gets called.
d2i_PKCS7 is an OpenSSSL function which decodes PKCS7 data structure (from an ASN1 stream) into
a PKCS7 data structure.  The negative serial # (though frowned upon, is not illegal and supposed to be supported)
is barfed on by our OpenSSL software.
Using the later version of OpenSSL (which is much stricter in it's ASN1 parsing), a failure code is returned
and we fail the ASR test you mentioned above.  We use OpenSSL version  3.0.9 and that fails ASN1 parsing of
this dataset. I don't know which versions of OpenSSL will fail here, just that newer versions will fail.
Using an OpenSSL, version of 1.1.1.q, this same test pases.
I think your test is fine, just the data content (i.e. the contained Cert) might need to be updated. That Cert is from 2012 it appears.