Prasad Dabak
2014-09-16 10:22:30 UTC
Hello,
I am currently focusing on matching various digests that we talked about earlier in the thread.
1. Computing the hash of the executable (excluding the areas as defined by MS) and matching it with the value stored in spcIndirectData. This is straight forward and figured out.
2. Computing the hash of spcIndirectData and matching it with with "messageDigest" stored in AuthenticatedAttributes. I realized that the sequence and length bytes need to be skipped before computing the hash of the spcIndirectData? Is this documented anywhere?
3. Computing hash of AuthenticatedAttributes and matching it with decrypted version of encryptedDigest. I am struggling to get this. Which portion of AuthenticatedAttributes should be considered for computing the hash? Further when I decrypt the encryptedDigest using the signer's public key, I get back a 256 byte value. This doesn't look like a SHA1 hash like in case (1) and (2). So what type of hash it is? Can someone elaborate OR point to documentation that elaborates on this?
Thanks.
-Prasad

I am currently focusing on matching various digests that we talked about earlier in the thread.
1. Computing the hash of the executable (excluding the areas as defined by MS) and matching it with the value stored in spcIndirectData. This is straight forward and figured out.
2. Computing the hash of spcIndirectData and matching it with with "messageDigest" stored in AuthenticatedAttributes. I realized that the sequence and length bytes need to be skipped before computing the hash of the spcIndirectData? Is this documented anywhere?
3. Computing hash of AuthenticatedAttributes and matching it with decrypted version of encryptedDigest. I am struggling to get this. Which portion of AuthenticatedAttributes should be considered for computing the hash? Further when I decrypt the encryptedDigest using the signer's public key, I get back a 256 byte value. This doesn't look like a SHA1 hash like in case (1) and (2). So what type of hash it is? Can someone elaborate OR point to documentation that elaborates on this?
Thanks.
-Prasad

Thanks Jacob for your response. Very informative indeed!
Thanks
-Prasad
Sent from my iPhone
is calculated over the file and is stored in the spcIndirectData. The
second digest is calculated over the spcIndirectData (the contentInfo
of the the PKCS#7 structure) and is stored as "messageDigest" in the
AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash
is calculated over the AuthenticatedAttributes and is signed to
produce the "encryptedDigest" in that same signerInfo. All 3 need to
be checked to confirm that the file hash is actually (indirectly)
signed by the encryptedDigest using the public key in the certificate
whose name is listed in the signerInfo.
checksum of file). Also it is allowed to be 0 to indicate no checksum
(even if you set the checksum, it might be cleared if an Administrator
adds his own countersignature to all authorized programs on his
computers, aka AppLocker).
believe the constant semi-empty spcPEImageData with the "<<<obsolete > > >"
string is the traditional marker to indicate that the signature is for
a PE file, and not e.g. a document file with the same hashed bytestream.
does not check. But note that it probably doesn't check the full chain
of 3 message digests, since at least the digest over the file itself is
inside a blob that the PKCS#7 standard has no opinion about.
of tagged strings) and the relevant comparison would be to compare those
elements that don't change when getting a new certificate from the CA.
It is the CAs responsibility to make sure the don't issue certificates
to the wrong people, and if they make a mistake they are expected to
quickly add the bad certificate to their published CRL, which is why
you need to check the CRL before trusting the certificate. An
additional check is to make sure the CA that issued the intermediary
certificate that issued the "COMAPNY-NAME" certificate is actually one
of the (few) CAs that "COMPANY-NAME" is going to buy certificates from.
This protects against fake certificates issued by smaller CAs that
you aren't going to use anyway.
consistency checks to make sure the signature is actually for a PE file
and was not otherwise doctored. For instance there should be no bytes
in the file after the end of the signature blob.
fields is needed.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 SÞborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Thanks
-Prasad
Sent from my iPhone
Thanks Jacob for an elaborate answer. Somehow I never received your response to my registered email address, hence delay in responding.
This time I have CC-ed you in addition to the mail list.I have a few follow-up questions on your response.
1. So, "encryptedDigest" has no relation to the stored "messageDigest"? I thought it's a encrypted version of the messageDigest?
As far as I recall, there is a chain of 4 digests. The first digest1. So, "encryptedDigest" has no relation to the stored "messageDigest"? I thought it's a encrypted version of the messageDigest?
is calculated over the file and is stored in the spcIndirectData. The
second digest is calculated over the spcIndirectData (the contentInfo
of the the PKCS#7 structure) and is stored as "messageDigest" in the
AuthenticatedAttributes of each PKCS#7 signerInfo. The third hash
is calculated over the AuthenticatedAttributes and is signed to
produce the "encryptedDigest" in that same signerInfo. All 3 need to
be checked to confirm that the file hash is actually (indirectly)
signed by the encryptedDigest using the public key in the certificate
whose name is listed in the signerInfo.
2. I agree that it's better to do cheaper checks first e.g. I am also matching PE checksum stored in the optional header.
Indeed, though that is a very weak checksum (file size plus 16 bit TCP/IPchecksum of file). Also it is allowed to be 0 to indicate no checksum
(even if you set the checksum, it might be cleared if an Administrator
adds his own countersignature to all authorized programs on his
computers, aka AppLocker).
3. spcPEImageData is probably relevant only for signing that uses page hashes?
I never quite figured out where they store the page hashes. However Ibelieve the constant semi-empty spcPEImageData with the "<<<obsolete > > >"
string is the traditional marker to indicate that the signature is for
a PE file, and not e.g. a document file with the same hashed bytestream.
4. PKCS7_verify is already matching the encryptedDigest, do we still need to validate it ourselves?
If it is, I am myself guessing a bit as to what that function does anddoes not check. But note that it probably doesn't check the full chain
of 3 message digests, since at least the digest over the file itself is
inside a blob that the PKCS#7 standard has no opinion about.
5. So, basically are are suggesting to look into the subject string and see if we can find patterns like /CN=COMPANY-NAME... issuer: /C=US/O=SIGNER_NAME....? How authoritative it is? I mean can someone else have same COMPANY-NAME and PATTERN-NAME in their certificate?
Actually, the subject is a data structure (a hierarchical list of setsof tagged strings) and the relevant comparison would be to compare those
elements that don't change when getting a new certificate from the CA.
It is the CAs responsibility to make sure the don't issue certificates
to the wrong people, and if they make a mistake they are expected to
quickly add the bad certificate to their published CRL, which is why
you need to check the CRL before trusting the certificate. An
additional check is to make sure the CA that issued the intermediary
certificate that issued the "COMAPNY-NAME" certificate is actually one
of the (few) CAs that "COMPANY-NAME" is going to buy certificates from.
This protects against fake certificates issued by smaller CAs that
you aren't going to use anyway.
In my case, I am the one who is signing the executable using my certificate and a "cross certificate" issued by Microsoft and I want to programmatically ensure following things.
1. Code is not tampered since it was signed (matching messageDigest with computed hash)
Actually matching digest in spcIndirectData with computed hash. Plus1. Code is not tampered since it was signed (matching messageDigest with computed hash)
consistency checks to make sure the signature is actually for a PE file
and was not otherwise doctored. For instance there should be no bytes
in the file after the end of the signature blob.
2. Verifying the digital signature (PKCS7_Verify)
3. Confirming that the executable is signed by my company certificate.
I am stuck on part (3) and don't see a clean way apart from matching strings in subject field? If I hard-code the public key in my verification code, I will need to update it when I switch to a newer public key?
Yep, that is why careful matching against various Distinguished Name3. Confirming that the executable is signed by my company certificate.
I am stuck on part (3) and don't see a clean way apart from matching strings in subject field? If I hard-code the public key in my verification code, I will need to update it when I switch to a newer public key?
fields is needed.
Hello,
Given a signed Windows portable executable, I want to programmatically verify two things using openssl APIs
1. Verify the digital signature.
2. Confirm that the executable is signed by a specific company using that company's public key.
It seems that part (1) can be done by parsing the signedData attribute in the portable executable, extracting the hashing algorithm and digest stored there, re-computing the digest of the executable using the same hashing algorithm and match them.
I have following questions.
1. The signData contains messageDigest (unencrypted) and encryptedDigest (encrypted). Is it enough to match messgaeDigest with the computed digest? OR we also need to decrypt the encryptedDigest using the company public key and match that as well?
2. What does PKCS7_Verify exactly do? I looked at https://www.openssl.org/docs/crypto/PKCS7_verify.htmland I understand that it verifies certificate chain. However, it's not clear to me as to what exactly it does with respect to signature verification?
3. I am assuming that I require to do both (1) and (2) in order to verify the authenticode signature?
4. What is the best way to verify if the executable is signed by specific company using that company's public key?
Any inputs will be greatly appreciated!
Given a signed Windows portable executable, I want to programmatically verify two things using openssl APIs
1. Verify the digital signature.
2. Confirm that the executable is signed by a specific company using that company's public key.
It seems that part (1) can be done by parsing the signedData attribute in the portable executable, extracting the hashing algorithm and digest stored there, re-computing the digest of the executable using the same hashing algorithm and match them.
I have following questions.
1. The signData contains messageDigest (unencrypted) and encryptedDigest (encrypted). Is it enough to match messgaeDigest with the computed digest? OR we also need to decrypt the encryptedDigest using the company public key and match that as well?
2. What does PKCS7_Verify exactly do? I looked at https://www.openssl.org/docs/crypto/PKCS7_verify.htmland I understand that it verifies certificate chain. However, it's not clear to me as to what exactly it does with respect to signature verification?
3. I am assuming that I require to do both (1) and (2) in order to verify the authenticode signature?
4. What is the best way to verify if the executable is signed by specific company using that company's public key?
Any inputs will be greatly appreciated!
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 SÞborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project http://www.openssl.org