Thanks Jacob for your response. Very informative indeed! Thanks -Prasad
Sent from my iPhone > On 09-Sep-2014, at 10:05 pm, Jakob Bohm <jb-open...@wisemo.com> wrote: > >> 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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
