tianocore
RT.SetVariable - Create one Time Base Auth Variable, the expect return status should be EFI_SUCCESS -- FAILURE 008E18A5-C345-48AE-9134-61A692E30B87
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.
@jamesphurl Thank you for raising this issue. `
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 `
Could you please update what is meant by negative serial numbers?
Are negative serial numbers disallowed by any specification?
Hello @edhay,
Responses below:
_Could you please update what is meant by negative serial numbers?__
For this issue, what fails, in OpenSSL >= 3.0.9, the issue happens when d2i_PKCS7 is an OpenSSL function which decodes PKCS7 data structure (from an ASN1 stream) into a PKCS7 data structure.
I showed the datastream above which shows the 19 byte Content Info struct, prepended, followed by the original 763 bytes of PKCS7 data (original Cert in mAuthVarDERCreateKey0).
(1) Using SignedPkcs7Blob.txt above
- Convert that text file to a DER file
- xxd -r -ps SignedPkcs7Blob.txt SignedPkcs7Blob.der
(2) Now transform that DER file to an X509 PEM file (to easily show you the Negative Serial # I am talking about)
- openssl pkcs7 -inform DER -in SignedPkcs7Blob.der -print_certs -out SignedPkcs7Blob.pem
(3) Dump the X509 data
openssl x509 -in SignedPkcs7Blob.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: (Negative)48:1c:56:c5:ac:1c:32:7c:b3:28:ce:24:58:b9:c8:62 Signature Algorithm: sha256WithRSAEncryption Issuer: CN = TestRoot01 Validity Not Before: Nov 13 08:15:13 2012 GMT Not After : Dec 31 23:59:59 2039 GMT Subject: CN = TestRoot01 Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (1024 bit) Modulus: 00:b1:32:da:e7:be:b8:eb:17:15:60:f6:bc:45:45: 8a:20:9d:ae:94:4a:36:de:5e:11:92:4a:3f:b9:95: b2:15:4e:08:b1:bc:b8:b9:ce:ad:44:e5:2f:fd:94: 3e:a4:20:50:93:12:e3:5b:a0:31:db:cd:7a:34:d8: 00:e3:d2:4a:db:82:09:5c:34:3f:88:8b:83:0d:57: b4:c8:4d:37:e1:66:b1:12:50:a8:44:6b:f9:ae:f3: 32:66:3c:98:bf:ca:57:31:3b:16:77:e6:3d:33:f7: 93:66:19:26:fe:18:d3:f8:04:f9:a1:92:2f:86:18: ec:80:6e:71:65:ca:ea:99:37 Exponent: 65537 (0x10001) X509v3 extensions: 2.5.29.1: 0=.. ......Z.#^5......0.1.0...U... TestRoot01.....:S...L.1..F7. Signature Algorithm: sha256WithRSAEncryption Signature Value: 90:44:cc:26:df:bc:a5:b1:76:a1:ab:3c:02:0c:60:51:78:cf: 5a:16:45:47:31:18:1a:48:36:b0:c2:c5:c1:66:3f:f5:35:2d: f8:a9:75:a4:ff:be:88:ed:a6:88:f1:78:c6:8c:37:05:c4:78: 73:d9:d4:3b:b8:0f:79:ff:76:e0:fa:67:19:85:d5:a4:d4:25: 36:08:78:6f:07:93:57:1d:76:9d:fb:55:cc:13:fc:68:57:32: 2b:64:34:03:79:9e:cb:bd:4f:06:e8:66:e8:7c:9a:1b:a3:5f: b8:c0:03:11:a8:1e:95:29:86:85:c5:32:d4:87:1a:94:39:54: dd:5a
(4) Or if you don't want to go the X509 route, just dump the converted DER file:
openssl cms -cmsout -print -noout -inform der -in SignedPkcs7Blob.der
Are negative serial numbers disallowed by any specification?
RFC 5280:
https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.2
Just to summarize everything here. We need someone to work on this.
Issue
- The Auth variable test case fails when the firmware uses OpenSSL 3.0 or newer version library.
Root cause
- The hardcoded test pattern (mAuthVarDERCreateKey0[]) is not accepted by the firmware that uses OpenSSL 3.0 library. The pattern can only be accepted by older version 1.1.1. Note that the OpenSSL library in edk2 was updated from 1.1.1 to 3.0.9 in 2023 because Versions 1.1.1 and 1.0.2 are no longer supported. For details, please see https://openssl-library.org/policies/releasestrat/index.html.
Potential Solution
- Regenerate a new test pattern compatible with OpenSSL 3.0. Note if the new pattern cannot work with the firmware that uses OpenSSL 1.1.1, we will need to use two test patterns.
Cc @edhay @stuyod01 @jamesphurl
