On 09/09/2014 09:01, Prasad Dabak wrote:
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 digest
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/IP
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).
3. spcPEImageData is probably relevant only for signing that uses page
hashes?
I never quite figured out where they store the page hashes. However I
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.
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 and
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.
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 sets
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.
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. Plus
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 Name
fields is needed.
On Sep 06, 2014, at 09:44 PM, Prasad Dabak <pda...@icloud.com> wrote:
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!
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
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
